Eric Blake [Wed, 22 Jan 2014 18:57:37 +0000 (11:57 -0700)]
maint: this branch is now dead
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
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
Eric Blake [Wed, 12 Sep 2012 17:25:51 +0000 (11:25 -0600)]
build: avoid confusing make with raw name 'undefine'
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.
Zhou Yimin [Thu, 17 Oct 2013 07:59:21 +0000 (15:59 +0800)]
remote: fix regression in event deregistration
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: Zhou Yimin <zhouyimin@huawei.com> Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 9712c2510ec87a87578576a407768380e250a6a4)
Cole Robinson [Tue, 26 Mar 2013 21:53:54 +0000 (17:53 -0400)]
build: work around broken kernel header
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
Eric Blake [Mon, 1 Oct 2012 15:10:20 +0000 (09:10 -0600)]
build: avoid infinite autogen loop
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 c5f162200c32a078fd68507f26a15f84f7d65e9e)
Commit 9298bfbcb 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 f6c295156672fe15b32d2baddb68957bb7bddd8e)
Eric Blake [Fri, 7 Sep 2012 22:38:52 +0000 (16:38 -0600)]
build: force libnl1 if netcf also used libnl1
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.
Serge Hallyn [Thu, 3 May 2012 16:10:50 +0000 (11:10 -0500)]
build: support libnl-3
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: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 60fb8a22ee63481b6574a04304f740f50a133754)
Conflicts:
src/Makefile.am - dbus changes not backported
Eric Blake [Mon, 6 May 2013 14:18:39 +0000 (08:18 -0600)]
Skip libxl driver on Xen 4.2
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.
Michal Privoznik [Tue, 26 Mar 2013 14:45:16 +0000 (15:45 +0100)]
qemu: Set migration FD blocking
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 ceb31795af40f6127a541076b905935ff83e5b11)
Eric Blake [Mon, 14 Jan 2013 17:47:41 +0000 (10:47 -0700)]
build: further fixes for broken if_bridge.h
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 1bf661caf4e926efcad6e85151a587cea5fd29f4)
Cole Robinson [Tue, 26 Mar 2013 21:53:54 +0000 (17:53 -0400)]
build: work around broken kernel header
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 c308a9ae153db619fc0366bad9fd8f6c49cfac58)
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
Peter Krempa [Fri, 4 Jan 2013 15:15:04 +0000 (16:15 +0100)]
rpc: Fix crash on error paths of message dispatching
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 46532e3e8ed5f5a736a02f67d6c805492f9ca720)
commit ac2797cf2af2fd0e64c58a48409a8175d24d6f86 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 7c36650699f33e54361720f824efdf164bc6e65d)
Laine Stump [Thu, 20 Dec 2012 19:52:41 +0000 (14:52 -0500)]
util: add missing error log messages when failing to get netlink VFINFO
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
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 846770e5ff959f7819e2c32857598cb88e2e2f0e)
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.
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 ac2797cf2af2fd0e64c58a48409a8175d24d6f86)
Conflicts:
src/util/virnetdev.c: parameters of virNetlinkCommand were changed
post 0.9.11.
which was originally committed upstream in commit 753ff83a50263d6975f88d6605d4b5ddfcc97560. 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 d66eb7866757dd371560c288dc6201fb9348792a), 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.)
qemu: pass -usb and usb hubs earlier, so USB disks with static address are handled properly
(cherry picked from commit 81af5336acf4c765ef1201e7762d003ae0b0011e)
Stefan Hajnoczi [Thu, 1 Nov 2012 17:20:55 +0000 (18:20 +0100)]
qemu: Keep QEMU host drive prefix in BlkIoTune
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.
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 ff33f807739dc2950e4df8c1d4007ce9f8b290c0)
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 5114431396fd125b6ebe4d1a20a981111f948ee7)
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).
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.
(cherry picked from commit 753ff83a50263d6975f88d6605d4b5ddfcc97560)
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.
Laine Stump [Thu, 22 Nov 2012 02:17:30 +0000 (21:17 -0500)]
util: new virSocketAddrIsPrivate function
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.
(cherry picked from commit bf402e77b6d53a4e569b3aa76aef9c7d589c0cf2)
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.
Laine Stump [Tue, 20 Nov 2012 17:22:15 +0000 (12:22 -0500)]
util: capabilities detection for dnsmasq
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.
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
Eric Blake [Mon, 5 Nov 2012 16:48:28 +0000 (09:48 -0700)]
spec: don't enable cgconfig under systemd
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
Cole Robinson [Sat, 20 Oct 2012 19:57:28 +0000 (15:57 -0400)]
selinux: Don't fail RestoreAll if file doesn't have a default label
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.
Jiri Denemark [Wed, 17 Oct 2012 12:08:17 +0000 (14:08 +0200)]
qemu: Clear async job when p2p migration fails early
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.
remove dnsmasq command line parameter "--filterwin2k"
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 [Wed, 22 Aug 2012 16:59:24 +0000 (12:59 -0400)]
dnsmasq: avoid forwarding queries without a domain
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.
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 b7ff9e696063189a715802d081d55a398663c15a)
Eric Blake [Fri, 20 Jul 2012 20:44:54 +0000 (14:44 -0600)]
tests: avoid seclabeltest crash
Commit a56c347 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.
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 5d490603a6d60298162cbd32ec45f736b58929fb)
Jiri Denemark [Tue, 12 Jun 2012 12:32:27 +0000 (14:32 +0200)]
client rpc: Send keepalive requests from IO event loop
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 4d971dc7ef1a9d0dc830c243b5731e862ad0eb5c)
Jiri Denemark [Tue, 12 Jun 2012 07:02:38 +0000 (09:02 +0200)]
server rpc: Remove APIs for manipulating filters on locked client
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 d9ad41669828e33623ba8177f260b9f313c1963d)
Jiri Denemark [Tue, 12 Jun 2012 07:01:49 +0000 (09:01 +0200)]
rpc: Do not use timer for sending keepalive responses
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 bb85f2298e63b55b0465cb9e1f790019e99611dd)
Jiri Denemark [Tue, 12 Jun 2012 21:42:32 +0000 (23:42 +0200)]
rpc: Add APIs for direct triggering of keepalive timer
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 28c75382b00d75b129245dedc1ce92596b96ddf9)
Jiri Denemark [Tue, 12 Jun 2012 21:41:25 +0000 (23:41 +0200)]
rpc: Refactor keepalive timer code
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 a2ba8686325c8ba61c95f3f1152ef4420a029c15)
Jiri Denemark [Fri, 8 Jun 2012 13:24:06 +0000 (15:24 +0200)]
client rpc: Drop unused return value of virNetClientSendNonBlock
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 ca9b13e3733195d400effaca0ef13e4545a3b608)
Jiri Denemark [Mon, 11 Jun 2012 12:24:06 +0000 (14:24 +0200)]
client rpc: Just queue non-blocking call if another thread has the buck
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 ef392614aa585d168e618ffaf2c83545d81f0113)
Jiri Denemark [Fri, 8 Jun 2012 12:21:00 +0000 (14:21 +0200)]
client rpc: Don't drop non-blocking calls
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 b1e374a7ac56927cfe62435179bf0bba1e08b372 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 78602c4e83bbf51f89c24a0be14074e71d01bf60)
Jiri Denemark [Tue, 12 Jun 2012 06:41:59 +0000 (08:41 +0200)]
client rpc: Use event loop for writing
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 9e747e5c5079a5aead2f248fc22ff658bd0180be)
Jiri Denemark [Fri, 8 Jun 2012 11:41:25 +0000 (13:41 +0200)]
client rpc: Improve debug messages in virNetClientIO
When analyzing our debug log, I'm always confused about what each of the
pointers mean. Let's be explicit.
(cherry picked from commit 71689f95ceedbc63953a0b06aa2c2cee7fabfa2b)
Peter Krempa [Fri, 3 Aug 2012 09:20:29 +0000 (11:20 +0200)]
conf: Remove console stream callback only when freeing console helper
Commit ba226d334acbc49f6751b430e0c4e00f69eef6bf 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 45edefc7a7bcbec988f54331ff37fc32e4bc2718)
Peter Krempa [Fri, 3 Aug 2012 11:16:24 +0000 (13:16 +0200)]
virsh: console: Avoid using stream after being freed.
The stream object wasn't set to NULL after freeing causing a double free
attempt on the cleanup path.
(cherry picked from commit e3b8808ba764e06f68785a2bbdd8b7ab00b71fa4)
Eric Blake [Tue, 31 Jul 2012 14:05:14 +0000 (08:05 -0600)]
qemu: fix use after free
Detected by Coverity.
* src/qemu/qemu_hotplug.c (qemuDomainAttachHostDevice): Avoid
double free of usb on failure.
(cherry picked from commit 665c8cdecc2d91a83f08a6ec95531b0de57c0e0a)
Peter Krempa [Fri, 27 Jul 2012 12:50:54 +0000 (14:50 +0200)]
conf: Remove callback from stream when freeing entries in console hash
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 ba226d334acbc49f6751b430e0c4e00f69eef6bf)
security: Skip labeling resources when seclabel defaults to none
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 ce53382ba28179d3a504b29b4f888b6e130d53f0)
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 5eef74320b0bb9e604400168e0896c5ac527abef)
adding handling EINTR to poll to make it more robust
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
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 d57e17d58300589e4b53c52360d9fcd7592f53b2)
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 faffe26909d8e5cde7e80e5a8f33296ed56dcfc7)
Ensure failure to talk to Xen hypervisor is fatal when privileged
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 489900e3de9de74ce4197807935ffc3ef8a68bca)
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
Remote driver needs to make sure the driver lock is released before
entering client IO loop as that may block indefinitely in poll(). As a
direct consequence of not following this in stream APIs, tunneled
migration to a destination host which becomes non-responding may block
qemu driver. Luckily, if keepalive is turned for p2p migrations, both
remote and qemu drivers will get automagically unblocked after keepalive
timeout.
(cherry picked from commit 17f3be079c3c421eff203fcd311b0357ec42d801)
qemu: Do not fail virConnectCompareCPU if host CPU is not known
When host CPU could not be properly detected, virConnectCompareCPU will
just report that any CPU is incompatible with host CPU instead of
failing.
(cherry picked from commit 87c8623161f19c4f37844991deb1477e53c2b310)
When --direct is used when migrating a domain running on a hypervisor
that does not support direct migration (such as QEMU), the caller would
get the following error message:
this function is not supported by the connection driver:
virDomainMigrateToURI2
which is a complete nonsense since qemu driver implements
virDomainMigrateToURI2. This patch would emit a more sensible error in
this case:
Requested operation is not valid: direct migration is not supported
by the connection driver
(cherry picked from commit 3189dfb1636da22d426d2fc07cc9f60304b16c5c)
Commit 32a9aac switched libvirt to use the XDG base directories
to locate most of its data/config. In particular, the per-user socket
for qemu:///session is now stored in the XDG runtime directory.
This directory is located by looking at the XDG_RUNTIME_DIR environment
variable, with a fallback to ~/.cache/libvirt if this variable is not
set.
When the daemon is autospawned because a client application wants
to use qemu:///session, the daemon is ran in a clean environment
which does not contain XDG_RUNTIME_DIR. It will create its socket
in ~/.cache/libvirt. If the client application has XDG_RUNTIME_DIR
set, it will not look for the socket in the fallback place, and will
fail to connect to the autospawned daemon.
This patch adds XDG_RUNTIME_DIR to the daemon environment before
auto-starting it. I've done this in virNetSocketForkDaemon rather
than in virCommandAddEnvPassCommon as I wasn't sure we want to pass
these variables to other commands libvirt spawns. XDG_CACHE_HOME
and XDG_CONFIG_HOME are also added to the daemon env as it makes use
of those as well.
(cherry picked from commit efe6c8021146d046846ead5b5efc9828d97c1ceb)
This makes the driver fail with a clear error message in case of UUID
collisions (for example if somebody copied a container configuration
without updating the UUID) and also raises an error on other hash map
failures.
OpenVZ itself doesn't complain about duplicate UUIDs since this
parameter is only used by libvirt.
(cherry picked from commit 31351c316fee0487dcbc5ef6b630d75be6b212e5)
Fix /domain/features setting in qemuParseCommandLine
Commit 5e6ce1 moved down detection of the ACPI feature in
qemuParseCommandLine. However, when ACPI is detected, it clears
all feature flags in def->features to only set ACPI. This used to
be fine because this was the first place were def->features was set,
but after the move this is no longer necessarily true because this
block comes before the ACPI check:
Since def is allocated in qemuParseCommandLine using VIR_ALLOC, we
can always use |= when modifying def->features
(cherry picked from commit 626dd5180e472c0b4c0c5fb7072358743ca63653)
Jim Fehlig [Mon, 9 Jul 2012 15:52:55 +0000 (09:52 -0600)]
systemd: start libvirtd after network
Domains configured with autostart may fail to start if the host
network stack has not been started. E.g. when using bridged
networking autostarting a domain can fail with
libvirtd[1403]: 2012-06-20 13:23:49.833+0000: 1485: error :
qemuAutostartDomain:177 : Failed to autostart VM 'test': Cannot get
interface MTU on 'br0': No such device
(cherry picked from commit 4036aa91bff6482cf4c136c93277619fa8ec6f94)
Peter Krempa [Thu, 21 Jun 2012 15:59:27 +0000 (17:59 +0200)]
virsh: Clarify documentation for virsh dompmsuspend command
Clarify the docs to make more clear what this command does and that it
requires a guest agent running in the guest.
(cherry picked from commit e16d434da75430b05545f4d85d156f36b1ce51d1)
Peter Krempa [Mon, 9 Jul 2012 12:10:05 +0000 (14:10 +0200)]
storage_backend_fs: Don't free a part of a structure on error
As the storage pool sources are stored in a list of structs, the pointer
returned by virStoragePoolSourceListNewSource() shouldn't be freed as it
points in the middle of a memory block. This combined with a regression
that takes the error path every time on caused a double-free abort on
the src struct in question.
(cherry picked from commit ab9c72ae9e55e7190f52ad1550624630a5c7f78b)
projects / thirdparty / libvirt.git / log
