On Jan 31, 2012, at 9:31 AM, Sean Dilda wrote:

> On 1/31/12 8:46 AM, Aaron Coburn wrote:
>> Sean,
>>> You can use the vsphere api to get the file names if you really need
>>> them.
>> This is true, and that may very well be the better approach. I am not
>> entirely happy with the method I described earlier, which relies on my
>> own observation of an apparently undocumented behavior of VMware. There
>> is, for instance, no guarantee that VMware won't start truncating
>> virtual disk filenames at 28 characters at some point in the future.
>> On the other hand, if VMware is allowed to (arbitrarily?) truncate
>> values that follow an otherwise fairly strict VCL naming convention,
>> there could be negative implications for subsequent revisions of a given
>> image. Imagine, for instance, a situation with multiple management nodes
>> or at least multiple VM host infrastructures. If one infrastructure
>> truncates the imagename value, what happens if that image is revised
>> again later in a different VM infrastructure (possibly, even, with a
>> different VMware API being used). Would the new imagename be generated
>> properly? (This example is not at all hypothetical, given the way we
>> have set up our VCL).
>> Another potential problem is that the VCL database enforces unique
>> imagename values. The VCL, however, would not be able to enforce this if
>> VMware is allowed to truncate these values according to its own opaque
>> contrivance. In fact, it is entirely is possible to construct a scenario
>> in which different versions of the same base image are assigned
>> identical paths in a VMware datastore. Aside from not suiting the
>> database schema particularly well, this could, potentially, overwrite
>> another revision of the same image stored in the VCL repository path.
> I agree completely with the concerns you mentioned.  That's why I suggested 
> the APIs.  VMware thinks of itself as the only one managing or caring about 
> filenames.  Thus, I think VCL trying to enforce filenames is going to lead to 
> nothing but problems.  Instead I think it should only care about the VM's 
> name and let VMware figure out the filenames.

I, too, think this approach would be the best for a vCenter-based 
infrastructure -- that is, a setup where the VCL keeps track of the names of 
the virtual disks, but doesn't enforce a particular format. What I don't know 
is what implications that would have on a VMware setup that uses the VIM_SSH or 
VIX_API modules -- code with which I am almost entirely unfamiliar. I also 
don't know how this would affect how images are shared using the image library 
features of the VCL. We are moving toward a multi-node, physically distributed 
architecture using a shared image library, but we are not there yet, so I am 
only vaguely aware of how this is implemented. Perhaps someone who uses the 
image library to share images between management nodes could chime in?

>>> Why does vcl write its own vmx instead of using the apis? vSphere
>>> expects programs to use the apis, not to hand craft files.
>> I completely agree. I must admit that, when I wrote the vCenter
>> provisioning module, I tried to use as much existing VCL code as
>> possible. Rather than reimplementing everything to use vSphere managed
>> objects, I rewrote only what appeared to be necessary. So for example,
>> in VMWare.pm, the 'load' subroutine calls 'prepare_vmx', which generates
>> a vmx text file on the management node. This file is then transferred
>> via VIExt::http_put_file into the VMware infrastructure. While I managed
>> to make this sequence of commands work in the context of vCenter, I
>> agree that it would be far better to implement this differently for a
>> vCenter provisioning module.
>> Within the context of the current VMware module design, the
>> communication with the VM host is expected to occur by means of the API
>> object (i.e. $self->{api}). So for instance, the creation of the virtual
>> machine via vCenter would logically occur when
>> $self->api->vm_register(…) is called. The call to $self->prepare_vmx in
>> the preceding lines would be superfluous, and there would be no need for
>> that method to write and then transfer a vmx file to the VM host
>> infrastructure. In short, there would need to be some way for the
>> vCenter API to circumvent that sequence of commands.
>> Since all the VMware API modules inherit from the base VMware class,
>> there could be a new method, such as 'require_prepare_vmx', for which
>> the VMware class provides a simple default implementation:
> I haven't had a chance to look at the code, but would it make more sense for 
> the vSphere module to overwrite the prepare_vmx function with 'return 1;' ?  
> That way it doesn't happen for vSphere, but no code in higher modules needs 
> to be modified.

That would work with a simple change in the VMware module. Because the 
prepare_vmx function is executed in the context of the VMware base object -- 
rather than the API -- the line in VMware.pm:


would need to be changed to:


If I understand the code correctly, any VMware API in use will fall back on the 
prepare_vmx subroutine implemented in the (parent) VMware module. Then, the 
vCenter module could implement its own short-circuited, { return 1; } block.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to