I looked through the current code for VCL::Module::Provisioning::VMware::vSphere_SDK
For the most part, all of the code I submitted for the vCenter module has been integrated into vSphere_SDK class. There are three exceptions, which I didn't see in the current code: 1. in the move_virtual_disk subroutine, you use the MoveVirtualDisk vSphere method. This works fine on esx hosts, but in the context of a vCenter, it will return a "not implemented" fault. I liked how this was handled in the copy_virtual_disk subroutine: first try the method that makes sense and then fall back to using the full 'CloneVM' approach if the first method doesn't work. The way I had implemented this, move_virtual_disk just uses the copy_virtual_disk method and then deletes the source files upon successful completion. I can add that code if you would like. 2. in the copy_file_to and copy_file_from subroutines, I needed to add a loop because the VIExt::http_put_file and VIExt::http_get_file functions periodically fail. That is, if copy_file_to fails, the code sleeps for a few seconds and tries again, up to a maximum of a few tries. From what I can tell, this sort of looping doesn't exist when prepare_vmx() is called. I can wrap that in a Module::code_loop_timeout subroutine, if you would like. 3. When vCenter clones a VM with the CloneVM method, it will silently truncate long vm names. This isn't necessarily a problem as long as that new name finds its way into the database; otherwise, however, when VMX files are generated, the vmdk file pointers will reference incorrect locations. I had solved this by enforcing a maximum length in the web code (i.e. the vcl.image.name table). There are pros and cons to this, though a better approach may be to retrieve the actual name of the vmdk file after a clone operation is performed. This would require having the copy_virtual_disk and move_virtual_disk to return values other than just 1 (or, those methods could update the database themselves). I am not sure which approach you would prefer. I am also unsure of the best way to update the database with this information: would I simply call database_execute(...) and then call $self->data->refresh()? Or is there other code that handles this type of operation? Please advise. Aaron On Apr 25, 2012, at 10:28 AM, Josh Thompson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I think we targeted April to get a release out. The number of JIRA issues we > have left is starting to go down a fair amount. I'm almost finished with the > frontend. How's the backend? Are there other things we'd like to do for > this > release such as scripting the install as much as possible? I don't think > we'll be done by the end of April, but I think the first week of May would be > possible. > > Aaron C., Jim, and David - Have you tested your provisioning modules with > recent code from subversion? If not, do you think you can do that in the > next > week or two? > > Josh > - -- > - ------------------------------- > Josh Thompson > VCL Developer > North Carolina State University > > my GPG/PGP key can be found at pgp.mit.edu > > All electronic mail messages in connection with State business which > are sent to or received by this account are subject to the NC Public > Records Law and may be disclosed to third parties. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (GNU/Linux) > > iEYEARECAAYFAk+YChIACgkQV/LQcNdtPQPsagCdHCZOuT1ZIXxZrB+9EtppUjkc > KJIAn1mxEVtuZ64KEG0I4AwosUo3qT2P > =InjJ > -----END PGP SIGNATURE----- >
