Re: VCL 2.2 with VMware Server 2.x or ESXi 4.x

[Andy Kurth <an...@ncsu.edu>]

I have committed the new VMware code.  It is not quite ready to be tested yet. 
It resides in managementnode/lib/VCL/Module/Provisioning/VMware so that it 
doesn't conflict with the existing VMware modules.  Many things need to be 
documented but here are a few notes:

VMware Support
The code should currently work with VMware Server 2.x and ESX/ESXi as long as 
the product isn't restricted by the licensing mode.  Additional utility modules 
will need to be written to support Server 1.x without VIX installed and "free" 
ESXi with SSH enabled.

VMware.pm
This is the main provisioning module.  It contains subroutines called by VCL 
state modules such as load(), capture(), get_image_size(), etc.  It also 
contains several other helper subroutines.

VM host OS object
An OS object is created when VMware.pm is initialized which is used to control 
the VM host.  This allows the code in Linux.pm and other OS modules to be used 
without duplication for both the OS of the reservation computer and the OS of 
the VM host.  The VM host OS object is accessed/controlled in the same manner as 
the normal OS object for the reservation computer.  This is accomplished by 
creating an additional DataStructure object containing the image and computer 
info of the VM host.  VM host OS functions can be accessed via $self->vmhost_os 
just as the reservation computer OS functions can be accessed via $self->os.

vSphere_SDK.pm and VIX_API.pm
These are utility modules which implement subroutines to utilize the VMware 
API/SDKs.  These modules are used to control the VMs and to control the 
VMware-specific functions on the VM host.  They contain subroutines such as 
get_registered_vms(), vm_register(), vm_power_on(), etc.  These subroutines are 
accessed from VMware.pm via $self->api.  For example, to retrieve an array 
containing the registered vmx paths on the VM host: 
$self->api->get_registered_vms().

vSphere_SDK.pm OS functions
The vShphere_SDK.pm module contains subroutines which allow it to be used as a 
VM host OS module if ESX/ESXi is being used.  In some configurations, the only 
way to access and control the VM host OS is by using the SDK.  For example, the 
vSphere SDK will allow you to determine if a file exists on an ESXi host which 
doesn't have SSH enabled.  A Linux OS module would not be able to do this.

VM Disk Conversion
The code can currently convert virtual disks created for other VMware products 
to a format compatible with ESX.  This should allow existing VMware Server 1.x 
images to be used on an ESX/ESXi host.

VM Naming / Base Image Creation
The code was written to relieve any naming assumptions in order to make base 
image creation easier.  An base image capture should work regardless of the name 
of the VM, vmx file, or vmdk file.  The only requirement is that the management 
node be able to SSH into the VM using the hostname configured in the VCL 
database.  The code retrieves the MAC addresses being used by the VM by 
gathering the networking configuration via SSH.  It then retrieves a list of all 
vmx files and matches up the MAC addresses being used by the VM to the addresses 
configured in a vmx file.  If a single vmx file is found with a matching MAC 
address, the vmdk path is retrieved from the vmx file.

Not done yet:
-Space checking on the VM host.
-retrieve_image subroutine not implemented yet.  I would like to move this up to 
Provisioning.pm as described in VCL-289.
-Semaphores when manipulating shared directories not used yet.  VMware.pm has 
get_lockfile() and release_lockfile() subroutines.  These will be used to ensure 
that only 1 process is manipulating a shared directory at a time.

-Andy


Jose Higino wrote:
> Hi,
> 
> I was wondering if VCL 2.2 ca be used now, because I would like to try out 
> VMware Server 2.x or ESXi 4.x with it.
> 
> Where can I get the code, the SVN repository only has 2.1?
> 
> Regards