The new flags allow to pick current state, config or the live
parameter, with current being the existing API default (0).
This also hooks this to --config, --live, --current parameters for
the memtune virsh command

* include/libvirt/libvirt.h.in: defines the new flags
* tools/virsh.c: adds support at virsh level
* tools/virsh.pod: updates virsh documentation

This patch allows to modify interfaces of domain(qemu)
* src/conf/domain_conf.c src/conf/domain_conf.h src/libvirt_private.syms:
  (virDomainNetInsert)     : Insert a network device to domain definition.
  (virDomainNetIndexByMac) : Returns an index of net device in array.
  (virDomainNetRemoveByMac): Remove a NIC of passed MAC address.
* src/qemu/qemu_driver.c
  (qemuDomainAttachDeviceConfig): add codes for NIC.
  (qemuDomainDetachDeviceConfig): add codes for NIC.

Before commit 145d6cb0 (in August 2010) absolute file names
in VMX and domain XML configs were handled correctly. But this got
lost during the refactoring. The test cases didn't highlight this
problem because they have their own set of file name handling
functions. The actual ones require a real connection to an ESX
server. Also the test case functions always worked correctly.

Fix the regression and add a new in-the-wild VMX file that contains
such a problematic absolute path. Even though this test case won't
protect against new regressions.

Reported by lofic (IRC nick)

This testcase passes before the regression is added in f0443765, fails
after that commit and passes again after the regression was fixed.

drivers implementing domainSetSchedulerParametersFlags should check
flags themselves.

As reported by Diego Blanco in

  https://bugzilla.redhat.com/show_bug.cgi?id=702602

commit f0443765 which replaced openvz_readline to getline(3)
broke OpenVZ driver as it changed semantics of EOF-handling
when parsing OpenVZ configuration.

There're several other issues reported with current OpenVZ driver:

 #1: unclear error message when parsing "CPUS=" line
 #2: openvz driver goes into crashing loop
 #3: "NETIF=" line in configuration is not parsed correctly
 #4: aborts even when optional parameter is missing
 #5: there's a potential memory leak

This updated patch to fix #[145]. This patch does not fix #[23]
as I haven't verified these yet, but this at least got me to run
OpenVZ on libvirt once again.

Coverity spotted this off-by-one.  Thankfully, no one in libvirt
was ever calling virAuditSend with an argument of 3.

* src/util/virtaudit.c (virAuditSend): Use correct comparison.

Originally most of libvirt domain-specific calls were blocking
during a migration.
A new mechanism to allow specific calls (blkstat/blkinfo) to be
executed in such condition has been implemented.
In the long term it'd be desirable to get a more general
solution to mark further APIs as migration safe, without needing
special case code.

 * src/qemu/qemu_migration.c: add some additional job signal
   flags for doing blkstat/blkinfo during a migration
 * src/qemu/qemu_domain.c: add a condition variable that can be
   used to efficiently wait for the migration code to clear the
   signal flag
 * src/qemu/qemu_driver.c: execute blkstat/blkinfo using the
   job signal flags during migration

Based on the device attach/detach code from the QEMU driver,
but using the new functions to create the structures associated.
* src/libxl/libxl_driver.c: implements domainAttachDevice,
  domainAttachDeviceFlags, domainDetachDevice, domainDetachDeviceFlags
  and domainUpdateDeviceFlags

* src/libxl/libxl_driver.c: in libxlVmCleanup, free up the
  newDef definition if present overwise it would be leaked.

Create 3 new function refactored from previous list ones and
exports them internally to the driver

* src/libxl/libxl_conf.c src/libxl/libxl_conf.h: create libxlMakeDisk,
  libxlMakeNic libxlMakeVfb out of the exsting static List functions
  and exports them

When modifying the disk devices of a live domain and the domain
configuration, the function qemuDomainAttachDeviceConfig
first sets dev->data->disk to NULL. Later qemuDomainAttachDeviceLive
accesses dev->data.disk and causes a segfault.
* src/qemu/qemu_driver.c: fix qemuDomainModifyDeviceFlags() accordingly

We support this in code, but forgot to add this to RNG schema as well.
According to documentation, the value match the dateTime type.

Anything generated that must end up in the tarball must either
have unconditional rules for generation (remote_protocol.c) or
must live in libvirt.git for the case where the person running
'make dist' has disabled the configure options that control the
rebuild of the generated file (remote_protocol-structs).

* src/Makefile.am (remote_protocol-structs): Add a dependency and
document why it must live in git.
($(srcdir)/remote/%_protocol.c, $(srcdir)/remote/%_protocol.c):
Unconditionally generate.

http://lists.gnu.org/archive/html/qemu-devel/2011-05/threads.html#02162

Currently, qemu silently clips any JSON integer in the range
0x8000000000000000 - 0xffffffffffffffff (all numbers in this range
will be clipped to 0x7fffffffffffffff == LLONG_MAX).

To avoid this, pass these as signed 64 bit integers in the QMP
request.

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.

virNodeGetFreeMemory used unsigned long long in the public API but
signed hyper in the XDR protocol. Convert the XDR protocol to use
unsigned hyper.

As explained by Eric before, this doesn't affect the on-the-wire protocol.

Extend procedure annotation in the .x file for stream handling.

Adds a missing remoteStreamRelease call to remoteDomainScreenshot
error path.

Several functions return values by reference parameters. This is realized
by passing the members of remote_CALL_ret by reference to the called
function.

The position of this parameters in the function signature follows some
patterns with some exceptions. This patterns and exceptions are hardcoded
in the generator.

Add an insert@<offset> annotation to the remote_CALL_ret struct members
for functions that return lists to remove some of the hardcoded patterns
and exceptions.

This allows to remove some special case code from the generator.

Add special case code for updating a given domain object instead of
returning a new one.

localtime_r expects time_t.

In particular, this guarantees that virStrerror always gives a
useful result.

* .gnulib: Update to latest, for (lots of) strerror_r fixes.

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

When doing migration, if an error occurs in Perform, it must not
be overwritten during Finish/Confirm steps. If an error occurs
in Finish, it must not be overwritten in Confirm.

Previous commit a9d12c24 added
code to qemudDomainMigrateFinish2 to preserve the error. This
is not the right place, because it is not applicable in non-p2p
migration. The src/libvirt.c virDomainMigrateV2/3 methods need
code to preserve errors for non-p2p migration, while the
doPeer2PeerMigrate2 and doPeer2PeerMigrate3 methods contain
code to preverse errors for p2p migration.

Remove the bogus error preservation from qemudDomainMigrateFinish2
and qemudDomainMigrateFinish3.

Fix virDomainMigrateV3 and doPeer2PeerMigrate3 so that they
preserve any error hit during the Finish3 step, before invoking
Confirm3.

Finally if qemuMigrationFinish fails to resume the CPUs, it must
preserve the error before tearing down the VM, so that VM cleanup
doesn't overwrite it.

* src/libvirt.c: Preserve error before invoking Confirm3
* src/qemu/qemu_driver.c: Remove bogus error preservation
  code in qemudDomainMigrateFinish2/qemudDomainMigrateFinish3
* src/qemu/qemu_migration.c: Preserve error before invoking Confirm3
  and after resume fails in qemuMigrationFinish.

* src/libvirt.c: Add further debug lines in helper APIs for
  migration
* src/qemu/qemu_migration.c: Add debug lines for all internal
  migration API parameters

Even when failing to start CPUs, the finish method was returning
a success result. Fix this so that the QEMU process is killed
off when finish fails under v3 protocol. Also rename the
killOnFinish boolean to 'v3proto' to make it clearer that this
is a tunable based on the migration protocol version

* src/qemu/qemu_driver.c: Update for API change
* src/qemu/qemu_migration.c, src/qemu/qemu_migration.h: Kill
  VM in qemuMigrationFinish if failing to start CPUs

The SPICE seamless migration process requires data to be passed
back from the target host, to the source host via a cookie.
The cookie includes the target host's hostname, but this was not
stored, merely validated. This patch explicitly records the
remote hostname after parsing the cookie, and uses it when
initiating the SPICE migration

* qemu/qemu_migration.c: Fix SPICE seamless migration hostname

Before running perform in peer-2-peer migration, the current
guest state must be recorded, so that non-live migration can
currently unpause a running guest on completion.

* src/qemu/qemu_migration.c: Move check for offline guest
  to fix non-live migration

There are two pieces of information which are desirable for
migration, which cannot be supplied by applications

 - The explicit QEMU migration URI, while using Peer2Peer
   migration
 - An override for the target VM XML

This introduces two new public APIs to support these extra
parameters. There is no need for extra wire protocool changes,
since this is supported by the v3 migration enhancements

* include/libvirt/libvirt.h.in,
  src/libvirt.c, src/libvirt_public.syms: Add virDomainMigrate2
  and virDomainMigrateToURI2

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

Otherwise an attempt to use virConnectOpen or virConnectOpenAuth without
auth pointer results in the driver declining the URI and libvirt falling
back to the remote driver for an esx:// URI.

The cur_vcpus member of struct libxl_domain_build_info was incorrectly
initialized to the number of vcpus, when it should have been interpreted
as a bitmap, where bit X corresponds to online/offline status of vcpuX.

To complicate matters, cur_vcpus is an int, so only 32 vcpus can be
set online.  Add a check to ensure vcpus does not exceed this limit.

V2: Eric Blake noted a compilation pitfal when '1 << 32' on an int.
    Account for vcpus == 32.

We don't use the gnulib vsnprintf replacement, which means that
on mingw, vsnprintf doesn't support %zn or %lln.

And as it turns out, VIR_GET_VAR_STR was a rather inefficient
reimplementation of virVasprintf logic.

* src/util/logging.c (VIR_GET_VAR_STR): Drop.
(virLogMessage): Inline a simpler version here.
* src/util/virterror.c (VIR_GET_VAR_STR, virRaiseErrorFull):
Likewise.
Reported by Matthias Bolte.

Saving domain to previously created file changes also its ownership.
This is certainly not what users want if some conditions are met:
it is a regular, local file and dynamic_ownership is off.

Change f88af9dc accidentally
reverted the .gnulib update from f3cfc99e

* .gnulib: Update to 2c25c9ebe8db1415bfde25f0a451767332c8cf59

NB: the enum that uses the string vnet-host (now changed to vhost-net)
is used in XML, but fortunately that hasn't been in an official
release yet, so it can still be fixed.