The virDomainOpenGraphics API allows a libvirt client to pass in
a file descriptor for an open socket pair, and get it connected
to the graphics display of the guest. This is limited to working
with local libvirt hypervisors connected over a UNIX domain
socket, since it will use UNIX FD passing

* include/libvirt/libvirt.h.in: Define virDomainOpenGraphics
* src/driver.h: Define driver for virDomainOpenGraphics
* src/libvirt_public.syms, src/libvirt.c: Entry point for
  virDomainOpenGraphics
* src/libvirt_internal.h: VIR_DRV_FEATURE_FD_PASSING

The previous API addition allowed traversal up the hierarchy;
this one makes it easier to traverse down the hierarchy.

In the python bindings, virDomainSnapshotNumChildren can be
generated, but virDomainSnapshotListChildrenNames had to copy
from the hand-written example of virDomainSnapshotListNames.

* include/libvirt/libvirt.h.in (virDomainSnapshotNumChildren)
(virDomainSnapshotListChildrenNames): New prototypes.
(VIR_DOMAIN_SNAPSHOT_LIST_DESCENDANTS): New flag alias.
* src/libvirt.c (virDomainSnapshotNumChildren)
(virDomainSnapshotListChildrenNames): New functions.
* src/libvirt_public.syms: Export them.
* src/driver.h (virDrvDomainSnapshotNumChildren)
(virDrvDomainSnapshotListChildrenNames): New callbacks.
* python/generator.py (skip_impl, nameFixup): Update lists.
* python/libvirt-override-api.xml: Likewise.
* python/libvirt-override.c
(libvirt_virDomainSnapshotListChildrenNames): New wrapper function.

Add new public api for 'reset'.
It can reset domain immediately without any guest shutdown.
Signed-off-by: NXu He Jie <xuhj@linux.vnet.ibm.com>

Although a client can already obtain a snapshot's parent by
dumping and parsing the xml, then doing a snapshot lookup by
name, it is more efficient to get the parent in one step, which
in turn will make operations that must traverse a snapshot
hierarchy easier to perform.

* include/libvirt/libvirt.h.in (virDomainSnapshotGetParent):
Declare.
* src/libvirt.c (virDomainSnapshotGetParent): New function.
* src/libvirt_public.syms: Export it.
* src/driver.h (virDrvDomainSnapshotGetParent): New callback.

/usr/lib/stdlib.h in Mac OS X and probably also in BSD's
exports this symbol :(

Includes impl of python binding since the generator was not
able to cope.

Note: Requires gendispatch.pl patch from Matthias Bolte

https://www.redhat.com/archives/libvir-list/2011-August/msg01367.html

Set up the types for the block pull functions and insert them into the
virDriver structure definition.  Symbols are exported in this patch to
prevent
documentation compile failures.

* include/libvirt/libvirt.h.in: new API
* src/driver.h: add the new entry to the driver structure
* python/generator.py: fix compiler errors, the actual python bindings
* are
  implemented later
* src/libvirt_public.syms: export symbols
* docs/apibuild.py: Extend 'unsigned long' parameter exception to this
* API

Modifying the xml on either save or restore only gets you so
far - you have to remember to 'virsh dumpxml dom' just prior
to the 'virsh save' in order to have an xml file worth modifying
that won't be rejected due to abi breaks.  To make this more
powerful, we need a way to grab the xml embedded within a state
file, and from there, it's not much harder to also support
modifying a state file in-place.

Also, virDomainGetXMLDesc didn't document its flags.

* include/libvirt/libvirt.h.in (virDomainSaveImageGetXMLDesc)
(virDomainSaveImageDefineXML): New prototypes.
* src/libvirt.c (virDomainSaveImageGetXMLDesc)
(virDomainSaveImageDefineXML): New API.
* src/libvirt_public.syms: Export them.
* src/driver.h (virDrvDomainSaveImageGetXMLDesc)
(virDrvDomainSaveImgeDefineXML): New driver callbacks.

This introduces new API virDomainDestroyFlags to allow
domain destroying with flags, as the existing API virDomainDestroy
misses flags.

The set of flags is defined in virDomainDestroyFlagsValues enum,
which is currently commented, because it is empty.

Calling this API with no flags set (@flags == 0) is equivalent calling
virDomainDestroy.

In order to choose whether to use O_DIRECT when saving a domain image
to a file, we need a new flag.  But virDomainSave was implemented
before our policy of all new APIs having a flag argument.  Likewise
for virDomainRestore when restoring from a file.

The new flag name is chosen as CACHE_BYPASS so as not to preclude
a future solution that uses posix_fadvise once the Linux kernel has
a smarter implementation of that interface.

* include/libvirt/libvirt.h.in (virDomainCreateFlags)
(virDomainCoreDumpFlags): Add a flag.
(virDomainSaveFlags, virDomainRestoreFlags): New prototypes.
* src/libvirt.c (virDomainSaveFlags, virDomainRestoreFlags): New API.
* src/libvirt_public.syms: Export them.
* src/driver.h (virDrvDomainSaveFlags, virDrvDomainRestoreFlags):
New driver callbacks.

This introduces a new API virDomainUndefineFlags to control the
domain undefine process, as the existing API virDomainUndefine
doesn't support flags.

Currently only flag VIR_DOMAIN_UNDEFINE_MANAGED_SAVE is supported.
If the domain has a managed save image, including
VIR_DOMAIN_UNDEFINE_MANAGED_SAVE in @flags will also remove that
file, and omitting the flag will cause undefine process to fail.

This patch also changes the behavior of virDomainUndefine, if the
domain has a managed save image, the undefine will be refused.

There were two API in driver.c that were silently masking flags
bits prior to calling out to the drivers, and several others
that were explicitly masking flags bits.  This is not
forward-compatible - if we ever have that many flags in the
future, then talking to an old server that masks out the
flags would be indistinguishable from talking to a new server
that can honor the flag.  In general, libvirt.c should forward
_all_ flags on to drivers, and only the drivers should reject
unknown flags.

In the case of virDrvSecretGetValue, the solution is to separate
the internal driver callback function to have two parameters
instead of one, with only one parameter affected by the public
API.  In the case of virDomainGetXMLDesc, it turns out that
no one was ever mixing VIR_DOMAIN_XML_INTERNAL_STATUS with
the dumpxml path in the first place; that internal flag was
only used in saving and restoring state files, which happened
to be in functions internal to a single file, so there is no
mixing of the internal flag with a public flags argument.
Additionally, virDomainMemoryStats passed a flags argument
over RPC, but not to the driver.

* src/driver.h (VIR_DOMAIN_XML_FLAGS_MASK)
(VIR_SECRET_GET_VALUE_FLAGS_MASK): Delete.
(virDrvSecretGetValue): Separate out internal flags.
(virDrvDomainMemoryStats): Provide missing flags argument.
* src/driver.c (verify): Drop unused check.
* src/conf/domain_conf.h (virDomainObjParseFile): Delete
declaration.
(virDomainXMLInternalFlags): Move...
* src/conf/domain_conf.c: ...here.  Delete redundant include.
(virDomainObjParseFile): Make static.
* src/libvirt.c (virDomainGetXMLDesc, virSecretGetValue): Update
clients.
(virDomainMemoryPeek, virInterfaceGetXMLDesc)
(virDomainMemoryStats, virDomainBlockPeek, virNetworkGetXMLDesc)
(virStoragePoolGetXMLDesc, virStorageVolGetXMLDesc)
(virNodeNumOfDevices, virNodeListDevices, virNWFilterGetXMLDesc):
Don't mask unknown flags.
* src/interface/netcf_driver.c (interfaceGetXMLDesc): Reject
unknown flags.
* src/secret/secret_driver.c (secretGetValue): Update clients.
* src/remote/remote_driver.c (remoteSecretGetValue)
(remoteDomainMemoryStats): Likewise.
* src/qemu/qemu_process.c (qemuProcessGetVolumeQcowPassphrase):
Likewise.
* src/qemu/qemu_driver.c (qemudDomainMemoryStats): Likewise.
* daemon/remote.c (remoteDispatchDomainMemoryStats): Likewise.

Introduce a new API in libvirt-qemu.so

 virDomainPtr virDomainQemuAttach(virConnectPtr domain,
                                  unsigned long long pid,
                                  unsigned int flags);

This allows libvirtd to attach to an existing, externally
launched QEMU process. This is useful for QEMU developers who
prefer to launch QEMU themselves for debugging/devel reasons,
but still want the benefit of libvirt based tools like
virt-top, virt-viewer, etc

* include/libvirt/libvirt-qemu.h: Define virDomainQemuAttach
* src/driver.h, src/libvirt-qemu.c, src/libvirt_qemu.syms:
  Driver glue for virDomainQemuAttach

Now that the public APIs always use unsigned flags, the internal
driver callbacks might as well do likewise.

* src/driver.h (vrDrvOpen, virDrvDomainCoreDump)
(virDrvDomainGetXMLDesc, virDrvNetworkGetXMLDesc)
(virDrvNWFilterGetXMLDesc): Update type.
* src/remote/remote_protocol.x (remote_open_args)
(remote_domain_core_dump_args, remote_domain_get_xml_desc_args)
(remote_network_get_xml_desc_args)
(remote_nwfilter_get_xml_desc_args): Likewise.
* src/test/test_driver.c: Update clients.
* src/remote/remote_driver.c: Likewise.
* src/xen/xen_hypervisor.c: Likewise.
* src/xen/xen_hypervisor.h: Likewise.
* src/xen/xen_driver.c: Likewise.
* src/xen/xend_internal.c: Likewise.
* src/xen/xend_internal.h: Likewise.
* src/xen/xm_internal.c: Likewise.
* src/xen/xm_internal.h: Likewise.
* src/xen/xs_internal.c: Likewise.
* src/xen/xs_internal.h: Likewise.
* src/xen/xen_inotify.c: Likewise.
* src/xen/xen_inotify.h: Likewise.
* src/phyp/phyp_driver.c: Likewise.
* src/openvz/openvz_driver.c: Likewise.
* src/vmware/vmware_driver.c: Likewise.
* src/vbox/vbox_driver.c: Likewise.
* src/vbox/vbox_tmpl.c: Likewise.
* src/xenapi/xenapi_driver.c: Likewise.
* src/esx/esx_driver.c: Likewise.
* src/esx/esx_interface_driver.c: Likewise.
* src/esx/esx_network_driver.c: Likewise.
* src/esx/esx_storage_driver.c: Likewise.
* src/esx/esx_device_monitor.c: Likewise.
* src/esx/esx_secret_driver.c: Likewise.
* src/esx/esx_nwfilter_driver.c: Likewise.
* src/interface/netcf_driver.c: Likewise.
* src/nwfilter/nwfilter_driver.c: Likewise.
* src/libxl/libxl_driver.c: Likewise.
* src/qemu/qemu_driver.c: Likewise.
* src/lxc/lxc_driver.c: Likewise.
* src/uml/uml_driver.c: Likewise.
* src/network/bridge_driver.c: Likewise.
* src/secret/secret_driver.c: Likewise.
* src/storage/storage_driver.c: Likewise.
* src/node_device/node_device_hal.c: Likewise.
* src/node_device/node_device_udev.c: Likewise.
* src/remote_protocol-structs: Likewise.

We already have a public virDomainPinVcpu, which implies that
Pin and Vcpu are treated as separate words.  Unreleased commit
e261987c introduced virDomainGetVcpupinInfo as the first public
API that used Vcpupin, although we had prior internal uses of
that spelling.  For consistency, change the spelling to be two
words everywhere, regardless of whether pin comes first or last.

* daemon/remote.c: Treat vcpu and pin as separate words.
* include/libvirt/libvirt.h.in: Likewise.
* src/conf/domain_conf.c: Likewise.
* src/conf/domain_conf.h: Likewise.
* src/driver.h: Likewise.
* src/libvirt.c: Likewise.
* src/libvirt_private.syms: Likewise.
* src/libvirt_public.syms: Likewise.
* src/libxl/libxl_driver.c: Likewise.
* src/qemu/qemu_driver.c: Likewise.
* src/remote/remote_driver.c: Likewise.
* src/xen/xend_internal.c: Likewise.
* tools/virsh.c: Likewise.
* src/remote/remote_protocol.x: Likewise.
* src/remote_protocol-structs: Likewise.
Suggested by Matthias Bolte.

This patch introduces a new libvirt API (virDomainGetVcpupinInfo),
as a counterpart to virDomainPinVcpuFlags.

We can use virDomainGetVcpus API to retrieve CPU affinity information,
but can't use this API against inactive domains (at least in case of KVM),
as it lacks a flags parameter.
The usual thing is to add a new virDomainGetVcpusFlags, but that API name
is already occupied by the counterpart to virDomainGetMaxVcpus, which
has a completely different signature.

The virDomainGetVcpupinInfo is the new API to retrieve CPU affinity
information of active and inactive domains.  While the usual convention
is to list an array before its length, this API violates that rule
in order to be more like virDomainGetVcpus (where maxinfo was doing
double-duty as the length of two different arrays).
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>

This reverts commit 7d56a16d.

Conflicts:

	python/generator.py
	src/libvirt_public.syms

The API can be used to query current state of an interface to VMM used
to control a domain. In QEMU world this translates into monitor
connection.

Even though rpc uses 'unsigned int' for the _len parameter that
passes the length of item<length>, the public libvirt APIs all
use 'int' and filter out lengths < 0, except for virDomainSendKey.

* include/libvirt/libvirt.h.in (virDomainSendKey): All other APIs
use int for array length.
* src/libvirt.c (virDomainSendKey): Adjust.
* src/driver.h (virDrvDomainSendKey): Likewise.
* daemon/remote_generator.pl: Likewise.

Set up the types for the block pull functions and insert them into the
virDriver structure definition.  Symbols are exported in this patch to prevent
documentation compile failures.

* include/libvirt/libvirt.h.in: new API
* src/driver.h: add the new entry to the driver structure
* python/generator.py: fix compiler errors, the actual python bindings are
  implemented later
* src/libvirt_public.syms: export symbols
Signed-off-by: NAdam Litke <agl@us.ibm.com>

Signed-off-by: NMinoru Usui <usui@mxm.nes.nec.co.jp>

Signed-off-by: NMinoru Usui <usui@mxm.nes.nec.co.jp>

Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

This patch introduces a new libvirt API virDomainPinVcpuFlags,
a direct extension from the existing virDomainPinVcpu

If we can choose live or config when setting, then we need to
be able to choose which one we are querying.

Also, make the documentation clear that set must use a non-empty
subset (some of the hypervisors fail if params is NULL).

* include/libvirt/libvirt.h.in
(virDomainGetSchedulerParametersFlags): New prototype.
* src/libvirt.c (virDomainGetSchedulerParametersFlags): Implement
it.
* src/libvirt_public.syms: Export it.
* python/generator.py (skip_impl): Don't auto-generate.
* src/driver.h (virDrvDomainGetSchedulerParametersFlags): New
callback.

Rather mechanical in nature.

* src/driver.h: Use newer virTypedParameter API names.
* src/libvirt.c: Likewise.
* daemon/remote.c: Likewise.
* src/esx/esx_driver.c: Likewise.
* src/libxl/libxl_driver.c: Likewise.
* src/lxc/lxc_driver.c: Likewise.
* src/qemu/qemu_driver.c: Likewise.
* src/remote/remote_driver.c: Likewise.
* src/test/test_driver.c: Likewise.
* src/xen/xen_driver.c: Likewise.
* src/xen/xen_hypervisor.c: Likewise.
* src/xen/xen_hypervisor.h: Likewise.
* src/xen/xend_internal.c: Likewise.
* tools/virsh.c: Likewise.

In most cases this affects flags parameters that are unsigned in the
public and driver API but signed in the XDR protocol. Switch the
XDR protocol to unsigned for those.

A counterexample is virNWFilterGetXMLDesc. Its flags parameter is signed
in the public API and XDR protocol, but unsigned in the driver API.

The current virDomainMigrateFinish3 method signature attempts to
distinguish two types of errors, by allowing return with ret== 0,
but ddomain == NULL, to indicate a failure to start the guest.
This is flawed, because when ret == 0, there is no way for the
virErrorPtr details to be sent back to the client.

Change the signature of virDomainMigrateFinish3 so it simply
returns a virDomainPtr, in the same way as virDomainMigrateFinish2
The disk locking code will protect against the only possible
failure mode this doesn't account for (loosing conenctivity to
libvirtd after Finish3 starts the CPUs, but before the client
sees the reply for Finish3).

* src/driver.h, src/libvirt.c, src/libvirt_internal.h: Change
  virDomainMigrateFinish3 to return a virDomainPtr instead of int
* src/remote/remote_driver.c, src/remote/remote_protocol.x,
  daemon/remote.c, src/qemu/qemu_driver.c, src/qemu/qemu_migration.c:
  Update for API change

The virDomainMigratePerform3 currently has a single URI parameter
whose meaning varies. It is either

 - A QEMU migration URI (normal migration)
 - A libvirtd connection URI (peer2peer migration)

Unfortunately when using peer2peer migration, without also
using tunnelled migration, it is possible that both URIs are
required.

This adds a second URI parameter to the virDomainMigratePerform3
method, to cope with this scenario. Each parameter how has a fixed
meaning.

NB, there is no way to actually take advantage of this yet,
since virDomainMigrate/virDomainMigrateToURI do not have any
way to provide the 2 separate URIs

* daemon/remote.c, src/remote/remote_driver.c,
  src/remote/remote_protocol.x, src/remote_protocol-structs: Add
  the second URI parameter to perform3 message
* src/driver.h, src/libvirt.c, src/libvirt_internal.h: Add
  the second URI parameter to Perform3 method
* src/libvirt_internal.h, src/qemu/qemu_migration.c,
  src/qemu/qemu_migration.h: Update to handle URIs correctly

This extends the v3 migration protocol such that the
virDomainMigrateBegin3 and virDomainMigratePerform3
methods accept an application supplied XML config for
the target VM.

If the 'xmlin' parameter is NULL, then Begin3 uses the
current guest XML as normal. A driver implementing the
Begin3 method should either reject all non-NULL 'xmlin'
parameters, or strictly validate that the app supplied
XML does not change guest ABI.

The Perform3 method also needed the xmlin parameter to
cope with the Peer2Peer migration sequence.

NB it is not yet possible to use this capability since
neither of the public virDomainMigrate/virDomainMigrateToURI
methods have a way to pass in XML.

* daemon/remote.c, src/remote/remote_driver.c,
  src/remote/remote_protocol.x, src/remote_protocol-structs:
  Add 'remote_string xmlin' parameter to begin3/perform3
  RPC messages
* src/libvirt.c, src/driver.h, src/libvirt_internal.h: Add
  'const char *xmlin' parameter to Begin3/Perform3 methods
* src/qemu/qemu_driver.c, src/qemu/qemu_migration.c,
  src/qemu/qemu_migration.h: Pass xmlin parameter around
  migration methods

This new function allows aditional flags to be passed into from
the virsh command line.

Migration just seems to go from bad to worse. We already had to
introduce a second migration protocol when adding the QEMU driver,
since the one from Xen was insufficiently flexible to cope with
passing the data the QEMU driver required.

It turns out that this protocol still has some flaws that we
need to address. The current sequence is

 *  Src: DumpXML
          - Generate XML to pass to dst

 *  Dst: Prepare
          - Get ready to accept incoming VM
          - Generate optional cookie to pass to src

 *  Src: Perform
          - Start migration and wait for send completion
          - Kill off VM if successful, resume if failed

 *  Dst: Finish
          - Wait for recv completion and check status
          - Kill off VM if unsuccessful

The problems with this are:

 - Since the first step is a generic 'DumpXML' call, we can't
   add in other migration specific data. eg, we can't include
   any VM lease data from lock manager plugins
 - Since the first step is a generic 'DumpXML' call, we can't
   emit any 'migration begin' event on the source, or have
   any hook that runs right at the start of the process
 - Since there is no final step on the source, if the Finish
   method fails to receive all migration data & has to kill
   the VM, then there's no way to resume the original VM
   on the source

This patch attempts to introduce a version 3 that uses the
improved 5 step sequence

 *  Src: Begin
          - Generate XML to pass to dst
          - Generate optional cookie to pass to dst

 *  Dst: Prepare
          - Get ready to accept incoming VM
          - Generate optional cookie to pass to src

 *  Src: Perform
          - Start migration and wait for send completion
          - Generate optional cookie to pass to dst

 *  Dst: Finish
          - Wait for recv completion and check status
          - Kill off VM if failed, resume if success
          - Generate optional cookie to pass to src

 *  Src: Confirm
          - Kill off VM if success, resume if failed

The API is designed to allow both input and output cookies
in all methods where applicable. This lets us pass around
arbitrary extra driver specific data between src & dst during
migration. Combined with the extra 'Begin' method this lets
us pass lease information from source to dst at the start of
migration

Moving the killing of the source VM out of Perform and
into Confirm, means we can now recover if the dst host
can't successfully Finish receiving migration data.

Fix some driver names:

  s/virDrvCPUCompare/virDrvCompareCPU/
  s/virDrvCPUBaseline/virDrvBaselineCPU/
  s/virDrvQemuDomainMonitorCommand/virDrvDomainQemuMonitorCommand/
  s/virDrvSecretNumOfSecrets/virDrvNumOfSecrets/
  s/virDrvSecretListSecrets/virDrvListSecrets/

And some driver struct field names:

  s/getFreeMemory/nodeGetFreeMemory/

* src/driver.h: Stub code for new API
* src/esx/esx_driver.c, src/libxl/libxl_driver.c,
  src/lxc/lxc_driver.c, src/openvz/openvz_driver.c,
  src/phyp/phyp_driver.c, src/qemu/qemu_driver.c,
  rc/remote/remote_driver.c, rc/test/test_driver.c,
  src/uml/uml_driver.c, src/vbox/vbox_tmpl.c,
  src/vmware/vmware_driver.c, src/xen/xen_driver.c,
  src/xen/xen_driver.h, src/xen/xen_hypervisor.c,
  src/xen/xen_inotify.c, src/xen/xend_internal.c,
  src/xen/xm_internal.c, src/xen/xs_internal.c,
  src/xenapi/xenapi_driver.c: Add dummy entries in driver
  table for new APIs