* src/esx/esx_vi_types.c: Include <stdint.h>.

* src/conf/domain_conf.c: add defaults for the video device
* src/esx/esx_vmx.[ch]: add VNC support to the VMX handling
* tests/vmx2xmltest.c, tests/xml2vmxtest.c: add tests for the VNC support

Before the driver assumed that there is always a domain part. That's
not true. Now the domain part is handled as optional.

This stops libvirt from probing for a libvirtd on the ESX server and
sets the base for the implementation of the secondary drivers.

Currently only the faultcode and faultstring are deserialized, the
detail part is ignored. The implementation of many new SOAP types
would be necessary to deserialize the detail part correctly. As an
intermediate solution the raw response is dumped to the debug log.

The MAC addresses with 00:50:56 prefix are split into several ranges:

  00:50:56:00:00:00 - 00:50:56:3f:ff:ff  'static' range (manually assigned)
  00:50:56:80:00:00 - 00:50:56:bf:ff:ff  'vpx' range (assigned by a VI Client)

Erroneously the 'vpx' range was assumed to be larger and to occupy the
remaining addresses of the 00:50:56 prefix that are not part of the 'static'
range.

00:50:56 was used as prefix for generated MAC addresses, this is not possible
anymore, because there are gaps in the allowed ranges. Therefore, change the
prefix to 00:0c:29 which is the prefix for auto generated MAC addresses anyway.

Allow arbitrary MAC addresses to be used and set the checkMACAddress VMX option
to false in case the MAC address doesn't fall into any predefined range.

* docs/drvesx.html.in: update website accordingly
* src/esx/esx_driver.c: set the auto generation prefix to 00:0c:29
* src/esx/esx_vmx.c: fix MAC address range handling and allow arbitrary MAC
  addresses
* tests/vmx2xml*, tests/xml2vmx*: add some basic MAC address range tests

The data passed to the callback is not guaranteed to be zero terminated,
take care of that by coping the data and adding a zero terminator.

Also dump the data for other types than CURLINFO_TEXT.

Set CURLOPT_VERBOSE to 1 so the debug callback is called when enabled.

A domain with virtualHW version 4 is allowed on an ESX 4.0 server.
If a domain is migrated from an ESX 3.5 server to an ESX 4.0 server
then the virtualHW version stays the same. So a ESX 4.0 server can
host domains with virtualHW version 4.

Alter the offending variable names to fix this.

Set up the types for the domainMemoryStats function and insert it into the
virDriver structure definition.  Because of static initializers, update
every driver and set the new field to NULL.

* include/libvirt/libvirt.h.in: new API
* src/driver.h src/*/*_driver.c src/vbox/vbox_tmpl.c: add the new
  entry to the driver structure
* python/generator.py: fix compiler errors, the actual python binding is
  implemented later

If a virtual machine is destroyed on a ESX server then immediately
undefining this virtual machine on a vCenter may fail, because the
vCenter has not been informed about the status change yet. Therefore,
destroy a virtual machine on a vCenter if available, so the vCenter
is up-to-date when the virtual machine should be undefined.

Undefining a virtual machine on an ESX server leaves a orphan on the
vCenter behind. So undefine a virtual machine on a vCenter if available
to fix this problem.

Also move XPath expression composition into esxVI_Context_Execute().

If an ESX host is managed by a vCenter, it knows the IP address of the
vCenter. Setting the vCenter query parameter to * allows to connect to the
vCenter known to an ESX host without the need to specify its IP address
or hostname explicitly.

esxDomainLookupByUUID() and esxDomainIsActive() lookup a domain by asking
ESX for all known domains and searching manually for the one with the
matching UUID. This is inefficient. The VI API allows to lookup by UUID
directly: FindByUuid().

* src/esx/esx_driver.c: change esxDomainLookupByUUID() and esxDomainIsActive()
  to use esxVI_LookupVirtualMachineByUuid(), also reorder some functions to
  keep them in sync with the driver struct

Questions can block tasks, to handle them automatically the driver can answers
them with the default answer. The auto_answer query parameter allows to enable
this automatic question handling.

* src/esx/README: add a detailed explanation for automatic question handling
* src/esx/esx_driver.c: add automatic question handling for all task related
  driver functions
* src/esx/esx_util.[ch]: add handling for the auto_answer query parameter
* src/esx/esx_vi.[ch], src/esx/esx_vi_methods.[ch], src/esx/esx_vi_types.[ch]:
  add new VI API methods and types and additional helper functions for
  automatic question handling

* src/driver.h: add an extra entry point in the structure
* src/esx/esx_driver.c src/lxc/lxc_driver.c src/opennebula/one_driver.c
  src/openvz/openvz_driver.c src/phyp/phyp_driver.c src/qemu/qemu_driver.c
  src/remote/remote_driver.c src/test/test_driver.c src/uml/uml_driver.c
  src/vbox/vbox_tmpl.c src/xen/xen_driver.c: add NULL entry points for
  all drivers

* src/esx/esx_vi.c (esxVI_List_CastFromAnyType): For invalid
inputs, fail right away.  Do not "goto failure" where a NULL
input pointer would be dereferenced.

* src/esx/esx_util.c (esxUtil_ParseDatastoreRelatedPath): Return
right away for invalid inputs, rather than using them (which would
dereference NULL pointers) in clean-up code.

This also fixes a NULL-deref of virtualDev in esxVMX_ParseSCSIController
found by Jim Meyering.

Replace free(virBufferContentAndReset()) with virBufferFreeAndReset().
Update documentation and replace all remaining calls to free() with
calls to VIR_FREE(). Also add missing calls to virBufferFreeAndReset()
and virReportOOMError() in OOM error cases.

esxVMX_IndexToDiskName handles indices up to 701. This limit comes
from a mapping gap in virDiskNameToIndex:

  sdzy -> 700
  sdzz -> 701
  sdaaa -> 728
  sdaab -> 729

This line in virDiskNameToIndex causes this gap:

  idx = (idx + i) * 26;

Fixing it by altering this line to:

  idx = (idx + (i < 1 ? 0 : 1)) * 26;

Also add a new version of virIndexToDiskName that handles the inverse
mapping for arbitrary indices.

* src/esx/esx_vmx.[ch]: remove esxVMX_IndexToDiskName
* src/util/util.[ch]: add virIndexToDiskName and fix mapping gap
* tests/esxutilstest.c: update test to verify that the gap is fixed

VMware uses two MAC address prefixes: 00:0c:29 and 00:50:56. The 00:0c:29
prefix is used for ESX server generated addresses. The 00:50:56 prefix is
split into two parts. MAC addresses above 00:50:56:3f:ff:ff are generated
by a vCenter. The rest of the 00:50:56 prefix can be assigned manually.
Any MAC address within the 00:0c:29 and 00:50:56 prefix can be specified
in a domain XML config and the driver will handle the details internally.

* src/esx/esx_vmx.c: fix MAC address formatting
* tests/xml2vmxdata/*: update test files accordingly

In commit 3c80fac2 'vmxnet3' handling
was added to esxVMX_ParseEthernet(), but not to the inverse function
esxVMX_FormatEthernet().

* docs/drivers.html.in: list the ESX driver
* docs/drvesx.html.in: the new ESX driver documentation
* docs/hvsupport.html.in: add the ESX driver to the matrix
* docs/index.html.in, docs/sitemap.html.in: list the ESX driver
* src/esx/esx_driver.c: fix and cleanup some comments