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.

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.

Reply via email to