(cherry picked from commit 81af5336)

Conflicts:
	src/qemu/qemu_command.c
	tests/qemuxml2argvdata/qemuxml2argv-bios.args
	tests/qemuxml2argvdata/qemuxml2argv-blkiotune-device.args
	tests/qemuxml2argvdata/qemuxml2argv-blkiotune.args
	tests/qemuxml2argvdata/qemuxml2argv-boot-menu-disable-drive-bootindex.args
	tests/qemuxml2argvdata/qemuxml2argv-console-virtio-s390.args
	tests/qemuxml2argvdata/qemuxml2argv-cpu-eoi-disabled.args
	tests/qemuxml2argvdata/qemuxml2argv-cpu-eoi-enabled.args
	tests/qemuxml2argvdata/qemuxml2argv-cputune.args
	tests/qemuxml2argvdata/qemuxml2argv-disk-blockio.args
	tests/qemuxml2argvdata/qemuxml2argv-disk-copy_on_read.args
	tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-auth.args
	tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd.args
	tests/qemuxml2argvdata/qemuxml2argv-disk-geometry.args
	tests/qemuxml2argvdata/qemuxml2argv-disk-ide-drive-split.args
	tests/qemuxml2argvdata/qemuxml2argv-disk-ide-wwn.args
	tests/qemuxml2argvdata/qemuxml2argv-disk-ioeventfd.args
	tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-split.args
	tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.args
	tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-s390.args
	tests/qemuxml2argvdata/qemuxml2argv-eoi-disabled.args
	tests/qemuxml2argvdata/qemuxml2argv-eoi-enabled.args
	tests/qemuxml2argvdata/qemuxml2argv-event_idx.args
	tests/qemuxml2argvdata/qemuxml2argv-graphics-spice.args
	tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc.args
	tests/qemuxml2argvdata/qemuxml2argv-hyperv.args
	tests/qemuxml2argvdata/qemuxml2argv-kvmclock+eoi-disabled.args
	tests/qemuxml2argvdata/qemuxml2argv-machine-core-off.args
	tests/qemuxml2argvdata/qemuxml2argv-machine-core-on.args
	tests/qemuxml2argvdata/qemuxml2argv-memtune.args
	tests/qemuxml2argvdata/qemuxml2argv-metadata.args
	tests/qemuxml2argvdata/qemuxml2argv-minimal-s390.args
	tests/qemuxml2argvdata/qemuxml2argv-minimal.args
	tests/qemuxml2argvdata/qemuxml2argv-misc-disable-s3.args
	tests/qemuxml2argvdata/qemuxml2argv-misc-disable-suspends.args
	tests/qemuxml2argvdata/qemuxml2argv-misc-enable-s4.args
	tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.args
	tests/qemuxml2argvdata/qemuxml2argv-net-virtio-s390.args
	tests/qemuxml2argvdata/qemuxml2argv-numad-auto-memory-vcpu-cpuset.args
	tests/qemuxml2argvdata/qemuxml2argv-numad-auto-memory-vcpu-no-cpuset-and-placement.args
	tests/qemuxml2argvdata/qemuxml2argv-numad-auto-vcpu-static-numatune.args
	tests/qemuxml2argvdata/qemuxml2argv-numad-static-memory-auto-vcpu.args
	tests/qemuxml2argvdata/qemuxml2argv-numad.args
	tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-disabled.args
	tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-enabled.args
	tests/qemuxml2argvdata/qemuxml2argv-seclabel-dynamic-baselabel.args
	tests/qemuxml2argvdata/qemuxml2argv-seclabel-dynamic-override.args
	tests/qemuxml2argvdata/qemuxml2argv-seclabel-dynamic.args
	tests/qemuxml2argvdata/qemuxml2argv-seclabel-none.args
	tests/qemuxml2argvdata/qemuxml2argv-seclabel-static-relabel.args
	tests/qemuxml2argvdata/qemuxml2argv-seclabel-static.args
	tests/qemuxml2argvdata/qemuxml2argv-smbios.args
	tests/qemuxml2argvdata/qemuxml2argv-virtio-lun.args

(cherry picked from commit 8f708761)

The string comparison logic was inverted and matched the first drive
that does *not* have the name we search for.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 23d47b33)

The QEMU -drive id= begins with libvirt's QEMU host drive prefix
("drive-"), which is stripped off in several places two convert between
host ("-drive") and guest ("-device") device names.

In the case of BlkIoTune it is unnecessary to strip the QEMU host drive
prefix because we operate on "info block"/"query-block" output that uses
host drive names.

Stripping the prefix incorrectly caused string comparisons to fail since
we were comparing the guest device name against the host device name.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 04ee70bf)

If debugging is enabled, the debug messages are sent to stderr.
Moreover, if a command has catching of stderr set, the messages
gets mixed with stdout output (assuming both outputs are stored
in the same variable). The resulting string then doesn't
necessarily have to start with desired prefix then. This bug
exposes itself when parsing dnsmasq output:

2012-12-06 11:18:11.445+0000: 18491: error :
dnsmasqCapsSetFromBuffer:664 : internal error cannot parse
/usr/sbin/dnsmasq version number in '2012-12-06
11:11:02.232+0000: 18492: debug : virFileClose:72 : Closed fd 22'

We can clearly see that the output of dnsmasq --version doesn't
start with expected "Dnsmasq version " string but a libvirt debug
output.
(cherry picked from commit ff33f807)

If the debugging is enabled, the virCommand subsystem catches debug
messages in the command output as well. In that case, we can't assume
the string corresponding to command's stdout will start with specific
prefix. But the prefix can be moved deeper in the string. This bug
shows itself when parsing dnsmasq output:

2012-12-06 11:18:11.445+0000: 18491: error :
dnsmasqCapsSetFromBuffer:664 : internal error cannot parse
/usr/sbin/dnsmasq version number in '2012-12-06 11:11:02.232+0000:
18492: debug : virFileClose:72 : Closed fd 22'

We can clearly see that the output of dnsmasq --version
doesn't start with expected "Dnsmasq version " string but a libvirt
debug output.
(cherry picked from commit 51144313)

This resolves:

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

These three functions:

  virDomainNetGetActualBridgeName
  virDomainNetGetActualDirectDev
  virDomainNetGetActualDirectMode

return attributes that are in a union whose contents are interpreted
differently depending on the actual->type and so they should only
return non-0 when actual->type is 'bridge' (in the first case) or
'direct' (in the other two cases, but I had neglected to do that, so
...DirectDev() was returning bridge.brname (which happens to share the
same spot in the union with direct.linkdev) if actual->type was
'bridge', and ...BridgeName was returning direct.linkdev when
actual->type was 'direct'.

How does this involve Bug 881480 (which was about the inability to
switch between two networks that both have "<forward mode='bridge'/>
<bridge name='xxx'/>"? Whenever the return value of
virDomainNetGetActualDirectDev() for the new and old network
definitions doesn't match, qemuDomainChangeNet() requires a "complete
reconnect" of the device, which qemu currently doesn't
support. ...DirectDev() *should* have been returning NULL for old and
new, but was instead returning the old and new bridge names, which
differ.

(The other two functions weren't causing any behavioral problems in
virDomainChangeNet(), but their problem and fix was identical, so I
included them in this same patch).

This bug resolves CVE-2012-3411, which is described in the following
bugzilla report:

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

The following report is specifically for libvirt on Fedora:

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

In short, a dnsmasq instance run with the intention of listening for
DHCP/DNS requests only on a libvirt virtual network (which is
constructed using a Linux host bridge) would also answer queries sent
from outside the virtualization host.

This patch takes advantage of a new dnsmasq option "--bind-dynamic",
which will cause the listening socket to be setup such that it will
only receive those requests that actually come in via the bridge
interface. In order for this behavior to actually occur, not only must
"--bind-interfaces" be replaced with "--bind-dynamic", but also all
"--listen-address" options must be replaced with a single
"--interface" option. Fully:

   --bind-interfaces --except-interface lo --listen-address x.x.x.x ...

(with --listen-address possibly repeated) is replaced with:

   --bind-dynamic --interface virbrX

Of course libvirt can't use this new option if the host's dnsmasq
doesn't have it, but we still want libvirt to function (because the
great majority of libvirt installations, which only have mode='nat'
networks using RFC1918 private address ranges (e.g. 192.168.122.0/24),
are immune to this vulnerability from anywhere beyond the local subnet
of the host), so we use the new dnsmasqCaps API to check if dnsmasq
supports the new option and, if not, we use the "old" option style
instead. In order to assure that this permissiveness doesn't lead to a
vulnerable system, we do check for non-private addresses in this case,
and refuse to start the network if both a) we are using the old-style
options, and b) the network has a publicly routable IP
address. Hopefully this will provide the proper balance of not being
disruptive to those not practically affected, and making sure that
those who *are* affected get their dnsmasq upgraded.

(--bind-dynamic was added to dnsmasq in upstream commit
54dd393f3938fc0c19088fbd319b95e37d81a2b0, which was included in
dnsmasq-2.63)

(cherry picked from commit 753ff83a)
Conflicts:
        src/network/bridge_driver.c
        * needed to change virReportError() to the older
          networkReportError()

	tests/networkxml2argvdata/nat-network-dns-txt-record.argv
        * this test file has an example of an arg with embedded space,
          which gets sorrounded by '' in newer releases. Other
          items on the same line had been modified.

	tests/networkxml2argvdata/routed-network.argv
        * in the newer releases, this test file had an --addn-hosts
          arg that didn't exist on this branch. Again, it was in the
          surrounding context of the changes that had been made on
          master.

This new function returns true if the given address is in the range of
any "private" or "local" networks as defined in RFC1918 (IPv4) or
RFC3484/RFC4193 (IPv6), otherwise they return false.

These ranges are:

   192.168.0.0/16
   172.16.0.0/16
   10.0.0.0/24
   FC00::/7
   FEC0::/10

(cherry picked from commit bf402e77)
Conflicts:
    src/util/virsocketaddr.c
    src/util/virsocketaddr.h
     * both of these files had new functions that had been added
       at the same place virSocketAddrIsPrivate was being added,
       so the context on the branch didn't match.

In order to optionally take advantage of new features in dnsmasq when
the host's version of dnsmasq supports them, but still be able to run
on hosts that don't support the new features, we need to be able to
detect the version of dnsmasq running on the host, and possibly
determine from the help output what options are in this dnsmasq.

This patch implements a greatly simplified version of the capabilities
code we already have for qemu. A dnsmasqCaps device can be created and
populated either from running a program on disk, reading a file with
the concatenated output of "dnsmasq --version; dnsmasq --help", or
examining a buffer in memory that contains the concatenated output of
those two commands. Simple functions to retrieve capabilities flags,
the version number, and the path of the binary are also included.

bridge_driver.c creates a single dnsmasqCaps object at driver startup,
and disposes of it at driver shutdown. Any time it must be used, the
dnsmasqCapsRefresh method is called - it checks the mtime of the
binary, and re-runs the checks if the binary has changed.

networkxml2argvtest.c creates 2 "artificial" dnsmasqCaps objects at
startup - one "restricted" (doesn't support --bind-dynamic) and one
"full" (does support --bind-dynamic). Some of the test cases use one
and some the other, to make sure both code pathes are tested.

(cherry picked from commit 719c2c76)

Conflicts:
  src/network/bridge_driver.c
  * some new functions are missing in the backport, so they don't need
    to be modified.
  * Use dnsmasqCapsFree() instead of virObjectUnref()
  src/util/dnsmasq.c
  * eliminate use of virObject, since this version of libvirt
    doesn't yet have it
  * use networkReportError() instead of virReportError()
  * virBitmapAlloc() instead of virBitmapNew()
  src/util/dnsmasq.h
  * don't #include virobject.h
  * add prototype for dnsmasqCapsFree()
  src/libvirt_private.syms
  * export dnsmasqCapsFree

In Fedora 16, we quit enabling cgconfig because systemd set up
default cgroups that were good enough for our use.  But in F17,
when we switched to systemd, we reverted and started up cgconfig
again.  See also the tail of this thread:
https://www.redhat.com/archives/libvir-list/2012-October/msg01657.html

* libvirt.spec.in (with_systemd): Rely on systemd for cgroups.
(cherry picked from commit b61eadf3)

https://bugzilla.redhat.com/show_bug.cgi?id=636832
(cherry picked from commit 9a297578)

Conflicts:
	src/qemu/qemu_driver.c

When restoring selinux labels after a VM is stopped, any non-standard
path that doesn't have a default selinux label causes the process
to stop and exit early. This isn't really an error condition IMO.

Of course the selinux API could be erroring for some other reason
but hopefully that's rare enough to not need explicit handling.

Common example here is storing disk images in a non-standard location
like under /mnt.
(cherry picked from commit 767be8be)

If building on a 64bit host, rename the affected tapsets to <name>-64.stp.
This is similar to what the python package does in fedora.

https://bugzilla.redhat.com/show_bug.cgi?id=831425
(cherry picked from commit 18d0632d)

Conflicts:
	libvirt.spec.in

We were just installing them in the top level html directory, which
broke navigation and overwrote other pages.

https://bugzilla.redhat.com/show_bug.cgi?id=837825
(cherry picked from commit 7146d416)

Conflicts:
	docs/Makefile.am

https://bugzilla.redhat.com/show_bug.cgi?id=860004
(cherry picked from commit 2143ced7)

On F17 at least, every time libvirtd starts we get this in syslog:

libvirtd: Could not find keytab file: /etc/libvirt/krb5.tab: No such file or directory

This comes from cyrus-sasl, and happens regardless of whether the
gssapi plugin is requested, which is what actually uses
/etc/libvirt/krb5.tab.

While cyrus-sasl shouldn't complain, we can easily make it shut up by
commenting out the keytab value by default.

Also update the keytab comment to the more modern one from qemu's
sasl config file.
(cherry picked from commit fe772f24)

Before:
$ sudo virsh vol-create-as --pool vgvirt sparsetest --capacity 16M --allocation 0
error: Failed to create vol sparsetest
error: internal error Child process (/usr/sbin/lvchange -aln vgvirt/sparsetest) unexpected exit status 5:   One or more specified logical volume(s) not found.

After:
$ sudo virsh vol-create-as --pool vgvirt sparsetest --capacity 16M --allocation 0
error: Failed to create vol sparsetest
error: internal error Child process (/usr/sbin/lvcreate --name sparsetest -L 0K --virtualsize 16384K vgvirt) unexpected exit status 5:   Unable to create new logical volume with no extents
(cherry picked from commit 01df6f2b)

Conflicts:
	src/storage/storage_backend_logical.c

When p2p migration fails early because qemuMigrationIsAllowed or
qemuMigrationIsSafe say migration should be cancelled, we fail to clear
the migration-out async job. As a result of that, further APIs called
for the same domain may fail with Timed out during operation: cannot
acquire state change lock.

Reported by Guido Winkelmann.

This reverts commit d4ffc36f.
That commit cherry-picked from 68a97bd8 in isolation, but should
really only be needed if we had also cherry-picked 387117ad.

This patch removed the "--filterwin2k" dnsmasq command line
parameter which was unnecessary for domain specification,
possibly blocked some usage, and was command line clutter.

Gene Czarcinski <gene@czarc.net>
(cherry picked from commit f20b7dbe)

Conflicts:
	tests/networkxml2argvdata/nat-network-dns-txt-record.argv

dnsmasq is forwarding a number of queries upstream that should not
be done.  There still remains an MX query for a plain name with no
domain specified that will be forwarded is dnsmasq has --domain=xxx
--local=/xxx/ specified. This does not happen with no domain name
and --local=// ... not a libvirt problem.

BTW, thanks again to Claudio Bley!
(cherry picked from commit f3868259)

Conflicts:
	AUTHORS

Fix for CVE-2012-4423.

When generating RPC protocol messages, it's strictly needed to have a
continuous line of numbers or RPC messages. However in case anyone
tries backporting some functionality and will skip a number, there is
a possibility to make the daemon segfault with newer virsh (version of
the library, rpc call, etc.) even unintentionally.

The problem is that the skipped numbers will get func filled with
NULLs, but there is no check whether these are set before the daemon
tries to run them. This patch very simply enhances one check and fixes
that.
(cherry picked from commit b7ff9e69)

Commit a56c3470 introduced a use of random numbers into seclabel
handling, but failed to initialize the random number generator
in the testsuite.  Also, fail with usual status, not 255.

* tests/seclabeltest.c (main): Initialize randomness.
(cherry picked from commit a22a36e8)

Conflicts:
	tests/seclabeltest.c

First 'poll' can't return EWOULDBLOCK, and second, we're checking errno
so far away from the poll() call that we've probably already trashed the
original errno value.
(cherry picked from commit 5d490603)

In addition to keepalive responses, we also need to send keepalive
requests from client IO loop to properly detect dead connection in case
a libvirt API is called from the main loop, which prevents any timers to
be called.
(cherry picked from commit 4d971dc7)

We don't need to add or remove filters when client object is already
locked anymore. There's no reason to keep the *Locked variants of those
APIs.
(cherry picked from commit d9ad4166)

The previous commit removed the only usage of ``all'' parameter in
virKeepAliveStopInternal, which was actually the only reason for having
virKeepAliveStopInternal. This effectively reverts most of commit
6446a9e2.
(cherry picked from commit 0ec514b3)

When a libvirt API is called from the main event loop (which seems to be
common in event-based glib apps), the client IO loop would properly
handle keepalive requests sent by a server but will not actually send
them because the main event loop is blocked with the API. This patch
gets rid of response timer and the thread which is processing keepalive
requests is also responsible for queueing responses for delivery.
(cherry picked from commit bb85f229)

This makes it possible to create and queue new calls while we are
running IO loop.
(cherry picked from commit c57103e5)

Add virKeepAliveTimeout and virKeepAliveTrigger APIs that can be used to
set poll timeouts and trigger keepalive timer. virKeepAliveTrigger
checks if it is called to early and does nothing in that case.
(cherry picked from commit 28c75382)

The code that needs to be run every keepalive interval of inactivity was
only called from a timer and thus from the main event loop. We will need
to call the code directly from another place.
(cherry picked from commit a2ba8686)

As we never drop non-blocking calls, the return value that used to
indicate a call was dropped is no longer needed.
(cherry picked from commit ca9b13e3)

As non-blocking calls are no longer dropped, we don't really need to
care that much about their fate and wait for the thread with the buck
to process them. If another thread has the buck, we can just push a
non-blocking call to the queue and be done with it.
(cherry picked from commit ef392614)

So far, we were dropping non-blocking calls whenever sending them would
block. In case a client is sending lots of stream calls (which are not
supposed to generate any reply), the assumption that having other calls
in a queue is sufficient to get a reply from the server doesn't work. I
tried to fix this in b1e374a7 but
failed and reverted that commit.

With this patch, non-blocking calls are never dropped (unless the
connection is being closed) and will always be sent.
(cherry picked from commit 78602c4e)

Normally, when every call has a thread associated with it, the thread
may get the buck and be in charge of sending all calls until its own
call is done. When we introduced non-blocking calls, we had to add
special handling of new non-blocking calls. This patch uses event loop
to send data if there is no thread to get the buck so that any
non-blocking calls left in the queue are properly sent without having to
handle them specially. It also avoids adding even more cruft to client
IO loop in the following patches.

With this change in, non-blocking calls may see unpredictable delays in
delivery when the client has no event loop registered. However, the only
non-blocking calls we have are keepalives and we already require event
loop for them, which makes this a non-issue until someone introduces new
non-blocking calls.
(cherry picked from commit 9e747e5c)