I agree that an overall naming convention shouldn't be imposed because
of one particular provisioning engine. Your idea of having
copy/move_virtual_disk return the name of the destination disk sounds
like the best approach. I wouldn't have these subroutines edit the
image name in the database, in
Hi, Andy,
> Please feel free to make the changes you described in 1 and 2 to trunk.
Will do.
> 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:
> /vmfs/volumes/datast
Hi Aaron,
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:
/vmfs/volumes/datastore/vmwarewin2008-myrea
I looked through the current code for
VCL::Module::Provisioning::VMware::vSphere_SDK
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
-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 this
release such a