VirtualBox 4.0.8 changed the registry key layout. Before the version
number was in a Version key. Now the Version key contains %VER% and
the actual version number is in VersionExt now.

Move value lookup code into its own function: vboxLookupRegistryValue.

This commit is safe precisely because there has been no release
for any of the enum values being deleted (they were added post-0.9.1).

After the 0.9.2 release, we can then take advantage of
virDomainModificationImpact in more places.

* include/libvirt/libvirt.h.in (virDomainModificationImpact): New
enum.
(virDomainSchedParameterFlags, virMemoryParamFlags): Delete, since
these were never released, and the new enum works fine here.
* src/libvirt.c	(virDomainGetMemoryParameters)
(virDomainSetMemoryParameters)
(virDomainGetSchedulerParametersFlags)
(virDomainSetSchedulerParametersFlags): Update documentation.
* src/qemu/qemu_driver.c (qemuDomainSetMemoryParameters)
(qemuDomainGetMemoryParameters, qemuSetSchedulerParametersFlags)
(qemuSetSchedulerParameters, qemuGetSchedulerParametersFlags)
(qemuGetSchedulerParameters): Adjust clients.
* tools/virsh.c (cmdSchedinfo, cmdMemtune): Likewise.
Based on ideas by Daniel Veillard and Hu Tao.

This fixes:

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

Both of these complain of a failure to use an image file that resides
on a read-only NFS volume. The function in the DAC security driver
that chowns image files to the qemu user:group before using them
already has special cases to ignore failure of chown on read-only file
systems, and in a few other cases, but it hadn't been checking for
EINVAL, which is what is returned if the qemu user doesn't even exist
on the NFS server.

Since the explanation of EINVAL in the chown man page almost exactly
matches the log message already present for the case of EOPNOTSUPP,
I've just added EINVAL to that same conditional.

This fixes a build failure on MinGW, due to MinGW not supporting dlopen.

Signed-off-by: NNeil Wilson <neil@aldur.co.uk>

Coverity couldn't see that priv is NULL on failure.  But on failure,
we might as well guarantee that callers don't try to free uninitialized
memory.

* src/remote/remote_driver.c (remoteGenericOpen): Even on failure,
pass priv back to caller.

Coverity complained that infd could be -1 at the point where it is
passed to write, when in reality, this code can only be reached if
infd is non-negative.

* src/util/command.c (virCommandProcessIO): Help out coverity.

Detected by Coverity.  Bug introduced in 08106e20 (unreleased).

* src/conf/domain_conf.c (virDomainChannelDefCheckABIStability):
Use correct sizeof operand.

Detected by Coverity.  Introduced in commit aaf2b70b, and turned into
a regression in the next few commits through 4e6e6672 (unreleased).

* src/conf/domain_event.c (virDomainEventStateFree): Free object,
per documentation.

Detected by Coverity.  This leaked a cpumap on every iteration
of the loop.  Leak introduced in commit 1cc4d025 (v0.9.0).

* src/qemu/qemu_process.c (qemuProcessSetVcpuAffinites): Plug
leak, and hoist allocation outside loop.

Detected by Coverity.  Only possible in OOM situations.

* daemon/remote.c (remoteDispatchDomainScreenshot): Plug leak.

Detected by Coverity.  Only possible on OOM situations.

* src/locking/lock_manager.c (virLockManagerPluginNew): Plug leak.

Spotted by coverity.  Triggers on failed stat, although I'm not sure
how easy that condition is, so I'm not sure if this is a runtime
memory hog.  Regression introduced in commit 8077d64f (unreleased).

* src/util/storage_file.c (virStorageFileGetMetadataFromFD):
Reduce need for malloc, avoiding a leak.

Coverity detected that options was being set by strdup but never
freed.  But why even bother with an options variable?  The options
parameter never changes!  Leak present since commit 44948f5b (0.7.0).

This function could probably be rewritten to take better advantage
of virCommand, but that is more invasive.

* src/storage/storage_backend_fs.c
(virStorageBackendFileSystemMount): Avoid wasted strdup, and
guarantee proper cleanup on all paths.

Spotted by Coverity.  Only possible on an OOM condition, so
unlikely to bite in the wild.

* daemon/libvirtd.c (qemudSetLogging): Don't leak memory.

Detected by Coverity.  While it is possible on OOM condition, as
well as with bad code that passes binary == NULL, it is unlikely
to be encountered in the wild.

* src/util/command.c (virCommandNewArgList): Don't leak memory.

In v3 migration, once migration is completed, the VM needs
to be left in a paused state until after Finish3 has been
executed on the target. Only then will the VM be killed
off. When using non-JSON QEMU monitor though, we don't
receive any 'STOP' event from QEMU, so we need to manually
set our state offline & thus release lock manager leases.
It doesn't hurt to run this on the JSON case too, just in
case the event gets lost somehow

* src/qemu/qemu_migration.c: Explicitly set VM state to
  paused when migration completes

The change 18c2a592 caused
some regressions in behaviour of virDomainBlockStats
and virDomainBlockInfo in the QEMU driver.

The virDomainBlockInfo API stopped working for inactive
guests if querying a block device.

The virDomainBlockStats API did not promptly report
an error if the guest was not running in some cases.

* src/qemu/qemu_driver.c: Fix inactive guest handling
  in BlockStats/Info APIs

There were a few minor issues in commit 5b6c961e
- leak managed save path
- leak managed save fd
- functions that open an fd should also close it

I have been finding that some UML command line networking parameters are
being generated incorrectly.

For more information, see
https://bugzilla.redhat.com/show_bug.cgi?id=706295 .

I intentionally set things up so 'virsh help interface' lists
commands in alphabetical order, but 'man virsh' lists them in
topical order; this matches our practice on some other commands.

* tools/virsh.pod: Document all iface commands.
* tools/virsh.c (ifaceCmds): Sort.

The qemuAuditDisk calls in disk hotunplug operations were being
passed 'ret >= 0', but the code which sets ret to 0 was not yet
executed, and the error path had already jumped to the 'cleanup'
label. This meant hotunplug failures were never audited, and
hotunplug success was audited as a failure

* src/qemu/qemu_hotplug.c: Fix auditing of hotunplug

When virLockDriverAcquire is invoked during hotplug the state
parameter will be left as NULL.

* src/locking/lock_driver_nop.c,
  src/locking/lock_driver_sanlock.c: Don't reference NULL state
  parameter

Refactoring of the lock manager hotplug methods lost the
ret = 0 assignment for successful return path

* src/locking/domain_lock.c: Add missing ret = 0 assignments

After successfull virDomainSave/virDomainManagedSave calls
the guest will no longer be active, so the domain ID must
be reset to -1

* daemon/remote_generator.pl: Special case virDomainSave &
  virDomainManagedSave for same reason as virDomainDestroy

Commit 4454a9ef introduced bad
behaviour on the VIR_EVENT_HANDLE_ERROR condition. This condition
is only hit when an invalid FD is used in poll() (typically due
to a double-close bug). The QEMU monitor code was treating this
condition as non-fatal, and thus libvirt would poll() in a fast
loop forever burning 100% CPU. VIR_EVENT_HANDLE_ERROR must be
handled in the same way as VIR_EVENT_HANDLE_HANGUP, killing the
QEMU instance.

* src/qemu/qemu_monitor.c: Treat VIR_EVENT_HANDLE_ERROR as EOF

In between fork and exec, a connection to sanlock is acquired
and the socket file descriptor is intionally leaked to the
child process. sanlock watches this FD for POLL_HANGUP to
detect when QEMU has exited. We don't want a rogus/compromised
QEMU from issuing sanlock RPC calls on the leaked FD though,
since that could be used to DOS other guests. By calling
sanlock_restrict() on the socket before exec() we can lock
it down.

* configure.ac: Check for sanlock_restrict API
* src/locking/domain_lock.c: Restrict lock acquired in
  process startup phase
* src/locking/lock_driver.h: Add VIR_LOCK_MANAGER_ACQUIRE_RESTRICT
* src/locking/lock_driver_sanlock.c: Add call to sanlock_restrict
  when requested by VIR_LOCK_MANAGER_ACQUIRE_RESTRICT flag

Partial revert of commit c3c30d4d.

* docs/Makefile.am (internals/%.html.tmp): Restore MKDIR_P; it is
needed for intermediate file after all.
Reported by Daniel P. Berrange.

* tools/virsh.c: Add screenshot command
* tools/virsh.pod: Document new command
* src/libvirt.c: Fix off-be-one error

Based on the equivalent qemu driver code

* src/libxl/libxl_driver.c: refactor the Start save and restore
  routines of the driver and adds the new entry points for
  managed saves handling

* src/libxl/libxl_driver.c: fix the libxlDomainGetInfo to return the
  maximum memory for running domain

Sanlock is a project that implements a disk-paxos locking
algorithm. This is suitable for cluster deployments with
shared storage.

* src/Makefile.am: Add dlopen plugin for sanlock
* src/locking/lock_driver_sanlock.c: Sanlock driver
* configure.ac: Check for sanlock
* libvirt.spec.in: Add a libvirt-lock-sanlock RPM

* src/conf/domain_conf.c, src/conf/domain_conf.h: APIs for
  inserting/finding/removing virDomainLeaseDefPtr instances
* src/qemu/qemu_driver.c: Wire up hotplug/unplug for leases
* src/qemu/qemu_hotplug.h, src/qemu/qemu_hotplug.c: Support
  for hotplug and unplug of leases

Some lock managers associate state with leases, allowing a process
to temporarily release its leases, and re-acquire them later, safe
in the knowledge that no other process has acquired + released the
leases in between.

This is already used between suspend/resume operations, and must
also be used across migration. This passes the lockstate in the
migration cookie. If the lock manager uses lockstate, then it
becomes compulsory to use the migration v3 protocol to get the
cookie support.

* src/qemu/qemu_driver.c: Validate that migration v2 protocol is
  not used if lock manager needs state transfer
* src/qemu/qemu_migration.c: Transfer lock state in migration
  cookie XML

The QEMU integrates with the lock manager instructure in a number
of key places

 * During startup, a lock is acquired in between the fork & exec
 * During startup, the libvirtd process acquires a lock before
   setting file labelling
 * During shutdown, the libvirtd process acquires a lock
   before restoring file labelling
 * During hotplug, unplug & media change the libvirtd process
   holds a lock while setting/restoring labels

The main content lock is only ever held by the QEMU child process,
or libvirtd during VM shutdown. The rest of the operations only
require libvirtd to hold the metadata locks, relying on the active
QEMU still holding the content lock.

* src/qemu/qemu_conf.c, src/qemu/qemu_conf.h,
  src/qemu/libvirtd_qemu.aug, src/qemu/test_libvirtd_qemu.aug:
  Add config parameter for configuring lock managers
* src/qemu/qemu_driver.c: Add calls to the lock manager

To facilitate use of the locking plugins from hypervisor drivers,
introduce a higher level API for locking virDomainObjPtr instances.
In includes APIs targetted to VM startup, and hotplug/unplug

* src/Makefile.am: Add domain lock API
* src/locking/domain_lock.c, src/locking/domain_lock.h: High
  level API for domain locking