VMware Drivers 3.6
The VMware Drivers enable the management of an OpenNebula cloud based on VMware ESX and/or VMware Server hypervisors. It uses libvirt to invoke the Virtual Infrastructure SOAP API exposed by the VMware hypervisors, and it entails a much better integration and performance than the java based drivers traditionally found in the OpenNebula distribution.
It features a simple configuration process that will leverage the stability, performance and feature set of any existing VMware based OpenNebula cloud.
In order to use the VMware Drivers, some software dependencies have to be met:
DATASTORE
is needed, and it is explained in the TM part of the Configuration section.Optional Requirements. To enable some OpenNebula features you may need:
The creation of a user in the VMware hypervisor is recommended. Go to the Users & Group tab in the VI Client, and create a new user (for instance, “oneadmin”) with the same UID and username as the oneadmin user executing OpenNebula in the front-end. Please remember to give full permissions to this user (Permissions tab).
Since all the available DATASTORES in this version require SSH access, please remember to click the “Grant shell access to this user” checkbox. Also, if we want to use the VMware datastore, we are going to need to add “oneadmin” to the root
group.
The access via SSH needs to be passwordless. Please follow the next steps to configure the ESX node:
For ESX 4.x
For ESX 5.x
<xterm> $ su - $ mkdir /etc/ssh/keys-oneadmin $ chmod 755 /etc/ssh/keys-oneadmin $ su - oneadmin $ vi /etc/ssh/keys-oneadmin/authorized_keys <paste here the contents of the oneadmin's front-end account public key (FE → $HOME/.ssh/id_{rsa,dsa}.pub) and exit vi> $ chmod 600 /etc/ssh/keys-oneadmin/authorized_keys </xterm>
More information on passwordless ssh connections here.
If you plan to use the VMware datastore, a couple of steps remain:
<xterm> $ su $ chmod +s /sbin/vmkfstools </xterm>
In order to use the attach/detach functionality for VM disks, some extra configuration steps are needed.
There are several possible configurations regarding storage. Considerations must be made for the system datastore and for the vmware datastores, which can be configured with different transfer managers: ssh, shared and vmware specific. Please refer to the VMware Datastore guide for more details.
Networking can be used in the two different modes: pre-defined (to use pre-defined port groups) or dynamic (to dynamically create port groups and VLAN tagging). Please refer to the VMware Networking guide for more details.
In order to access running VMs through VNC, the ESX host needs to be configured beforehand, basically to allow VNC inbound connections via their firewall.
In the vSphere client, go to Configuration tab, Software Security Profile, Properties of the firewall (in the right pane) and then tick the “VNC Server” checkbox.
Please follow this guide.
In order to configure OpenNebula to work with the VMware drivers, the following sections need to be uncommented in the /etc/one/oned.conf
file.
#------------------------------------------------------------------------------- # VMware Virtualization Driver Manager Configuration #------------------------------------------------------------------------------- VM_MAD = [ name = "vmm_vmware", executable = "one_vmm_sh", arguments = "-t 15 -r 0 vmware", default = "vmm_exec/vmm_exec_vmware.conf", type = "vmware" ] #------------------------------------------------------------------------------- # VMware Information Driver Manager Configuration #------------------------------------------------------------------------------- IM_MAD = [ name = "im_vmware", executable = "one_im_sh", arguments = "-t 15 -r 0 vmware" ] #------------------------------------------------------------------------------- #------------------------------------------------------------------------------- # Transfer Manager Driver Configuration #------------------------------------------------------------------------------- TM_MAD = [ executable = "one_tm", arguments = "-t 15 -d dummy,lvm,shared,ssh,vmware,iscsi" ] #------------------------------------------------------------------------------- #------------------------------------------------------------------------------- # Datastore Manager Driver Configuration #------------------------------------------------------------------------------- DATASTORE_MAD = [ executable = "one_datastore", arguments = "-t 15 -d fs,vmware,iscsi" ] #-------------------------------------------------------------------------------
The configuration attributes for the VMware drivers are set in the /etc/one/vmwarerc
file. In particular the following values can be set:
SCHEDULER OPTIONS | DESCRIPTION |
---|---|
:libvirt_uri | used to connect to VMware through libvirt. When using VMware Server, the connection string set under LIBVIRT_URI needs to have its prefix changed from esx to gsx |
:username | username to access the VMware hypervisor |
:password | password to access the VMware hypervisor |
:datacenter | (only for vMotion) name of the datacenter where the hosts have been registered. |
:vcenter | (only for vMotion) name or IP of the vCenter that manage the ESX hosts |
Example of the configuration file:
:libvirt_uri: "esx://@HOST@/?no_verify=1&auto_answer=1" :username: "oneadmin" :password: "mypass" :datacenter: "ha-datacenter" :vcenter: "London-DC"
Finally you need to set the name of the system datastore to be used in the vSphere hosts in /etc/one/vmm_exec/vmm_exec_vmware.conf
. More details on datastores for VMware here.
The physical hosts containing the VMware hypervisors need to be added with the appropriate VMware Drivers. If the box running the VMware hypervisor is called, for instance, esx-host, the host would need to be registered with the following command (dynamic netwotk mode):
$ onehost create esx-host -i im_vmware -v vmm_vmware -n vmware
or for pre-defined networking
$ onehost create esx-host -i im_vmware -v vmm_vmware -n dummy
The attach/detach functionality needs some special configuration both in the front-end and the worker node.
/etc/oned.conf
, the variable SCRIPTS_REMOTE_DIR
should point to /tmp/one
For ESX > 5.0
<xterm> $ su $ chmod +s /bin/vim-cmd </xterm>
Due to conventions adopted by OpenNebula (mainly, having always the context disk placed as the second disk), the first new disk will be assigned the DISK_ID
of 2 (assuming that the original VM only has one disk, otherwise it will be # DISKS + 1), the second added disk will have DISK_ID
of 3 and so on. This is specially important for the detach functionality.
Please refer to the VMware Networking guide for the Virtual Network attributes supported for VMware-based dataceneters.
The Datastores subsystem introduced in OpenNebula v3.4 needs to be used in order to register images in OpenNebula catalog. .
To register an existing VMware disk you need to:
NAME = MyVMwareDisk PATH =/absolute/path/to/disk/folder TYPE = OS
Once registered the image can be used as any other image in the OpenNebula system as described in the Virtual Machine Images guide.
Due to the different tools available in the front-end and the ESX hosts, there is different possibilities at the time of creating DATABLOCKS or volatile disks, in terms of available formats that can be enforce to the newly created disks:
DATABLOCKS
New disks created in a particular datastore are created in the front-end, so the template of the DATABLOCK can reference in the FSTYPE attribute any value understood by mkfs unix command.
VOLATILE DISKS
At the time of defining a VM, a volatile disk can be described, which will be created in the remote ESX host. This is true for disks defined in the VM template, and also for the file needed in the “onevm attachdisk” operation. Here, it is not possible to format the disk, so it will appear as a raw device on the guest, which will then need to be formatted. Possible values for the FORMAT attribute (more info on this here):
Following the two last sections, we can use a template for a VMware VM like:
NAME = myVMwareVM CPU = 1 MEMORY = 256 DISK = [IMAGE_ID="7"] NIC = [NETWORK="public"]
The VMware Drivers consists of three drivers, with their corresponding files:
/var/lib/one/remotes/vmm/vmware
: commands executed to perform actions./var/lib/one/remotes/im/vmware.d
: vmware IM probes./usr/lib/one/tm_commands
: commands executed to perform transfer actions.And the following driver configuration files:
/etc/one/vmm_exec/vmm_exec_vmware.conf
: This file is home for default values for domain definitions (in other words, OpenNebula templates). For example, if the user wants to set a default value for CPU requirements for all of their VMware domain definitions, simply edit the /etc/one/vmm_exec/vmm_exec_vmware.conf
file and set a CPU=0.6
into it. Now, when defining a template to be sent to a VMware resource, the user has the choice of “forgetting” to set the CPU requirement, in which case it will default to 0.6.
It is generally a good idea to place defaults for the VMware-specific attributes, that is, attributes mandatory for the VMware hypervisor that are not mandatory for other hypervisors. Non mandatory attributes for VMware but specific to them are also recommended to have a default.
/etc/one/tm_vmware/tm_vmware.conf
: This files contains the scripts tied to the different actions that the TM driver can deliver. You can here deactivate functionality like the DELETE action (this can be accomplished using the dummy tm driver, dummy/tm_dummy.sh) or change the default behavior.More generic information about drivers: