Upstream is no longer willing to backport patches to a branch
this old.  If you disagree with the policy, please volunteer
to become the branch maintainer on libvir-list@redhat.com
Signed-off-by: NEric Blake <eblake@redhat.com>

When given a CA cert with basic constraints to set non-critical,
and key usage of 'key signing', this should be rejected. Version
of GNUTLS < 3 do not rejecte it though, so we never noticed the
test case was broken
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 0204d6d7)
(cherry picked from commit ec5190af)

Make has a builtin operator 'undefine', and coupled with latest
automake.git, this test name ended up confusing make into thinking
the file name was meant to be used as the make operator.  Renaming
the file avoids the confusion.

* tests/undefine: Rename...
* tests/virsh-undefine: ...to this.
* tests/Makefile.am (test_scripts): Use new name.
Reported by Jim Meyering.

(cherry picked from commit a20f06d9)

Introduced by 7b87a3
When I quit the process which only register VIR_DOMAIN_EVENT_ID_REBOOT,
I got error like:
"libvirt: XML-RPC error : internal error: domain event 0 not registered".
Then I add the following code, it fixed.
Signed-off-by: NZhou Yimin <zhouyimin@huawei.com>
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 9712c251)

Conflicts:
	src/remote/remote_driver.c - context

https://bugzilla.redhat.com/show_bug.cgi?id=888071
(cherry picked from commit d60c7f75)

The Fedora policies don't want us installing the legacy initscripts
in parallel with the systemd ones, so switch to only install the
systemd unit
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 49e5abb6)

Done by 'git merge -s ours v0.9.11.6', so that the maint branch
will contain all release tags.
Signed-off-by: NEric Blake <eblake@redhat.com>

qemu-img resize will fail with "The new size must be a multiple of 512"
if libvirt doesn't round it first.
This fixes rhbz#951495
Signed-off-by: NChristophe Fergeau <cfergeau@redhat.com>
(cherry picked from commit 9a8f39d0)

Reported by Anthony Messina in
https://bugzilla.redhat.com/show_bug.cgi?id=904692
Present since introduction of smartcard support in commit f5fd9baa

* src/qemu/qemu_command.c (qemuBuildCommandLine): Match qemu spelling.
* tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.args:
Fix broken test.
(cherry picked from commit 6f7e4ea3)

This reverts commit 71e88fc5.

Accidental double commit.

This reverts commit d23e735f.

Accidental double commit.

Commit c308a9ae was incomplete; it resolved the configure failure,
but not a later build failure.

* src/util/virnetdevbridge.c: Include pre-req header.
* configure.ac (AC_CHECK_HEADERS): Prefer standard in.h over
non-standard ip6.h.
(cherry picked from commit 1bf661ca)
(cherry picked from commit 2c7638fd)

Conflicts:
	src/util/virnetdevbridge.c

I got this scary warning during ./configure on rawhide:

checking linux/if_bridge.h usability... no
checking linux/if_bridge.h presence... yes
configure: WARNING: linux/if_bridge.h: present but cannot be compiled
configure: WARNING: linux/if_bridge.h:     check for missing prerequisite headers?
configure: WARNING: linux/if_bridge.h: see the Autoconf documentation
configure: WARNING: linux/if_bridge.h:     section "Present But Cannot Be Compiled"
configure: WARNING: linux/if_bridge.h: proceeding with the compiler's result
configure: WARNING:     ## ------------------------------------- ##
configure: WARNING:     ## Report this to libvir-list@redhat.com ##
configure: WARNING:     ## ------------------------------------- ##
checking for linux/if_bridge.h... no

* configure.ac (AC_CHECK_HEADERS): Provide struct in6_addr, since
linux/if_bridge.h uses it without declaring it.
(cherry picked from commit c308a9ae)
(cherry picked from commit 7ae53f15)
(cherry picked from commit 879f28a9)

Conflicts:
	configure.ac

Several people have reported that if the .gnulib submodule is dirty,
then 'make' will go into an infinite loop attempting to rerun bootstrap,
because that never cleans up the dirty submodule.  By default, we
should halt and make the user investigate, but if the user doesn't
know why or care that the submodule is dirty, I also added the ability
to 'make CLEAN_SUBMODULE=1' to get things going again.

Also, while testing this, I noticed that when a submodule update was
needed, 'make' would first run autoreconf, then bootstrap (which
reruns autoreconf); adding a strategic dependency allows for less work.

* .gnulib: Update to latest, for maint.mk improvements.
* cfg.mk (_autogen): Also hook maint.mk, to run before autoreconf.
* autogen.sh (bootstrap): Refuse to run if gnulib is dirty, unless
user requests discarding gnulib changes.
(cherry picked from commit c5f16220)

Conflicts:
	.gnulib

Commit 64297313 added three direct
references to nl_handle_* instead of using our aliases which hide
differences between libnl-3 and libnl-1.
(cherry picked from commit d9d39e62)

Commit 9298bfbc introduced code to detect if netcf is linked with
libnl1, and to prefer libnl1 over libnl3 when this is the case.
This behaviour can be disabled by setting LIBNL_CFLAGS to any value,
including the empty string.
However, configure.ac sets LIBNL_CFLAGS to "" before attempting
libnl detection, so the libnl1 detection code is always disabled.
This caused issues on my f17 system where netcf is linked with libnl1
but libvirt got built with libnl3.

This commit removes the setting of the LIBNL_* variables to "" as
this does not appear to be needed. After this change, libnl1 is
used when building libvirt on my f17 system.
(cherry picked from commit f6c29515)

Recent spec file changes ensure that in distro situations, netcf
and libvirt will link against the same libnl in order to avoid
dumping core.  But for every-day development, if you use F17 and
have the libnl3-devel headers available, libvirt was blindly
linking against libnl3 even though F17 netcf still links against
libnl1, making testing a self-built binary on F17 impossible.

By making configure a little bit smarter, we can avoid this
situation - we merely skip the probe of libnl-3 if we can prove
that netcf is still using libnl-1.  I intentionally wrote the
test so that we still favor libnl-3 if netcf is not installed or
if we couldn't use ldd to determine things.

Defaults being what they are, someone will invariably complain
that our smarts were wrong.  Never fear - in that case, just run
./configure LIBNL_CFLAGS=..., where the fact that you set
LIBNL_CFLAGS (even to the empty string) will go back to probing
for libnl-3, regardless of netcf's choice.

* configure.ac (LIBNL): Don't probe libnl3 if netcf doesn't use it.
(cherry picked from commit 9298bfbc)

configure.ac: check for libnl-3 in addition to libnl-1

src/Makefile.am: link against libnl when needed

src/util/virnetlink.c:
support libnl3 api.  To minimize impact on code flow, wrap the
differences under the virNetlink* namespace.

Unfortunately libnl3 moves netlink/msg.h to
/usr/include/libnl3/netlink/msg.h, so the LIBNL_CFLAGS need to be added
to a bunch of places where they weren't needed with libnl1.
Signed-off-by: NSerge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 60fb8a22)

Conflicts:
	src/Makefile.am - dbus changes not backported

Specific to v0.9.11.  This is the opposite of commit dfa1e1dd,
and done for the purposes of minimal code changes to allow
compilation of libxl on Fedora 17 which still has experimental
libxl 4.1, while still being able to compile the branch (minus
libxl code) on Fedora 18 and later.
Signed-off-by: NEric Blake <eblake@redhat.com>

In Xen 4.2, xs.h is deprecated in favor of xenstore.h.  xs.h now
contains

#warning xs.h is deprecated use xenstore.h instead
#include <xenstore.h>

which fails compilation when warnings are treated as errors.

Introduce a configure-time check for xenstore.h and if found,
use it instead of xs.h.
(cherry picked from commit 416eca18)

Since we switched from direct host migration scheme to the one,
where we connect to the destination and then just pass a FD to a
qemu, we have uncovered a qemu bug. Qemu expects migration FD to
block. However, we are passing a nonblocking one which results in
cryptic error messages like:

  qemu: warning: error while loading state section id 2
  load of migration failed

The bug is already known to Qemu folks, but we should workaround
already released Qemus. Patch has been originally proposed by Stefan
Hajnoczi <stefanha@gmail.com>
(cherry picked from commit ceb31795)

Commit c308a9ae was incomplete; it resolved the configure failure,
but not a later build failure.

* src/util/virnetdevbridge.c: Include pre-req header.
* configure.ac (AC_CHECK_HEADERS): Prefer standard in.h over
non-standard ip6.h.
(cherry picked from commit 1bf661ca)

Conflicts:
	src/util/virnetdevbridge.c

I got this scary warning during ./configure on rawhide:

checking linux/if_bridge.h usability... no
checking linux/if_bridge.h presence... yes
configure: WARNING: linux/if_bridge.h: present but cannot be compiled
configure: WARNING: linux/if_bridge.h:     check for missing prerequisite headers?
configure: WARNING: linux/if_bridge.h: see the Autoconf documentation
configure: WARNING: linux/if_bridge.h:     section "Present But Cannot Be Compiled"
configure: WARNING: linux/if_bridge.h: proceeding with the compiler's result
configure: WARNING:     ## ------------------------------------- ##
configure: WARNING:     ## Report this to libvir-list@redhat.com ##
configure: WARNING:     ## ------------------------------------- ##
checking for linux/if_bridge.h... no

* configure.ac (AC_CHECK_HEADERS): Provide struct in6_addr, since
linux/if_bridge.h uses it without declaring it.
(cherry picked from commit c308a9ae)

When running virDomainDestroy, we need to make sure that no other
background thread cleans up the domain while we're doing our work.
This can happen if we release the domain object while in the
middle of work, because the monitor might detect EOF in this window.
For this reason we have a 'beingDestroyed' flag to stop the monitor
from doing its normal cleanup. Unfortunately this flag was only
being used to protect qemuDomainBeginJob, and not qemuProcessKill

This left open a race condition where either libvirtd could crash,
or alternatively report bogus error messages about the domain already
having been destroyed to the caller
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 81621f3e)

Conflicts:
	src/qemu/qemu_driver.c

This patch resolves CVE-2013-0170:
https://bugzilla.redhat.com/show_bug.cgi?id=893450

When reading and dispatching of a message failed the message was freed
but wasn't removed from the message queue.

After that when the connection was about to be closed the pointer for
the message was still present in the queue and it was passed to
virNetMessageFree which tried to call the callback function from an
uninitialized pointer.

This patch removes the message from the queue before it's freed.

* rpc/virnetserverclient.c: virNetServerClientDispatchRead:
    - avoid use after free of RPC messages
(cherry picked from commit 46532e3e)

This is an adjustment to the fix for

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

to account for two bonehead mistakes I made.

commit ac2797cf attempted to fix a
problem with netlink in newer kernels requiring an extra attribute
with a filter flag set in order to receive an IFLA_VFINFO_LIST from
netlink. Unfortunately, the #ifdef that protected against compiling it
in on systems without the new flag went a bit too far, assuring that
the new code would *never* be compiled, and even if it had, the code
was incorrect.

The first problem was that, while some IFLA_* enum values are also
their existence at compile time, IFLA_EXT_MASK *isn't* #defined, so
checking to see if it's #defined is not a valid method of determining
whether or not to add the attribute. Fortunately, the flag that is
being set (RTEXT_FILTER_VF) *is* #defined, and it is never present if
IFLA_EXT_MASK isn't, so it's sufficient to just check for that flag.

And to top it off, due to the code not actually compiling when I
thought it did, I didn't realize that I'd been given the wrong arglist
to nla_put() - you can't just send a const value to nla_put, you have
to send it a pointer to memory containing what you want to add to the
message, along with the length of that memory.

This time I've actually sent the patch over to the other machine
that's experiencing the problem, applied it to the branch being used
(0.10.2) and verified that it works properly, i.e. it does fix the
problem it's supposed to fix. :-/
(cherry picked from commit 7c366506)

This patch fixes the lack of error messages when libvirt fails to find
VFINFO in a returned netlinke response message.

https://bugzilla.redhat.com/show_bug.cgi?id=827519#c10 is an example
of the error message that was previously logged when the
IFLA_VFINFO_LIST object was missing from the netlink response. The
reason for this failure is detailed in

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

Even though that root problem has been fixed, the experience of
finding the root cause shows us how important it is to properly log an
error message in these cases. This patch *seems* to replace the entire
function, but really most of the changes are due to moving code that
was previously inside an if() statement out to the top level of the
function (the original if() was reversed and made to log an error and
return).
(cherry picked from commit 846770e5)

Conflicts:
  src/util/virnetdev.c: virNetDevError was replaced with virReportError
                        post-0.9.11. Also memcpy of mac addr was replaced
                        with a call to virMacAddrSetRaw.

This patch resolves:

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

When assigning an SRIOV virtual function to a guest using "intelligent
PCI passthrough" (<interface type='hostdev'>, which sets the MAC
address and vlan tag of the VF before passing its info to qemu),
libvirt first learns the current MAC address and vlan tag by sending
an NLM_F_REQUEST message for the VF's PF (physical function) to the
kernel via a NETLINK_ROUTE socket (see virNetDevLinkDump()); the
response message's IFLA_VFINFO_LIST section is examined to extract the
info for the particular VF being assigned.

This worked fine with kernels up until kernel commit
115c9b81928360d769a76c632bae62d15206a94a (first appearing in upstream
kernel 3.3) which changed the ABI to not return IFLA_VFINFO_LIST in
the response until a newly introduced IFLA_EXT_MASK field was included
in the request, with the (newly introduced, of course) RTEXT_FILTER_VF
flag set.

The justification for this ABI change was that new fields had been
added to the VFINFO, causing NLM_F_REQUEST messages to fail on systems
with large numbers of VFs if the requesting application didn't have a
large enough buffer for all the info. The idea is that most
applications doing an NLM_F_REQUEST don't care about VFINFO anyway, so
eliminating it from the response would lower the requirements on
buffer size. Apparently, the people who pushed this patch made the
mistaken assumption that iproute2 (the "ip" command) was the only
package that used IFLA_VFINFO_LIST, so it wouldn't break anything else
(and they made sure that iproute2 was fixed.

The logic of this "fix" is debatable at best (one could claim that the
proper fix would be for the applications in question to be fixed so
that they properly sized the buffer, which is what libvirt does
(purely by virtue of using libnl), but it is what it is and we have to
deal with it.

In order for <interface type='hostdev'> to work properly on systems
with a kernel 3.3 or later, libvirt needs to add the afore-mentioned
IFLA_EXT_MASK field with RTEXT_FILTER_VF set.

Of course we also need to continue working on systems with older
kernels, so that one bit of code is compiled conditionally. The one
time this could cause problems is if the libvirt binary was built on a
system without IFLA_EXT_MASK which was subsequently updated to a
kernel that *did* have it. That could be solved by manually providing
the values of IFLA_EXT_MASK and RTEXT_FILTER_VF and adding it to the
message anyway, but I'm uncertain what that might actually do on a
system that didn't support the message, so for the time being we'll
just fail in that case (which will very likely never happen anyway).
(cherry picked from commit ac2797cf)

Conflicts:

 src/util/virnetdev.c: parameters of virNetlinkCommand were changed
                       post 0.9.11.

This patch resolves the problem reported in:

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

The source of the problem was the fix for CVE 2011-3411:

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

which was originally committed upstream in commit
753ff83a. That commit improperly
removed the "--except-interface lo" from dnsmasq commandlines when
--bind-dynamic was used (based on comments in the latter bug).

It turns out that the problem reported in the CVE could be eliminated
without removing "--except-interface lo", and removing it actually
caused each instance of dnsmasq to listen on localhost on port 53,
which created a new problem:

If another instance of dnsmasq using "bind-interfaces" (instead of
"bind-dynamic") had already been started (or if another instance
started later used "bind-dynamic"), this wouldn't have any immediately
visible ill effects, but if you tried to start another dnsmasq
instance using "bind-interfaces" *after* starting any libvirt
networks, the new dnsmasq would fail to start, because there was
already another process listening on port 53.

This patch changes the network driver to *always* add
"except-interface=lo" to dnsmasq conf files, regardless of whether we use
bind-dynamic or bind-interfaces. This way no libvirt dnsmasq instances
are listening on localhost (and the CVE is still fixed).

The actual code change is miniscule, but must be propogated through all
of the test files as well.

(This is *not* a cherry-pick of the upstream commit that fixes the bug
(commit d66eb786), because subsequent
to the CVE fix, another patch changed the network driver to put
dnsmasq options in a conf file rather than directly on the dnsmasq
commandline preserving the same options), so a cherry-pick is just one
very large conflict.)

(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.