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

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.