VCL-630 & vCenter image renaming

[Andy Kurth <an...@ncsu.edu>]

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