VMware ESX hypervisor driver

The libvirt VMware ESX driver can manage VMware ESX/ESXi 3.5/4.0 and VMware GSX 2.0, also called VMware Server 2.0, and possibly later versions.

Deployment pre-requisites

None. Any out-of-the-box installation of ESX/GSX should work. No preparations are required on the server side, no libvirtd must be installed on the ESX server. The driver uses version 2.5 of the remote, SOAP based VMware Virtual Infrastructure API to communicate with the ESX server, like the VMware Virtual Infrastructure Client does. Since version 4.0 this API is called VMware vSphere API.

Connections to the VMware ESX driver

Some example remote connection URIs for the driver are: 

esx://example.com                  (ESX over HTTPS)
gsx://example.com                  (GSX over HTTPS)
esx://example.com/?transport=http  (ESX over HTTP)
esx://example.com/?no_verify=1     (ESX over HTTPS, but doesn't verify the server's SSL certificate)

URI Format

URIs have this general form ('[...]' marks an optional part). 

type://[username@]hostname[:port]/[?extraparameters]

The type:// is either esx:// or gsx:// and the driver selects the default port depending on it. For ESX the default HTTPS port is 443, for GSX it is 8333. If the port parameter is given, it overrides the default port.

Extra parameters

Extra parameters can be added to a URI as part of the query string (the part following '?'). The driver understands the extra parameters shown below.

Name Values Meaning
transport http or https Overrides the default HTTPS transport. For ESX the default HTTP port is 80, for GSX it is 8222.
vcenter Hostname of a VMware vCenter In order to perform a migration the driver needs to know the VMware vCenter for the ESX server.
no_verify 0 or 1 If set to 1, this disables libcurl client checks of the server's SSL certificate. The default value it 0.

Authentication

In order to perform any useful operation the driver needs to log into the ESX server. Therefore, only virConnectOpenAuth can be used to connect to an ESX server, virConnectOpen and virConnectOpenReadOnly don't work. To log into an ESX server or vCenter the driver will request credentials using the callback passed to the virConnectOpenAuth function. The driver passes the hostname as challenge parameter to the callback. This enables the callback to distinguish between requests for ESX server and vCenter.

Note: During the ongoing driver development, testing is done using an unrestricted root account. Problems may occur if you use a restricted account. Detailed testing with restricted accounts has not been done yet.

Specialties in the domain XML config

There are several specialties in the domain XML config for ESX domains.

Restrictions

There are some restrictions for some values of the domain XML config. The driver will complain if this restrictions are violated.

Datastore references

Storage is managed in datastores. VMware uses a special path format to reference files in a datastore. Basically, the datastore name is put into squared braces in front of the path. 

[datastore] directory/filename

To define a new domain the driver converts the domain XML into a VMware VMX file and uploads it to a datastore known to the ESX server. Because multiple datastores may be known to an ESX server the driver needs to decide to which datastores the VMX file should be uploaded. The driver deduces this information from the path of the source of the first file-based harddisk listed in the domain XML.

Available hardware

VMware ESX supports different models of SCSI controllers and network cards.

SCSI controller models

buslogic
BusLogic SCSI controller for older guests.
lsilogic
LSI Logic SCSI controller for recent guests.

Here a domain XML snippet: 

    ...
    <disk type='file' device='disk'>
      <driver name='lsilogic'/>
      <source file='[local-storage] Fedora11/Fedora11.vmdk'/>
      <target dev='sda' bus='scsi'/>
    </disk>
    ...

Network card models

vlance
AMD PCnet32 network card for older guests.
vmxnet, vmxnet3
Special VMware VMXnet network card, requires VMware tools inside the guest.
e1000
Intel E1000 network card for recent guests.

Here a domain XML snippet: 

    ...
    <interface type='bridge'>
      <mac address='00:50:56:25:48:c7'/>
      <source bridge='VM Network'/>
      <model type='e1000'/>
    </interface>
    ...

Import and export of domain XML configs

The ESX driver currently supports a native config format known as vmware-vmx to handle VMware VMX configs.

Converting from VMware VMX config to domain XML config

The virsh domxml-from-native provides a way to convert an existing VMware VMX config into a domain XML config that can then be used by libvirt. 

$ cat > demo.vmx << EOF
#!/usr/bin/vmware
config.version = "8"
virtualHW.version = "4"
floppy0.present = "false"
nvram = "Fedora11.nvram"
deploymentPlatform = "windows"
virtualHW.productCompatibility = "hosted"
tools.upgrade.policy = "useGlobal"
powerType.powerOff = "default"
powerType.powerOn = "default"
powerType.suspend = "default"
powerType.reset = "default"
displayName = "Fedora11"
extendedConfigFile = "Fedora11.vmxf"
scsi0.present = "true"
scsi0.sharedBus = "none"
scsi0.virtualDev = "lsilogic"
memsize = "1024"
scsi0:0.present = "true"
scsi0:0.fileName = "/vmfs/volumes/498076b2-02796c1a-ef5b-000ae484a6a3/Fedora11/Fedora11.vmdk"
scsi0:0.deviceType = "scsi-hardDisk"
ide0:0.present = "true"
ide0:0.clientDevice = "true"
ide0:0.deviceType = "cdrom-raw"
ide0:0.startConnected = "false"
ethernet0.present = "true"
ethernet0.networkName = "VM Network"
ethernet0.addressType = "vpx"
ethernet0.address = "00:50:56:91:48:c7"
chipset.onlineStandby = "false"
guestOSAltName = "Red Hat Enterprise Linux 5 (32-Bit)"
guestOS = "rhel5"
uuid.bios = "50 11 5e 16 9b dc 49 d7-f1 71 53 c4 d7 f9 17 10"
snapshot.action = "keep"
sched.cpu.min = "0"
sched.cpu.units = "mhz"
sched.cpu.shares = "normal"
sched.mem.minsize = "0"
sched.mem.shares = "normal"
toolScripts.afterPowerOn = "true"
toolScripts.afterResume = "true"
toolScripts.beforeSuspend = "true"
toolScripts.beforePowerOff = "true"
scsi0:0.redo = ""
tools.syncTime = "false"
uuid.location = "56 4d b5 06 a2 bd fb eb-ae 86 f7 d8 49 27 d0 c4"
sched.cpu.max = "unlimited"
sched.swap.derivedName = "/vmfs/volumes/498076b2-02796c1a-ef5b-000ae484a6a3/Fedora11/Fedora11-7de040d8.vswp"
tools.remindInstall = "TRUE"
EOF

$ virsh -c esx://example.com domxml-from-native vmware-vmx demo.vmx
Enter username for example.com [root]:
Enter root password for example.com:
<domain type='vmware'>
  <name>Fedora11</name>
  <uuid>50115e16-9bdc-49d7-f171-53c4d7f91710</uuid>
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='i686'>hvm</type>
  </os>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <disk type='file' device='disk'>
      <driver name='lsilogic'/>
      <source file='[local-storage] Fedora11/Fedora11.vmdk'/>
      <target dev='sda' bus='scsi'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:50:56:91:48:c7'/>
      <source bridge='VM Network'/>
    </interface>
  </devices>
</domain>

Converting from domain XML config to VMware VMX config

The virsh domxml-to-native provides a way to convert a domain XML config into a VMware VMX config. 

$ cat > demo.xml << EOF
<domain type='vmware'>
  <name>Fedora11</name>
  <uuid>50115e16-9bdc-49d7-f171-53c4d7f91710</uuid>
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64'>hvm</type>
  </os>
  <devices>
    <disk type='file' device='disk'>
      <driver name='lsilogic'/>
      <source file='[local-storage] Fedora11/Fedora11.vmdk'/>
      <target dev='sda' bus='scsi'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:50:56:25:48:c7'/>
      <source bridge='VM Network'/>
    </interface>
  </devices>
</domain>
EOF

$ virsh -c esx://example.com domxml-to-native vmware-vmx demo.xml
Enter username for example.com [root]:
Enter root password for example.com:
config.version = "8"
virtualHW.version = "4"
guestOS = "other-64"
uuid.bios = "50 11 5e 16 9b dc 49 d7-f1 71 53 c4 d7 f9 17 10"
displayName = "Fedora11"
memsize = "1024"
numvcpus = "1"
scsi0.present = "true"
scsi0.virtualDev = "lsilogic"
scsi0:0.present = "true"
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.fileName = "/vmfs/volumes/local-storage/Fedora11/Fedora11.vmdk"
ethernet0.present = "true"
ethernet0.networkName = "VM Network"
ethernet0.connectionType = "bridged"
ethernet0.addressType = "static"
ethernet0.address = "00:50:56:25:48:C7"

Example domain XML configs

Fedora11 on x86_64

<domain type='vmware'>
  <name>Fedora11</name>
  <uuid>50115e16-9bdc-49d7-f171-53c4d7f91710</uuid>
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64'>hvm</type>
  </os>
  <devices>
    <disk type='file' device='disk'>
      <source file='[local-storage] Fedora11/Fedora11.vmdk'/>
      <target dev='sda' bus='scsi'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:50:56:25:48:c7'/>
      <source bridge='VM Network'/>
    </interface>
  </devices>
</domain>

Migration

A migration cannot be initiated on an ESX server directly, a VMware vCenter is necessary for this. The vCenter hostname has to be passed to the driver via the vcenter query parameter. 

esx://example.com/?vcenter=example-vcenter.com

Here an example how to migrate the domain Fedora11 from ESX server example-src.com to ESX server example-dst.com involving vCenter example-vcenter.com using virsh. 

$ virsh -c esx://example-src.com/?vcenter=example-vcenter.com migrate Fedora11 esx://example-dst.com/?vcenter=example-vcenter.com
Enter username for example-src.com [root]:
Enter root password for example-src.com:
Enter username for example-vcenter.com [administrator]:
Enter administrator password for example-vcenter.com:
Enter username for example-dst.com [root]:
Enter root password for example-dst.com:
Enter username for example-vcenter.com [administrator]:
Enter administrator password for example-vcenter.com:

Scheduler configuration

The driver exposes the ESX CPU scheduler. The parameters listed below are available to control the scheduler.

reservation
The amount of CPU resource in MHz that is guaranteed to be available to the domain. Valid values are 0 and greater.
limit
The CPU utilization of the domain will be limited to this value in MHz, even if more CPU resources are available. If the limit is set to -1, the CPU utilization of the domain is unlimited. If the limit is not set to -1, it must be greater than or equal to the reservation.
shares
Shares are used to determine relative CPU allocation between domains. In general, a domain with more shares gets proportionally more of the CPU resource. Valid values are 0 and greater. The special values -1, -2 and -3 represent the predefined shares level low, normal and high.

VMware tools

Some actions require installed VMware tools. If the VMware tools are not installed in the guest and one of the actions below is to be performed the ESX server raises an error and the driver reports it.

Links