The vSphere SDK is used within the VCL code to manage vCenter. As Aaron C. discovered and solved, the SDK imposes some name length limits when copying/moving vmdk's on vCenter. To work around this, the code shortens the image name. The image name in the database is updated if the name is shortened during an image capture.
This causes a few problems including the currentimage.txt problem described in https://issues.apache.org/jira/browse/VCL-630. Other problems are caused when there is a mix of vCenter and standalone hosts. We have one vCenter environment for a special project and many other standalone ESXi hosts spread across a few datacenters. The vCenter environment needs access to the existing images and occasionally images created on vCenter need to be loaded on hosts outside of that environment. This causes problems with images with long names. Scenario: -An image is captured on standalone host with long name -The long image name stored in database -Works fine on all standalone hosts -When loaded on vCenter, the name of the vmdk copied to vCenter's datastore is shortened -Image name stored in database can't be changed to the shortened name or else it will cause problems on the existing standalone hosts. The code will attempt to locate the shortened image name in the standalone hosts' datastores/repositories and reservations will fail because only the long-named image exists. -The image will successfully load the first time on vCenter but fail on subsequent loads. The long name is still stored in the database. The does_image_exist subroutine will determine that the long-named image doesn't exist on vCenter so an attempt to copy the image is repeated. This fails because the vSphere_SDK.pm code attempts to copy it to the shortened name and this already exists. I think I found a solution to these problems by making some changes to the code which allows vmdk's to be copied/renamed on vCenter using long names. The code in vSphere_SDK.pm which actually does the copy/clone is mostly unchanged. It still will shorten the name of the resulting files. If vSphere_SDK.pm::move_virtual_disk can't change the name due to MoveVirtualDisk not being implemented under vCenter it returns false instead of then calling copy_virtual_disk and deleting the original. I made some minor changes so that the vSphere_SDK.pm copy_virtual_disk and move_virtual_disk return the path to the resulting vmdk file. This makes it a little easier to detect if the name had to be changed in the calling subroutine. The rest of the solution actually turned out to be pretty simple using existing code. When VMware.pm::copy_vmdk detects that the name had to be shortened it then calls VMware.pm::move_vmdk. This subroutine will attempt to call vSphere_SDK.pm::move_virtual_disk, which returns false. move_vmdk retrieves the names of all the associated vmdk files and performs regular file renames on them. This works under vCenter -- the naming limitations only apply when using the virtual disk API calls, not for regular files. After renaming the files the vmdk won't work because the descriptor contains the original name. move_vmdk fixes this by retrieving the descriptor contents and replacing the names. The result is a copied or renamed vmdk with the originally requested long name. The image name in the database doesn't need to be changed under any circumstances. I just committed the changes. Please review the changes and test. Environments are different and I didn't test everything on all versions of ESXi/vCenter. Thanks, Andy
