Regarding image/file naming:
I foresaw issues like this when writing VMware.pm.  That's why all of
the naming logic is funneled through the various get_vmdk_* and
get_vmx_* subroutines.  Changes to naming conventions or where files
are saved should (~theoretically~) only involve changing 1 or 2 of
these subroutines.  All of the code in VMware.pm and the API modules
should rely on the get_* subroutines and not try to construct paths.

If vCenter for example goes and renames a vmdk, a small amount of code
could be added to VMware.pm::get_vmdk_file_path():
if ($self->api->can('get_mangled_vmdk_file_path')) {
   $vmdk_file_path = $self->api->get_mangled_vmdk_file_path();
}

This would allow all of the other code to still rely on
get_vmdk_file_path() for returning the correct path.

It shouldn't really matter what you name the image or files.  I wasn't
aware of the character limit.  During image capture, the backend code
could rename the image in the database to something like
vmwarewinxp-82-v3 if necessary.  I'm currently working on the KVM code
to do something like this.  The issue I ran into has to do with the
KVM code being able to load VMware images and then capture new images
or update revisions.  As a result, the updated image shouldn't be
named "vmware<x>-".  I was thinking the backend code could possibly
rename imagerevision.imagename via a update_image_name subroutine.
There may be some gotchas with the web code if you change the format.
Will have to test this.


Linked clones:
Already committed.  I mentioned this earlier in this thread on 8/17.
Yes, there are added dangers with snapshots.  I have added some safety
checks into the code.  A snapshot is taken after a VM is registered
but before it is powered on.  If the snapshot fails, the VM is
immediately deleted to prevent someone from powering it on.  You have
to be very careful when working with the vSphere Client.  If you
delete a linked clone VM it may delete the backing file.


prepare_vmx:
The current VMware code writes the vmx file out and then copies it to
the host for a few reasons:
- This is similar to how the old vmware.pm module did things.  It was
never changed to be purely done through the vSphere SDK/vim-cmd
because it was working.
- I'm not sure if every vmx setting is configurable via the vSphere
SDK/vim-cmd.  There are many undocumented vmx options which can be
useful.

That said, I have nothing against changing anything.  I would like to
keep all of the logic in VMware.pm.  The idea is that the API modules
are basically utility modules which expose functionality.  The
different API modules should be able to be used interchangeably with
the resulting VMs constructed very similarly.  Each subroutine in the
API modules should do a single simple task.  The register_vm
subroutine should do only that, not actually define/construct the VM,
add devices, or other operations.

I'd prefer to add subroutines to the API modules to add devices or
make other VM configuration changes, replacing the vmx file generation
tasks done by prepare_vmx.  There could either be granular subroutines
for the different device types or a single subroutine named something
like 'vmx_add_device' which accepts somewhat elaborate arguments.  It
could be called from a new define_vm subroutine in VMware.pm similar
to:

if ($self->api->can('vmx_add_device')) {
   $self->api->vmx_add_device('virtual_disk' => {
         'vmdk_file_path' => $self->get_vmdk_file_path(),
         'adapter_type' => $self->get_vm_disk_adapter_type()
      }
   );
   # Add other devices...
}
else {
   $self->prepare_vmx().
}

I'm not at all familiar with what needs to be done for vCenter.  Do
you think this would work?

Also, I haven't had a chance to dig through all of vCenter.pm but
there appears to be some duplicated code.  Was everything from
vSphere.pm copied into vCenter.pm or are all of the subroutines in
vCenter.pm ones which you had to modify?  What are the main things you
had to change which didn't work in vSphere.pm?  I'd like to push the
general changes into vSphere.pm and try to keep vCenter.pm small if
possible.

Thanks,
Andy


On Tue, Jan 31, 2012 at 10:14 AM, Aaron Coburn <acob...@amherst.edu> wrote:
>
> 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.
>
>

Reply via email to