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)

When analyzing our debug log, I'm always confused about what each of the
pointers mean. Let's be explicit.
(cherry picked from commit 71689f95)

The docs for virConnectSetKeepAlive() advertise that this function
should be able to disable keepalives on negative or zero interval time.

This patch removes the check that prohibited this and adds code to
disable keepalives on negative/zero interval.

* src/libvirt.c: virConnectSetKeepAlive(): - remove check for negative
                                             values
* src/rpc/virnetclient.c
* src/rpc/virnetclient.h: - add virNetClientKeepAliveStop() to disable
                            keepalive messages
* src/remote/remote_driver.c: remoteSetKeepAlive(): -add ability to
                                                     disable keepalives
(cherry picked from commit 6446a9e2)

Commit ba226d33 tried to fix crash of
the daemon when a domain with an open console was destroyed. The fix was
wrong as it tried to remove the callback also when the stream was
aborted, where at that point the fd stream driver was already freed and
removed.

This patch clears the callbacks with a helper right before the hash is
freed, so that it doesn't interfere with other codepaths where the
stream object is freed.
(cherry picked from commit 45edefc7)

(cherry picked from commit 7de158cf)

The stream object wasn't set to NULL after freeing causing a double free
attempt on the cleanup path.
(cherry picked from commit e3b8808b)

Pushed without ack, under the trivial rule.
(cherry picked from commit 2beed2da)

Detected by Coverity.

* src/qemu/qemu_hotplug.c (qemuDomainAttachHostDevice): Avoid
double free of usb on failure.
(cherry picked from commit 665c8cde)

When a domain has a active console connection and is destroyed the
callback is called on private data that no longer exist causing a
segfault.
(cherry picked from commit ba226d33)

If a domain is explicitly configured with <seclabel type="none"/> we
correctly ensure that no labeling will be done by setting
norelabel=true. However, if no seclabel element is present in domain XML
and hypervisor is configured not to confine domains by default, we only
set type to "none" without turning off relabeling. Thus if such a domain
is being started, security driver wants to relabel resources with
default label, which doesn't make any sense.

Moreover, with SELinux security driver, the generated image label lacks
"s0" sensitivity, which causes setfilecon() fail with EINVAL in
enforcing mode.
(cherry picked from commit ce53382b)

No check for conn->uri being NULL in virAuthGetConfigFilePath (valid
state) made the client segfault. This happens for example with these
settings:
 - no virtualbox driver installed (modifies conn->uri)
 - no default URI set (VIRSH_DEFAULT_CONNECT_URI="",
   LIBVIRT_DEFAULT_URI="", uri_default="")
 - auth_sock_rw="sasl"
 - virsh run as root

That are unfortunately the settings with fresh Fedora 17 installation
with VDSM.

The check ought to be enough as conn->uri being NULL is valid in later
code and is handled properly.
(cherry picked from commit 5eef7432)

some system call and signal will interrupt poll,
making event loop stops and fails to react events and keepalive message
from libvirt.
adding handling EINTR to poll to make it more robust
Signed-off-by: NRoyce Lv <lvroyce@linux.vnet.ibm.com>
(cherry picked from commit 5e62ba34)

The time keeping example was missing quotes which resulted in an error
if you copied and pasted the example into a domain's XML. Additionally
the rest of the examples use single quotes (') instead of double quotes
(") so standardized that.
(cherry picked from commit d57e17d5)

When the system doesn't have IPv6 available (e.g. not built into the
kernel or the module isn't loaded), you can not create an IPv6 socket.
The test determines earlier on that IPv6 isn't available then goes and
creates a socket. This makes socket creation conditional on IPv6
availability.
(cherry picked from commit faffe269)

As per the comment, the Xen hypervisor driver is considered to
be mandatory when running privileged. When it fails to open,
we should thus return an error, not ignore it.
(cherry picked from commit 489900e3)

When sending SIGHUP to libvirtd, it will trigger the virStateDriver
reload operation. This is intended to reload the configuration files
for guests. For unknown historical reasons this is also triggering
autostart of all guests. Autostart is generally expected to be
something that happens on OS startup. Starting VMs on SIGHUP will
violate that expectation and potentially cause dangerous scenarios
if the admin has explicitly shutdown a misbehaving VM that has
been marked as autostart
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 95c2c19f)