This patch is based on an earlier patch by Eric Blake which was never
committed:

https://www.redhat.com/archives/libvir-list/2011-November/msg00243.html

Aside from rebasing, this patch only drops the driver lock once (prior
to the first time the function sleeps), then leaves it dropped until
it returns (Eric's patch would drop and re-acquire the lock around
each call to sleep).

At the time Eric sent his patch, the response (from Dan Berrange) was
that, while it wasn't a good thing to be holding the driver lock while
sleeping, we really need to rethink locking wrt the driver object,
switching to a finer-grained approach that locks individual items
within the driver object separately to allow for greater concurrency.

This is a good plan, and at the time it made sense to not apply the
patch because there was no known bug related to the driver lock being
held in this function.

However, we now know that the length of the wait in qemuProcessKill is
sometimes too short to allow the qemu process to fully flush its disk
cache before SIGKILL is sent, so we need to lengthen the timeout (in
order to improve the situation with management applications until they
can be updated to use the new VIR_DOMAIN_DESTROY_GRACEFUL flag added
in commit 72f8a7f1). But, if we
lengthen the timeout, we also lengthen the amount of time that all
other threads in libvirtd are essentially blocked from doing anything
(since just about everything needs to acquire the driver lock, if only
for long enough to get a pointer to a domain).

The solution is to modify qemuProcessKill to drop the driver lock
while sleeping, as proposed in Eric's patch. Then we can increase the
timeout with a clear conscience, and thus at least lower the chances
that someone running with existing management software will suffer the
consequence's of qemu's disk cache not being flushed.

In the meantime, we still should work on Dan's proposal to make
locking within the driver object more fine grained.

(NB: although I couldn't find any instance where qemuProcessKill() was
called with no jobs active for the domain (or some other guarantee
that the current thread had at least one refcount on the domain
object), this patch still follows Eric's method of temporarily adding
a ref prior to unlocking the domain object, because I couldn't
convince myself 100% that this was the case.)

* libvirt.pc.in: Add missing '/api/' in path
* libvirt.spec.in, mingw32-libvirt.spec.in: s/apis/api/

via user agent. Allow targets mem & hybrid iff system_wakeup
monitor command is available.

In the future (my next patch in fact) we may want to make
decisions depending on qemu having a monitor command or not.
Therefore, we want to set qemuCaps flag instead of querying
on the monitor each time we are about to make that decision.

Language bindings may well want to use the libvirt-api.xml and
libvirt-qemu-api.xml files to either auto-generate themselves,
or sanity check the manually written bindings for completeness.
Currently these XML files are not installed as standard, merely
ending up as a %doc file in the RPM.

This changes them to be installed into $prefix/share/libvirt/apis/
The *-refs.xml files are not installed, since those are only
useful during generation of the online API doc files.

The pkg-config file is enhanced so that you can query the install
location of the API files. eg

  # pkg-config --variable=libvirt_qemu_api libvirt
  /home/berrange/builder/i686-pc-mingw32/sys-root/mingw/share/libvirt/libvirt-qemu-api.xml

* docs/Makefile.am: Install libvirt-api.xml & libvirt-qemu-api.xml
* libvirt.pc.in: Add vars for querying API install location
* libvirt.spec.in, mingw32-libvirt.spec.in: Include API XML files

When blkdeviotune was first committed in 0.9.8, we had the limitation
that setting one value reset all others.  But bytes and iops should
be relatively independent.  Furthermore, setting tuning values on
a live domain followed by dumpxml did not output the new settings.

* src/qemu/qemu_driver.c (qemuDiskPathToAlias): Add parameter, and
update callers.
(qemuDomainSetBlockIoTune): Don't lose previous unrelated
settings.  Make live changes reflect to dumpxml output.
* tools/virsh.pod (blkdeviotune): Update documentation.

* configure.ac docs/news.html.in libvirt.spec.in: updated for the release
* po/*.po*: update ja, it and uk localization, fixed the ja one

It's dompmsuspend, not suspend-duration.

Some programs, notably dnsmasq, which are writing pidfiles on their
own do append a whitespace character after pid, e.g. '\n'.

This reverts commit 7b345b69.

Conflicts:

	tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.xml

This reverts commit c9abfadf.

Conflicts:

	tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-virtio-scsi.xml

        *libvirt_virDomainBlockStatsFlags
        *libvirt_virDomainGetSchedulerParameters
        *libvirt_virDomainGetSchedulerParametersFlags
        *libvirt_virDomainSetSchedulerParameters
        *libvirt_virDomainSetSchedulerParametersFlags
        *libvirt_virDomainSetBlkioParameters
        *libvirt_virDomainGetBlkioParameters
        *libvirt_virDomainSetMemoryParameters
        *libvirt_virDomainGetMemoryParameters
        *libvirt_virDomainSetBlockIoTune
        *libvirt_virDomainGetBlockIoTune

Replace calls to fwrite() and fscanf() with more portable-friendly
version, such as snprintf() and virStrToLong().

It breaks the build on Mingw32,  because PRIx64 is coming
from the Win32 headers, but virAsprintf uses the gnulib printf.

Detected by valgrind. Leaks are introduced in commit c1b22644.

* src/remote/remote_driver.c (doRemoteOpen): free client program memory in failure path.

* How to reproduce?
% valgrind -v --leak-check=full virsh -c qemu:

* Actual result

==3969== 40 bytes in 1 blocks are definitely lost in loss record 8 of 28
==3969==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
    ==3969==    by 0x4C89C41: virAlloc (memory.c:101)
    ==3969==    by 0x4D5A236: virNetClientProgramNew (virnetclientprogram.c:60)
    ==3969==    by 0x4D47AB4: doRemoteOpen (remote_driver.c:658)
    ==3969==    by 0x4D49FFF: remoteOpen (remote_driver.c:871)
    ==3969==    by 0x4D13373: do_open (libvirt.c:1196)
    ==3969==    by 0x4D14535: virConnectOpenAuth (libvirt.c:1422)
    ==3969==    by 0x425627: main (virsh.c:18537)
    ==3969==
    ==3969== 40 bytes in 1 blocks are definitely lost in loss record 9 of 28
    ==3969==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
    ==3969==    by 0x4C89C41: virAlloc (memory.c:101)
    ==3969==    by 0x4D5A236: virNetClientProgramNew (virnetclientprogram.c:60)
    ==3969==    by 0x4D47AD7: doRemoteOpen (remote_driver.c:664)
    ==3969==    by 0x4D49FFF: remoteOpen (remote_driver.c:871)
    ==3969==    by 0x4D13373: do_open (libvirt.c:1196)
    ==3969==    by 0x4D14535: virConnectOpenAuth (libvirt.c:1422)
    ==3969==    by 0x425627: main (virsh.c:18537)
    ==3969==
    ==3969== LEAK SUMMARY:
    ==3969==    definitely lost: 80 bytes in 2 blocks
Signed-off-by: NAlex Jia <ajia@redhat.com>

The auto-generated WWN comply with the new addressing schema of WWN:

<quote>
the first nibble is either hex 5 or 6 followed by a 3-byte vendor
identifier and 36 bits for a vendor-specified serial number.
</quote>

We choose hex 5 for the first nibble. And for the 3-bytes vendor ID,
we uses the OUI according to underlying hypervisor type, (invoking
virConnectGetType to get the virt type). e.g. If virConnectGetType
returns "QEMU", we use Qumranet's OUI (00:1A:4A), if returns
ESX|VMWARE, we use VMWARE's OUI (00:05:69). Currently it only
supports qemu|xen|libxl|xenapi|hyperv|esx|vmware drivers. The last
36 bits are auto-generated.

Some audit records generated by libvirt contain fields enclosed by single
quotes. Since those fields are inside the msg field, which is enclosed by
single quotes, these records generated by libvirt are not correctly parsed by
libauparse.

Bug introduced in commit c6ec021b.
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

Some tools, such as virt-manager, prefers having the default USB
controller explicit in the XML document. This patch makes sure there
is one. With this patch, it is now possible to switch from USB1 to
USB2 from the release 0.9.1 of virt-manager.

Fix tests to pass with this change.

          *getPyVirTypedParameter
          *setPyVirTypedParameter
          *virDomainSetNumaParameters
          *virDomainGetNumaParameters
Signed-off-by: NEric Blake <eblake@redhat.com>

* docs/python.html.in: Class is virConnect, not virConn.

romfile wasn't mentioned in the comment, and the fact that rombar is
now supported for network interfaces also wasn't there.

The API definition accepts "flags" argument, however, the
implementation ignores it, though "flags" is unused currently,
we should expose it instead of hard coding, the API
implementation inside hypervisor driver is responsible to check
if the passed "flags" is valid.

virsh blkiotune dom --device-weights /dev/sda,400 --config

wasn't working correctly.

* src/qemu/qemu_driver.c (qemuDomainSetBlkioParameters): Use
correct definition.

The merge code had too many indirections to easily analyze.

* src/qemu/qemu_driver.c (qemuDomainMergeDeviceWeights): Pick
better variable names.

Now that no one is relying on the return value being a pointer to
somewhere inside of the passed-in argument, we can simplify the
callers to simply return success or failure.  Also wrap some long
lines and add some const-correctness.

* src/util/sysinfo.c (virSysinfoParseBIOS, virSysinfoParseSystem)
(virSysinfoParseProcessor, virSysinfoParseMemory): Change return.
(virSysinfoRead): Adjust caller.

Some applications expect /dev/std{in,out,err} to exist. Populate
them during container startup as symlinks to /proc/self/fd

Mingw32 does not have any truncate() API defined, but it does
have ftruncate(). So replace use of the former with the latter

This patch fixes the domain modification impact flags for tie virsh
desc command to match the new semantics and fix the docs to match
actual behavior.

Reported by Alex Jia:

==21503== 112 (32 direct, 80 indirect) bytes in 1 blocks are
definitely lost in loss record 37 of 40
==21503==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==21503==    by 0x4A8991: virAlloc (memory.c:101)
==21503==    by 0x505A6C: x86DataCopy (cpu_x86.c:247)
==21503==    by 0x507B34: x86Compute (cpu_x86.c:1225)
==21503==    by 0x43103C: qemuBuildCommandLine (qemu_command.c:3561)
==21503==    by 0x41C9F7: testCompareXMLToArgvHelper
(qemuxml2argvtest.c:183)
==21503==    by 0x41E10D: virtTestRun (testutils.c:141)
==21503==    by 0x41B942: mymain (qemuxml2argvtest.c:705)
==21503==    by 0x41D7E7: virtTestMain (testutils.c:696)

This is probably not strictly needed as save operation is not live but
we may have other reasons to avoid blocking qemu's main loop.

In case the caller specifies that confined guests are required but the
security driver turns out to be 'none', we should return an error since
this driver clearly cannot meet that requirement.  As a result of this
error, libvirtd fails to start when the host admin explicitly sets
confined guests are required but there is no security driver available.

Since security driver 'none' cannot create confined guests, we override
default confined setting so that hypervisor drivers do not thing they
should create confined guests.

Security label type 'none' requires relabel to be set to 'no' so there's
no reason to output this extra attribute.  Moreover, since relabel is
internally stored in a negative from (norelabel), the default value for
relabel would be 'yes' in case there is no <seclabel> element in domain
configuration.  In case VIR_DOMAIN_SECLABEL_DEFAULT turns into
VIR_DOMAIN_SECLABEL_NONE, we would incorrectly output relabel='yes' for
seclabel type 'none'.

Qemu uses non-blocking I/O which doesn't play nice with regular file
descriptors. We need to pass a pipe to qemu instead, which can easily be
done using iohelper.

virFileDirectFd was used for accessing files opened with O_DIRECT using
libvirt_iohelper. We will want to use the helper for accessing files
regardless on O_DIRECT and thus virFileDirectFd was generalized and
renamed to virFileWrapperFd.

Any device XML doesn't use the same order as libvirt generates, or
uses decimal for attributes like "slot" of "<address>" will cause
device detaching to fail, as virsh compares the XML simply earlier
in strict manner before internal parsing.

This is regression introduced by ea7182c2.

Gcc warned about an unused static function.

* python/libvirt-qemu-override.c (py_str): Delete.

 dmidecode displays processor information, followed by BIOS, system and
 memory-DIMM details.
 Calls to virSysinfoParseBIOS(), virSysinfoParseSystem() would update
 the buffer pointer 'base', so the processor information would be lost
 before virSysinfoParseProcessor() was called. Sysinfo would therefore
 not be able to display processor details -- It only described <bios>,
 <system> and <memory_device> details.
 This patch attempts to insulate sysinfo from ordering of dmidecode
 output.

Before the fix:
---------------
virsh # sysinfo
<sysinfo type='smbios'>
  <bios>
    ....
  </bios>
  <system>
    ....
  </system>
  <memory_device>
    ....
  </memory_device>

After the fix:
-------------
virsh # sysinfo
<sysinfo type='smbios'>
  <bios>
    ....
  </bios>
  <system>
    ....
  </system>
  <processor>
    ....
  </processor>
  <memory_device>
    ....
  </memory_device>