I looked through the current code for
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.
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
> 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
> 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
> week or two?
> - --
> - -------------------------------
> 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)
> -----END PGP SIGNATURE-----