To allow a client app to pass in custom XML during migration
of a guest it is neccessary to ensure the guest ABI remains
unchanged. The virDomainDefCheckABIStablity method accepts
two virDomainDefPtr structs and compares everything in them
that could impact the guest machine ABI

* src/conf/domain_conf.c, src/conf/domain_conf.h,
  src/libvirt_private.syms: Add virDomainDefCheckABIStablity
* src/conf/cpu_conf.c, src/conf/cpu_conf.h: Add virCPUDefIsEqual
* src/util/sysinfo.c, src/util/sysinfo.h: Add virSysinfoIsEqual

The virDomainHostdevDef struct contains a 'char *target'
field. This is set to 'NULL' when parsing XML and never
used / set anywhere else. Clearly it is bogus & unused

* src/conf/domain_conf.c, src/conf/domain_conf.h: Remove
  target from virDomainHostdevDef

This patch seperate the domain config loading just as qemu driver
does, first loading config of running or trasient domains, then
of persistent inactive domains. And only try to reconnect the
monitor of running domains, so that it won't always throws errors
saying can't connect to domain monitor.

And as "virDomainLoadConfig->virDomainAssignDef->virDomainObjAssignDef",
already do things like "vm->newDef = def", removed the codes
in "lxcReconnectVM" that does the same work.

Remove the Domain prefix from the comments.

As OpenVZ is Linux specific.

Add support to set the maximum memory of the domain.
Also add support to change the memory of the current
state of the domain, which translates to a running
domain or the config of the domain.

Based on the code from the qemu driver.

v3:
* initialize xml pointer to avoid segfault
* throw error message if domain is paused as
  libxenlight itself will pause it

v2:
* header is now padded and has a version field
* the correct restore function from libxl is used
* only create the restore event once in libxlVmStart

v2:
* incorporated Jim Fehlig's review

This patch fixes the population of the
libxenlight data structures. Now the devices
should be removed correctly from the xenstore
if they are detached.

Currently the QEMU monitor I/O handler code uses errno values
to report errors. This results in a sub-optimal error messages
on certain conditions, in particular when parsing JSON strings
malformed data simply results in 'EINVAL'.

This changes the code to use the standard libvirt error reporting
APIs. The virError is stored against the qemuMonitorPtr struct,
and when a monitor API is run, any existing stored error is copied
into that thread's error local

* src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h,
  src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_text.c: Use
  virError APIs for all monitor I/O handling code

Currently whenever there is any failure with parsing the monitor,
this is treated in the same was as end-of-file (ie QEMU quit).
The domain is terminated, if not already dead.

With this change, failures in parsing the monitor stream do not
result in the death of QEMU. The guest continues running unchanged,
but all further use of the monitor will be disabled.

The VMM_FAILURE event will be emitted, and the mgmt application
can decide when to kill/restart the guest to re-gain control

* src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h: Run a
  different callback for monitor EOF vs error conditions.
* src/qemu/qemu_process.c: Emit VMM_FAILURE event when monitor
  fails

This introduces a new domain

  VIR_DOMAIN_EVENT_ID_CONTROL_ERROR

Which uses the existing generic callback

typedef void (*virConnectDomainEventGenericCallback)(virConnectPtr conn,
                                                     virDomainPtr dom,
                                                     void *opaque);

This event is intended to be emitted when there is a failure in
some part of the domain virtualization system. Whether the domain
continues to run/exist after the failure is an implementation
detail specific to the hypervisor.

The idea is that with some types of failure, hypervisors may
prefer to leave the domain running in a "degraded" mode of
operation. For example, if something goes wrong with the QEMU
monitor, it is possible to leave the guest OS running quite
happily. The mgmt app will simply loose the ability todo various
tasks. The mgmt app can then choose how/when to deal with the
failure that occured.
* daemon/remote.c: Dispatch of new event
* examples/domain-events/events-c/event-test.c: Demo catch
  of event
* include/libvirt/libvirt.h.in: Define event ID and callback
* src/conf/domain_event.c, src/conf/domain_event.h: Internal
  event handling
* src/remote/remote_driver.c: Receipt of new event from daemon
* src/remote/remote_protocol.x: Wire protocol for new event
* src/remote_protocol-structs: add new event for checks

Well, the remaining drivers that already had the get/set
scheduler parameter functionality to begin with.

For now, this blindly treats VIR_DOMAIN_SCHEDINFO_CURRENT as
the only supported operation for these 5 domains; it will
take domain-specific patches if more specific behavior is
preferred.

* src/esx/esx_driver.c (esxDomainGetSchedulerParameters)
(esxDomainSetSchedulerParameters): Move guts...
(esxDomainGetSchedulerParametersFlags)
(esxDomainSetSchedulerParametersFlags): ...to new functions.
* src/libxl/libxl_driver.c (libxlDomainGetSchedulerParameters)
(libxlDomainSetSchedulerParameters)
(libxlDomainGetSchedulerParametersFlags)
(libxlDomainSetSchedulerParametersFlags): Likewise.
* src/lxc/lxc_driver.c (lxcGetSchedulerParameters)
(lxcSetSchedulerParameters, lxcGetSchedulerParametersFlags)
(lxcSetSchedulerParametersFlags): Likewise.
* src/test/test_driver.c (testDomainGetSchedulerParams)
(testDomainSetSchedulerParams, testDomainGetSchedulerParamsFlags)
(testDomainSetSchedulerParamsFlags): Likewise.
* src/xen/xen_driver.c (xenUnifiedDomainGetSchedulerParameters)
(xenUnifiedDomainSetSchedulerParameters)
(xenUnifiedDomainGetSchedulerParametersFlags)
(xenUnifiedDomainSetSchedulerParametersFlags): Likewise.

Since we can now set just --live or --config, we also need to be
able to query that back.

In the case of setting both --live and --config, it shouldn't matter
which value we read back; otherwise, since querying treats the two
flags as mutually exclusive, so does this patch.

* tools/virsh.c (cmdSchedinfo): Use new API where appropriate.

* daemon/remote.c (remoteDispatchDomainGetSchedulerParameters):
New function.
* src/remote/remote_driver.c (remoteDomainGetSchedulerParameters):
Likewise.
* src/remote/remote_protocol.x
(remote_domain_get_scheduler_parameters_flags_args)
(remote_domain_get_scheduler_parameters_flags_ret): New types.
(remote_procedure): New RPC.
* src/remote_protocol-structs: Likewise.

* src/qemu/qemu_driver.c (qemuGetSchedulerParameters): Move
guts...
(qemuGetSchedulerParametersFlags): ...to new callback, and honor
flags more accurately.

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.

* src/remote/remote_protocol.x (remote_typed_param_value)
(remote_typed_param):  New types.
(remote_sched_param_value, remote_sched_param)
(remote_blkio_param_value, remote_blkio_param)
(remote_memory_param_value, remote_memory_param): Delete.
(remote_domain_get_scheduler_parameters_ret)
(remote_domain_set_scheduler_parameters_args)
(remote_domain_set_scheduler_parameters_flags_args)
(remote_domain_set_blkio_parameters_args)
(remote_domain_get_blkio_parameters_ret)
(remote_domain_set_memory_parameters_args)
(remote_domain_get_memory_parameters_ret): Update clients.
* src/remote_protocol-structs: Likewise.
* src/remote/remote_driver.c (remoteSerializeTypedParameters)
(remoteDeserializeTypedParameters): New functions.
(remoteDomainSetMemoryParameters)
(remoteDomainGetMemoryParameters, remoteDomainSetBlkioParameters)
(remoteDomainGetBlkioParameters)
(remoteDomainGetSchedulerParameters)
(remoteDomainSetSchedulerParameters)
(remoteDomainSetSchedulerParametersFlags): Update clients.
* daemon/remote.c (remoteSerializeTypedParameters)
(remoteDeserializeTypedParameters): New functions.
(remoteDispatchDomainGetSchedulerParameters)
(remoteDispatchDomainSetSchedulerParameters)
(remoteDispatchDomainSetSchedulerParametersFlags)
(remoteDispatchDomainSetMemoryParameters)
(remoteDispatchDomainGetMemoryParameters)
(remoteDispatchDomainSetBlkioParameters)
(remoteDispatchDomainGetBlkioParameters): Update clients.

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.

Commit 824dcaff was a regression (thankfully unreleased) for any
client code that used 'struct _virSchedParameter' directly rather
than the preferred virSchedParameter typedef.  Adding a #define
avoids even that API change, while rearranging the file makes it
clear what the old vs. new API is.

* include/libvirt/libvirt.h.in: Rearrange older names to the
bottom and improve documentation on preferred names.
(virDomainGetSchedulerParameters, virDomainSetSchedulerParameters)
(virDomainSetSchedulerParametersFlags)
(virDomainSetBlkioParameters, virDomainGetBlkioParameters)
(virDomainSetMemoryParameters, virDomainGetMemoryParameters):
Use newer type names.
* python/libvirt-override.c: Adjust code generation to cope.
Suggested by Daniel P. Berrange.

Apparently introdunced in commit 376e1d94
the generator produces u_int flags not unsigned int flags.

* src/remote_protocol-structs: fix to the actual expected type and
  alignment

This was necessary to get libvirt to build on Solaris 11 Express and
seems correct (as it makes this match the definition in util.c):

This patch reorders the locks for the nwfilter updates and the access
the nwfilter objects. In the case that the IP address learning thread
was instantiating filters while an update happened, the previous order
lead to a deadlock.

It was suggested during review of a different patch that the libvirt
interface driver API's should have "netcf:" in their log
messages. This patch eliminates that from all interface driver API
functions, and also eliminates the extra " - " in the case that netcf
returns no details in its error info (which *never* happens at
present, but could happen sometime in the future.

This is the functionality at the end of the libvirt part of the call
chain - for each function, the corresponding netcf API is called.

This implements the commands iface-begin, iface-commit, and iface-rollback,
which simply call the corresponding functions in the libvirt API.

This is the API agreed on in:

  https://www.redhat.com/archives/libvir-list/2011-May/msg00026.html

(with a slight name change to use "...begin" rather than
"...start"). This implements transactional changes to the host network
config. When a transaction is begun with ncf_change_begin(), all other
netcf APIs will continue to work as they always have, but a snapshot
of the existing config will be taken, allowing reversion (rollback,
using ncf_change_rollback()) to the exact state of config at the time
ncf_change_begin() was called. Alternately, if it's determined that
the new changes are acceptable, ncf_change_commit() can be called,
which will eliminate the snapshot and make the changes permanent.

As a failsafe measure, if neither ncf_change_commit() or
ncf_change_rollback() is called by the next time the system reboots,
the netcf-transaction initscript will be automatically called to
rollback the changes.

Commit f0443765 replaced openvz_readline with getline and
changed EOF-handling in the openvzGetVPSUUID.

This patch restores original EOF-handling.

Reported by Jean-Baptiste Rouault.

This should have been in the last commit.

Export a bunch of missing symbols and link the remote driver to gnulib.

* src/qemu/qemu_driver.c: update qemuDomainSetMemoryParameters to
  look at the flag parameter and depending on it save the config
  or the live amount

* src/qemu/qemu_driver.c: update qemuDomainGetMemoryParameters to
  look at the flag parameter and depending on it read the config
  or the live amount

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)