* src/qemu/qemu_driver.c: The 'if' statement is supposed to check return
  value of pci = pciGetDevice(conn, ...); , but check uses if (!dev),
  fix it

Enable virDomainMemoryStats in the python API.  dom.memoryStats() will return a
dictionary containing the supported statistics.  A dictionary is required
because the meaining of each quantity cannot be inferred from its index in a
list.

* python/generator.py: reenable bindings for this entry point
* python/libvirt-override-api.xml python/libvirt-override.c: the
  generator can't handle this new function, add the new binding,
  and the XML description

Define a new command 'dommemstats' to report domain memory statistics.  The
output format is inspired by 'domblkstat' and 'domifstat' and consists of
tag/value pairs, one per line.  The command can complete successfully and
print no output if virDomainMemoryStats is supported by the driver, but not
the guest operating system.

Sample output:
swap_in 0
swap_out 0
major_fault 54
minor_fault 58259
unused 487680
available 502472

All stats referring to a quantity of memory (eg. all above except major and
minor faults) represent the quantity in KBytes.

* tools/virsh.c: implements the new command

Use a dynamically sized xdr_array to pass memory stats on the wire.  This
supports the addition of future memory stats and reduces the message size
since only supported statistics are returned.

* src/remote/remote_protocol.x: provide defines for the new entry point
* src/remote/remote_driver.c daemon/remote.c: implement the client and
  server side
* daemon/remote_dispatch_args.h daemon/remote_dispatch_prototypes.h
  daemon/remote_dispatch_ret.h daemon/remote_dispatch_table.h
  src/remote/remote_protocol.c src/remote/remote_protocol.h: generated
  stubs

Support for memory statistics reporting is accepted for qemu inclusion.
Statistics are reported via the monitor command 'info balloon' as a comma
seprated list:

(qemu) info balloon
balloon: actual=1024,mem_swapped_in=0,mem_swapped_out=0,major_page_faults=88,minor_page_faults=105535,free_mem=1017065472,total_mem=1045229568

Libvirt, qemu, and the guest operating system may support a subset of the
statistics defined by the virtio spec.  Thus, only statistics recognized by
components will be reported.

* src/qemu/qemu_driver.c src/qemu/qemu_monitor_text.[ch]: implement the
  new entry point by using info balloon monitor command

* src/libvirt.c: implement the main entry point
* src/libvirt_public.syms: add it to the exported symbols

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

Commit 33a198c1 increased the gcrypt
version requirement to 1.4.2 because the GCRY_THREAD_OPTION_VERSION
define was added in this version.

The configure script doesn't check for the gcrypt version. To support
gcrypt versions < 1.4.2 change the virTLSThreadImpl initialization
to use GCRY_THREAD_OPTION_VERSION only if it's defined.

* configure.in: If you pass libraries in the LDFLAGS variable, and then
  try AC_CHECK_FUNCS to find whether a function is present or not,
  it'll fail badly when using the --as-needed linker flag. Instead,
  pass the libraries through the LIBS library, so that they are passed
  after the conftest.c source file and the tests are done properly.

* configure.in: With the previous logic, if libhal_get_all_devices
  function was not found, HAVE_HAL would be defined for the preprocessor
  but it wouldn't be enabled in automake conditionals, causing the final
  link to fail with missing references to HAL entries.

* tools/virsh.c: provide a way to us teh new API with virsh

* src/qemu/qemu_conf.c src/qemu/qemu_conf.h src/qemu/qemu_driver.c:
  add the new entry point, extend capabilities and code to interract
  with qemu

* src/cpu/cpu_map.xml: newdescription file
* src/Makefile.am: include it in dist

Each driver supporting CPU selection must fill in host CPU capabilities.
When filling them, drivers for hypervisors running on the same node as
libvirtd can use cpuNodeData() to obtain raw CPU data. Other drivers,
such as VMware, need to implement their own way of getting such data.
Raw data can be decoded into virCPUDefPtr using cpuDecode() function.

When implementing virConnectCompareCPU(), a hypervisor driver can just
call cpuCompareXML() function with host CPU capabilities.

For each guest for which a driver supports selecting CPU models, it must
set the appropriate feature in guest's capabilities:

    virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0)

Actions needed when a domain is being created depend on whether the
hypervisor understands raw CPU data (currently CPUID for i686, x86_64
architectures) or symbolic names has to be used.

Typical use by hypervisors which prefer CPUID (such as VMware and Xen):

- convert guest CPU configuration from domain's XML into a set of raw
  data structures each representing one of the feature policies:

    cpuEncode(conn, architecture, guest_cpu_config,
              &forced_data, &required_data, &optional_data,
              &disabled_data, &forbidden_data)

- create a mask or whatever the hypervisor expects to see and pass it
  to the hypervisor

Typical use by hypervisors with symbolic model names (such as QEMU):

- get raw CPU data for a computed guest CPU:

    cpuGuestData(conn, host_cpu, guest_cpu_config, &data)

- decode raw data into virCPUDefPtr with a possible restriction on
  allowed model names:

    cpuDecode(conn, guest, data, n_allowed_models, allowed_models)

- pass guest->model and guest->features to the hypervisor

* src/cpu/cpu.c src/cpu/cpu.h src/cpu/cpu_generic.c
  src/cpu/cpu_generic.h src/cpu/cpu_map.c src/cpu/cpu_map.h
  src/cpu/cpu_x86.c src/cpu/cpu_x86.h src/cpu/cpu_x86_data.h
* configure.in: check for CPUID instruction
* src/Makefile.am: glue the new files in
* src/libvirt_private.syms: add new private symbols
* po/POTFILES.in: add new cpu files containing translatable strings

* src/remote/remote_driver.c: add the new entry point

* src/remote/remote_protocol.x: update with new entry point
* daemon/remote.c: add the new server dispatcher
* daemon/remote_dispatch_args.h daemon/remote_dispatch_prototypes.h
  daemon/remote_dispatch_ret.h daemon/remote_dispatch_table.h
  src/remote/remote_protocol.c src/remote/remote_protocol.h: regenerated

* src/libvirt.c: adds the public entry point virConnectCompareCPU()

* 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

* include/libvirt/libvirt.h.in: add it in the public API as
  well as the new flags
* src/libvirt_public.syms: export it

* po/POTFILES.in: adds src/conf/cpu_conf.c in teh set of files with
  translatable content
* src/conf/cpu_conf.c: remove an unused include

* include/libvirt/virterror.h src/util/virterror.c: add new domain
  VIR_FROM_CPU for errors
* src/conf/cpu_conf.c src/conf/cpu_conf.h: new parsing module
* src/Makefile.am proxy/Makefile.am: include new files
* src/conf/capabilities.[ch] src/conf/domain_conf.[ch]: reference
  new code
* src/libvirt_private.syms: private export of new entry points

XML schema for CPU flags

Firstly, CPU topology and model with optional features have to be
advertised in host capabilities:

    <host>
        <cpu>
            <arch>ARCHITECTURE</arch>
            <features>
                <!-- old-style features are here -->
            </features>
            <model>NAME</model>
            <topology sockets="S" cores="C" threads="T"/>
            <feature name="NAME"/>
        </cpu>
        ...
    </host>

Secondly, drivers which support detailed CPU specification have to
advertise
it in guest capabilities:

    <guest>
    ...
    <features>
            <cpuselection/>
        </features>
    </guest>

And finally, CPU may be configured in domain XML configuration:

<domain>
    ...
    <cpu match="MATCH">
        <model>NAME</model>
        <topology sockets="S" cores="C" threads="T"/>
        <feature policy="POLICY" name="NAME"/>
    </cpu>
</domain>

Where MATCH can be one of:
    - 'minimum'     specified CPU is the minimum requested CPU
    - 'exact'       disable all additional features provided by host CPU
    - 'strict'      fail if host CPU doesn't exactly match

POLICY can be one of:
    - 'force'       turn on the feature, even if host doesn't have it
    - 'require'     fail if host doesn't have the feature
    - 'optional'    match host
    - 'disable'     turn off the feature, even if host has it
    - 'forbid'      fail if host has the feature

'force' and 'disable' policies turn on/off the feature regardless of its
availability on host. 'force' is unlikely to be used but its there for
completeness since Xen and VMWare allow it.

'require' and 'forbid' policies prevent a guest from being started on a host
which doesn't/does have the feature. 'forbid' is for cases where you disable
the feature but a guest may still try to access it anyway and you don't want
it to succeed.

'optional' policy sets the feature according to its availability on host.
When a guest is booted on a host that has the feature and then migrated to
another host, the policy changes to 'require' as we can't take the feature
away from a running guest.

Default policy for features provided by host CPU but not specified in domain
configuration is set using match attribute of cpu tag. If 'minimum' match is
requested, additional features will be treated as if they were specified
with 'optional' policy. 'exact' match implies 'disable' policy and 'strict'
match stands for 'forbid' policy.

* docs/schemas/capability.rng docs/schemas/domain.rng: extend the
  RelaxNG schemas to add CPU flags support

GNUTLS uses gcrypt for its crypto functions. gcrypt requires
that the app/library initializes threading before using it.
We don't want to force apps using libvirt to know about
gcrypt, so we make virInitialize init threading on their
behalf. This location also ensures libvirtd has initialized
it correctly. This initialization is required even if libvirt
itself were only using one thread, since another non-libvirt
library (eg GTK-VNC) could also be using gcrypt from another
thread

* src/libvirt.c: Register thread functions for gcrypt
* configure.in: Add -lgcrypt to linker flags

* src/storage/storage_driver.c: Fix IsPersistent() and IsActivE()
  methods on storage pools to use 'storagePrivateData' instead
  of 'privateData'. Also fix naming convention of objects

* 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.