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:
$self->prepare_vmx
would need to be changed to:
$self->api->prepare_vmx
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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
