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