[jira] [Reopened] (VCL-630) currentimage.txt name may conflict with imagerevision name, causing unnecessary reloads

["Aaron Coburn (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/VCL-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Coburn reopened VCL-630:
------------------------------


If a new image is captured in a vCenter infrastructure and the name of the virtual disk exceeds 29 characters, the image name is truncated.

If, for instance, the image name (in the database) is:
vmwarewin7-ImageWithAReallyLongName-v0
That image will be stored in a vCenter infrastructure as:
vmwarewin7-ImageWithAReallyLo/vmwarewin7-ImageWithAReallyLo.vmdk

And thereafter any requests for the image will fail in vCenter.

There is code in VCL-2.3 to control for this, but it has been commented out in 2.3.1 to correct for the possibility that an image (with a long name) running in an ESX environment and then transferred to a vCenter infrastructure will cause the name to be truncated in the database. This will cause the existing image to no longer work on the ESX hosts.

I would recommend putting the _clean_vm_name($name) subroutine in the VMware.pm module code. I don't like inflicting vCenter's peculiarities on other VMware hosts, but it doesn't seem to work any other way if the VCL infrastructure uses both ESX and vCenter hosts.
                
> currentimage.txt name may conflict with imagerevision name, causing unnecessary reloads
> ---------------------------------------------------------------------------------------
>
>                 Key: VCL-630
>                 URL: https://issues.apache.org/jira/browse/VCL-630
>             Project: VCL
>          Issue Type: Bug
>          Components: vcld (backend)
>    Affects Versions: 2.3
>         Environment: accessing the first revision of an image on a clustered (vCenter) VMware host. This only affects images whose name (cleaned of non-alphanumeric characters) exceeds 29 characters. 
>            Reporter: Aaron Coburn
>            Assignee: Aaron Coburn
>             Fix For: 2.3.1
>
>
> A few words to provide some background: when the VCL uses a clustered (vCenter) VMware host, one cannot simply copy virtual disks as part of the image capture process; instead, the VM is cloned. This, however, exposed an apparently undocumented feature of VMware in that virtual disk names exceeding 29 characters are silently truncated. This creates significant problems for the VCL. The current solution (for 2.3) is to update the image name in the database after successfully capturing an image. This way, the VCL knows where to find the virtual disk in the VMware datastore.
> The problem with this approach is that this change isn't registered with the system until after the image has been captured. At this point, however, the currentimage.txt file has already been written to the disk and if the name changes ex post facto, then the problem simply re-emerges in a different form when a user makes a reservation for the image.
> Assuming the VM is available and otherwise ready to grant an immediate reservation, the reclaim.pm:process() subroutine checks the VM name listed in the currentimage.txt file and finds a conflict in the name listed on the OS and the name in the database.
> An immediate solution for users is to simply make a new revision of the same image. That second revision will have a shortened name in both currentimage.txt and the imagerevision table.
> There are two ways that this could be correctly solved in the perl code: either by updating the image name earlier in the provisioning module's capture() subroutine or by extracting other information from currentimage.txt, such as imagerevision_id.
> While the first approach would be easier to implement, the second approach seems to be more architecturally sound. That is, rather than relying on a comparison of two strings, the test would be between two integers, one of which is the primary key of the database table in question.
> Any thoughts on the best way to proceed?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira