Please feel free to make the changes you described in 1 and 2 to trunk.
Number 3 is a bit trickier. I'm afraid setting a name length limit in
the database will break other things.
Is the directory name also truncated or left intact? Example:
Assuming the directory name is NOT truncated, what do you think about
leaving the name in the database as-is
(vmwarewin2008-myreallylongname-v0) even if the vmdk file name gets
truncated. Add additional code to get the actual vmdk file name
rather than constructing it. This would probably be done in
VMware.pm::does_image_exist. Rather than looking for the full,
non-truncated vmdk file path it could get a list of vmdk directory
contents and then fetch the actual file name. Once retrieved,
set_vmdk_file_path could be called. All of the get_vmdk* subroutines
should then automatically use the correct value.
If the directory name gets truncated then there could be additional
problems if the truncated winds up being identical to another existing
-gets truncated to-
This would cause conflicts in both the filesystem and database. The
database wouldn't allow you to change the image name because
image.name has a unique restriction.
On Wed, Apr 25, 2012 at 12:58 PM, Aaron Coburn <acob...@amherst.edu> wrote:
> 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-----