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

Reply via email to