Quote client identity in SASL whitelist log message
When seeing a message
virNetSASLContextCheckIdentity:146 : SASL client admin not allowed in whitelist
it isn't immediately obvious that 'admin' is the identity
being checked. Quote the string to make it more obvious
(cherry picked from commit 07da0a6b54057f48238e35f1756d137c10e0bef5)
Ján Tomko [Fri, 30 Nov 2012 14:07:50 +0000 (15:07 +0100)]
nwfilter: report an error on OOM
Also removed some unreachable code found by coverity:
libvirt-0.10.2/src/nwfilter/nwfilter_driver.c:259: unreachable: This
code cannot be reached: "nwfilterDriverUnlock(driver...".
(cherry picked from commit 4f9af0857c1547d19610e5c59efe45a8d847b67f)
Ján Tomko [Fri, 30 Nov 2012 12:09:21 +0000 (13:09 +0100)]
virsh: check the return value of virStoragePoolGetAutostart
On error, virStoragePoolGetAutostart would return -1 leaving autostart
untouched.
Removed the misleading debug message as well.
Error: CHECKED_RETURN (CWE-252):
libvirt-0.10.2/tools/virsh-pool.c:1386: unchecked_value: No check of the
return value of "virStoragePoolGetAutostart(pool, &autostart)".
(cherry picked from commit e9d74a7a8238f082cf0f0285ce4d2547a72eaa01)
Ján Tomko [Thu, 29 Nov 2012 10:23:06 +0000 (11:23 +0100)]
virsh: use correct sizeof when allocating cpumap
Found by coverity:
Error: SIZEOF_MISMATCH (CWE-569):
libvirt-0.10.2/tools/virsh-domain.c:4754: suspicious_sizeof: Passing
argument "8UL /* sizeof (cpumap) */" to function
"_vshCalloc(vshControl *, size_t, size_t, char const *, int)" and
then casting the return value to "unsigned char *" is suspicious.
Error: SIZEOF_MISMATCH (CWE-569):
libvirt-0.10.2/tools/virsh-domain.c:4942: suspicious_sizeof: Passing
argument "8UL /* sizeof (cpumap) */" to function
"_vshCalloc(vshControl *, size_t, size_t, char const *, int)" and
then casting the return value to "unsigned char *" is suspicious.
(cherry picked from commit dc04b2a737c8c4240d0d412080ce798b977068a1)
Ján Tomko [Thu, 29 Nov 2012 09:56:56 +0000 (10:56 +0100)]
util: fix virBitmap allocation in virProcessInfoGetAffinity
Found by coverity:
Error: REVERSE_INULL (CWE-476):
libvirt-0.10.2/src/util/processinfo.c:141: deref_ptr: Directly
dereferencing pointer "map".
libvirt-0.10.2/src/util/processinfo.c:142: check_after_deref:
Null-checking "map" suggests that it may be null, but it has already
been dereferenced on all paths leading to the check.
(cherry picked from commit 7730257db30972a6f4db8d582b232b240b2a06b8)
Laine Stump [Wed, 28 Nov 2012 04:59:17 +0000 (23:59 -0500)]
network: fix crash when portgroup has no name
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=879473
The name attribute is required for portgroup elements (yes, the RNG
specifies that), and there is code in libvirt that assumes it is
non-null. Unfortunately, the portgroup parsing function wasn't
checking for lack of portgroup. One adverse result of this was that
attempts to update a network by adding a portgroup with no name would
cause libvirtd to segfault. For example:
This patch causes virNetworkPortGroupParseXML to fail if no name is
specified, thus avoiding any later problems.
(cherry picked from commit 012d69dff1e031f8079a9952e886a31795e589b2)
Ensure transient def is removed if LXC start fails
When starting a container, newDef is initialized to a
copy of 'def', but when startup fails newDef is never
removed. This cause later attempts to use 'virDomainDefine'
to lose the new data being defined.
Ensure failure to create macvtap device aborts LXC start
A mistaken initialization of 'ret' caused failure to create
macvtap devices to be ignored. The libvirt_lxc process
would later fail to start due to missing devices
Also make sure code checks '< 0' and not '!= 0' since only
-1 is considered an error condition
Treat missing driver cgroup as fatal in LXC driver
The LXC driver relies on use of cgroups to kill off LXC processes
in shutdown. If cgroups aren't available, we're unable to kill
off processes, so we must treat lack of cgroups as a fatal startup
error.
The code setting up LXC cgroups used an 'rc' variable both
for capturing the return value of methods it calls, and
its own return status. The result was that several failures
in setting up cgroups would actually result in success being
returned.
Use a separate 'ret' for tracking return value as per normal
code design in other parts of libvirt
Peter Krempa [Mon, 26 Nov 2012 11:13:56 +0000 (12:13 +0100)]
lxc: Avoid segfault of libvirt_lxc helper on early cleanup paths
Early jumps to the cleanup label caused a crash of the libvirt_lxc
container helper as the cleanup section called
virLXCControllerDeleteInterfaces(ctrl) without checking the ctrl argument
for NULL. The argument was de-referenced soon after.
$ /usr/libexec/libvirt_lxc
/usr/libexec/libvirt_lxc: missing --name argument for configuration
Segmentation fault
(cherry picked from commit 81efb13b4a33f58c28e0e65dcc9521b983592683)
Ján Tomko [Sun, 25 Nov 2012 01:59:33 +0000 (02:59 +0100)]
storage: fix logical volume cloning
Commit 258e06c removed setting of the volume type to
VIR_STORAGE_VOL_BLOCK, which leads to failures in
storageVolumeCreateXMLFrom.
The type (and target.format) of the volume was set to zero. In
virStorageBackendGetBuildVolFromFunction, this gets interpreted as
VIR_STORAGE_FILE_NONE and the qemu-img tool is called with unknown
"none" format.
Warn if requesting update to non-existent timer/handle watch
The event code is a no-op if requested to update a non-existent
timer/handle watch. This makes it hard to detect bugs in the
caller who have passed bogus data. Add a VIR_WARN output in
such cases, since the API does not allow for return errors.
Fix virDiskNameToIndex to actually ignore partition numbers
The docs for virDiskNameToIndex claim it ignores partition
numbers. In actual fact though, a code ordering bug means
that a partition number will cause the code to accidentally
multiply the result by 26.
Notice unsupported disk type (for the driver), but also no address
specified. The first part is not a problem and we should not abort
immediately because of that, but the combination with the address
unknown was causing an unspecified error.
While fixing this, I added an error to one place where this return
value was not managed properly.
(cherry picked from commit 03cd6e4ae8d86682986249f05f7de8eb405a12da)
The LXC controller code currently directly invokes the
libvirt main loop code. The problem is that this misses
the cleanup of virNetServerClient connections that
virNetServerRun takes care of.
The result is that when libvirtd is stopped, the
libvirt_lxc controller process gets stuck in a I/O loop.
When libvirtd is then started again, it fails to connect
to the controller and thus kills off the entire domain.
Osier Yang [Wed, 21 Nov 2012 03:22:39 +0000 (11:22 +0800)]
storage: Fix bug of fs pool destroying
Regression introduced by commit 258e06c85b7, "ret" could be set to 1
or 0 by virStorageBackendFileSystemIsMounted before goto cleanup.
This could mislead the callers (up to the public API
virStoragePoolDestroy) to return success even the underlying umount
command fails.
(cherry picked from commit f4ac06569a8ffce24fb8c07a0fc01574e38de6e4)
Ján Tomko [Tue, 20 Nov 2012 18:47:07 +0000 (19:47 +0100)]
conf: add support for booting from redirected USB devices
Commit a4c19459aa8634c43b51e8138fb1d7eec4c17824 only added the
QEMU capability flag, command line option and added the boot element
for redirdev's in the XML schema.
This patch adds support for parsing and writing the XML with redirdevs
with the boot flag. It also ignores unknown XML elements in redirdev
instead of failing with:
"error: An error occurred, but the cause is unknown"
The reported problem is that an attempt to restore a saved domain that
was configured with <currentMemory> and <memory> set to some (same for
both) number that's not a multiple of 4096KiB results in an error like
this:
error: Failed to start domain libvirt_test_api
error: XML error: current memory '4001792k' exceeds maximum '4000768k'
(in this case, currentMemory was set to 4000000KiB).
The reason for this failure is:
1) a saved image contains the "live xml" of the domain at the time of
the save.
2) the live xml of a running domain gets its currentMemory
(a.k.a. cur_balloon) directly from the qemu monitor rather than from
the configuration of the domain.
3) the value reported by qemu is (sometimes) not exactly what was
originally given to qemu when the domain was started, but is rounded
up to [some indeterminate granularity] - in some versions of qemu that
granularity is apparently 1MiB, and in others it is 4MiB.
4) When the XML is parsed to setup the state of the restored domain,
the XML parser for <currentMemory> compares it to <memory> (which is
the maximum allowed memory size for the domain) and if <currentMemory>
is greater than the next 1024KiB boundary above <memory>, it spits out
an error and fails.
For example (from the BZ) if you start qemu on RHEL6 with both
<currentMemory> and <memory> of 4000000 (this number is in KiB),
libvirt's dominfo or dumpxml will report "4001792" back (rounded up to
next 4MiB) for 10-20 seconds after the start, then revert to reporting
"4000000". On Fedora 16 (which uses qemu-1.0), it will instead report
"4000768" (rounded up to next 1MiB). On Fedora 17 (qemu-1.2), it seems
to always report "4000000". ("4000000" is of course okay, and
"4000768" is also okay since that's the next 1024KiB boundary above
"4000000" and the parser was already allowing for that. But "4001792
is *not* okay and produces the error message.)
This patch solves the problem by changing the allowed "fudge factor"
when parsing from 1024KiB to 4096KiB to match the maximum up-rounding
that could be done in qemu.
(I had earlier thought to fix this by up-rounding <memory> in the
dumpxml that's put into the saved image, but that wouldn't have fixed
the case where the save image was produced by an "unfixed"
libvirtd.)
(cherry picked from commit 89204fca7f193c7cf48f941bf2917c1a0e71096c)
Eric Blake [Thu, 1 Nov 2012 22:20:09 +0000 (16:20 -0600)]
nodeinfo: support kernels that lack socket information
On RHEL 5, I was getting a segfault trying to start libvirtd,
because we were failing virNodeParseSocket but not checking
for errors, and then calling CPU_SET(-1, &sock_map) as a result.
But if you don't have a topology/physical_package_id file,
then you can just assume that the cpu belongs to socket 0.
* src/nodeinfo.c (virNodeGetCpuValue): Change bool into
default_value.
(virNodeParseSocket): Allow for default value when file is missing,
different from fatal error on reading file.
(virNodeParseNode): Update call sites to fail on error.
(cherry picked from commit 47976b484cfae6ff0dd9e6fcbd45d377aaeaa8f4)
Eric Blake [Wed, 14 Nov 2012 20:20:55 +0000 (13:20 -0700)]
build: rerun bootstrap if AUTHORS is missing
Ever since commit 7b21981c started generating AUTHORS, we now have
the situation that if you flip between two branches in the same
git repository that cross that commit boundary, then 'make' will
fail due to automake complaining about AUTHORS not existing. The
simplest solution is to realize that if AUTHORS does not exist,
then we flipped branches so we will need to rerun bootstrap
anyways; and rerunning bootstrap ensures AUTHORS will exist in time.
Fix uninitialized variable in virLXCControllerSetupDevPTS
The lack of initialization of 'opts' caused a SEGV in the
cleanup: path if the root->src directory did not exist
(cherry picked from commit 3782814d4ad787d815e56382b6f809fe9020f14b)
After the connection to ESX 5.1 being broken since g1e7cd39, the fix
in bab7752c helped a bit, but still missed a spot, so the connection
is now successful, but some APIs (for example defineXML) don't work.
Two cases missing are added in this patch to avoid that.
(cherry picked from commit 9c294e6f9a2ae23f4fbfc98d0dc2aec1ce9eba0b)
qemu is sensitive to the order of arguments passed. Hence, if a
device requires a controller, the controller cmd string must
precede device cmd string. The same apply for controllers, when
for instance ccid controller requires usb controller. So
controllers create partial ordering in which they should be added
to qemu cmd line.
(cherry picked from commit 0f720ab35a1a836aa23b66ef4bafbc5e57290357)
Václav Pavlín [Thu, 25 Oct 2012 10:10:55 +0000 (12:10 +0200)]
spec: replace scriptlets with new systemd macros
https://bugzilla.redhat.com/850186
I added %with_systemd_macros so it should now work in F17 with old
scriptlets and in F18+/RHEL7+ with systemd macros
(see https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd)
I missed libvirt-guests.service because there is no systemctl call for
it. So I only added systemd macros calls.
(cherry picked from commit ec02d49dfd98313d1c8c4179e88754f10a82ca46)
Some FDs may not implement fdatasync() functionality,
e.g. pipes. In that case EINVAL or EROFS is returned.
We don't want to fail then nor report any error.
Peter Krempa [Thu, 1 Nov 2012 14:45:47 +0000 (15:45 +0100)]
qemu: Fix possible race when pausing guest
When pausing the guest while migration is running (to speed up
convergence) the virDomainSuspend API checks if the migration job is
active before entering the job. This could cause a possible race if the
virDomainSuspend is called while the job is active but ends before the
Suspend API enters the job (this would require that the migration is
aborted). This would cause a incorrect event to be emitted.
(cherry picked from commit d0fc6dc8315b3172501e6fe09c8aed12598de47e)
Peter Krempa [Thu, 25 Oct 2012 14:13:57 +0000 (16:13 +0200)]
net: Remove dnsmasq and radvd files also when destroying transient nets
The network driver didn't care about config files when a network was
destroyed, just when it was undefined leaving behind files for transient
networks.
This patch splits out the cleanup code to a helper function that handles
the cleanup if the inactive network object is being removed and re-uses
this code when getting rid of inactive networks.
(cherry picked from commit e87af617fc3e5a69fb19319d43f58262e5e624ea)
Peter Krempa [Thu, 25 Oct 2012 12:41:28 +0000 (14:41 +0200)]
net: Move creation of dnsmasq hosts file to function starting dnsmasq
The hosts file was created in the network definition function. This
patch moves the place the file is being created to the point where
dnsmasq is being started.
(cherry picked from commit 23ae3fe4256ba634babc6818b8cb7bbd3664a95a)
Peter Krempa [Fri, 26 Oct 2012 12:33:13 +0000 (14:33 +0200)]
conf: net: Fix deadlock if assignment of network def fails
When the assignment fails, the network object is not unlocked and next
call that would use it deadlocks.
(cherry picked from commit f8230891243f86e920d04a0751512cc31055ff8c)
Dan Walsh [Thu, 1 Nov 2012 18:54:39 +0000 (14:54 -0400)]
Linux Containers are not allowed to create device nodes.
This needs to be done before the container starts. Turning
off the mknod capability is noticed by systemd, which will
no longer attempt to create device nodes.
Michal Privoznik [Tue, 30 Oct 2012 18:15:48 +0000 (19:15 +0100)]
iohelper: fdatasync() at the end
Currently, when we are doing (managed) save, we insert the
iohelper between the qemu and OS. The pipe is created, the
writing end is passed to qemu and the reading end to the
iohelper. It reads data and write them into given file. However,
with write() being asynchronous data may still be in OS
caches and hence in some (corner) cases, all migration data
may have been read and written (not physically though). So
qemu will report success, as well as iohelper. However, with
some non local filesystems, where ENOSPACE is polled every X
time units, we may get into situation where all operations
succeeded but data hasn't reached the disk. And in fact will
never do. Therefore we ought sync caches to make sure data
has reached the block device on remote host.
(cherry picked from commit f32e3a2dd686f3692cd2bd3147c03e90f82df987)
Recent fixes made almost all the right steps to make emulator pinned
to the cpuset of the whole domain in case <emulatorpin> isn't
specified, but qemudDomainGetEmulatorPinInfo still reports all the
CPUs even when cpuset is specified. This patch fixes that.
(cherry picked from commit 10c5212b108e8395a6cab2dd449f2b1c0f1442d0)
Gene Czarcinski [Tue, 30 Oct 2012 21:18:34 +0000 (17:18 -0400)]
bugfix: ip6tables rule removal
Three FORWARD chain rules are added and two INPUT chain rules
are added when a network is started but only the FORWARD chain
rules are removed when the network is destroyed.
(cherry picked from commit adaa7ab653b0f841aa549e9f47f9e63ee1d15b37)
Laine Stump [Mon, 29 Oct 2012 22:05:41 +0000 (18:05 -0400)]
util: do a better job of matching up pids with their binaries
This patch resolves: https://bugzilla.redhat.com/show_bug.cgi?id=871201
If libvirt is restarted after updating the dnsmasq or radvd packages,
a subsequent "virsh net-destroy" will fail to kill the dnsmasq/radvd
process.
The problem is that when libvirtd restarts, it re-reads the dnsmasq
and radvd pidfiles, then does a sanity check on each pid it finds,
including checking that the symbolic link in /proc/$pid/exe actually
points to the same file as the path used by libvirt to execute the
binary in the first place. If this fails, libvirt assumes that the
process is no longer alive.
But if the original binary has been replaced, the link in /proc is set
to "$binarypath (deleted)" (it literally has the string " (deleted)"
appended to the link text stored in the filesystem), so even if a new
binary exists in the same location, attempts to resolve the link will
fail.
In the end, not only is the old dnsmasq/radvd not terminated when the
network is stopped, but a new dnsmasq can't be started when the
network is later restarted (because the original process is still
listening on the ports that the new process wants).
The solution is, when the initial "use stat to check for identical
inodes" check for identity between /proc/$pid/exe and $binpath fails,
to check /proc/$pid/exe for a link ending with " (deleted)" and if so,
truncate that part of the link and compare what's left with the
original binarypath.
A twist to this problem is that on systems with "merged" /sbin and
/usr/sbin (i.e. /sbin is really just a symlink to /usr/sbin; Fedora
17+ is an example of this), libvirt may have started the process using
one path, but /proc/$pid/exe lists a different path (indeed, on F17
this is the case - libvirtd uses /sbin/dnsmasq, but /proc/$pid/exe
shows "/usr/sbin/dnsmasq"). The further bit of code to resolve this is
to call virFileResolveAllLinks() on both the original binarypath and
on the truncated link we read from /proc/$pid/exe, and compare the
results.
The resulting code still succeeds in all the same cases it did before,
but also succeeds if the binary was deleted or replaced after it was
started.
(cherry picked from commit 7bafe009d93f8b26330d52dc3289643699cf74f0)
qemu: pass -usb and usb hubs earlier, so USB disks with static address are handled properly
(cherry picked from commit 81af5336acf4c765ef1201e7762d003ae0b0011e)
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).
(cherry picked from commit 3738cf41f1012eca419e8fa0fa0575cb1e0552e3)
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.
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.
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.
Jiri Denemark [Tue, 16 Oct 2012 19:11:29 +0000 (21:11 +0200)]
qemu: Always format CPU topology
When libvirt cannot find a suitable CPU model for host CPU (easily
reproducible by running libvirt in a guest), it would not provide CPU
topology in capabilities XML either. Even though CPU topology is known
and can be queried by virNodeGetInfo. With this patch, CPU topology will
always be provided in capabilities XML regardless on the presence of CPU
model.
(cherry picked from commit f1c70100409562c3f402392aa667732e5f89a2c4)
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
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.
Laine Stump [Fri, 26 Oct 2012 17:23:56 +0000 (13:23 -0400)]
parallels: fix build for some older compilers
Found this when building on RHEL5:
parallels/parallels_storage.c: In function 'parallelsStorageOpen':
parallels/parallels_storage.c:180: error: 'for' loop initial declaration used outside C99 mode
(and similar error in parallels_driver.c). This was in spite of
configuring with "-Wno-error".
(cherry picked from commit 73ebd86d7318960b22c3b0f1262cbbd770265c9c)
networkValidate was supposed to check for the existence of multiple
portgroups and report an error if this was encountered. It did, but
there were two problems:
1) even though it logged an error, it still returned success, allowing
the operation to continue.
2) It could exit the portgroup checking loop early (or possibly not
even do it once) if a vlan tag was supplied in the base network config
or one of the portgroups.
This patch fixes networkValidate to return failure in addition to
logging the error, and also changes it to not exit the portgroup
checking loop early. The logic was a bit off in the checking for vlan
anyway, and it's intertwined with fixing the early loop exit, so I
fixed that as well. Now it correctly checks for combinations where a
<virtualport> is specified in the base network def and <vlan> is given
in a portgroup, as well as the opposite (<vlan> in base network def
and <virtualport> in portgroup), and ignores the case of a disallowed
vlan when using *no* portgroup if there is a default portgroup (since
in that case there is no way to not use any portgroup).
(cherry picked from commit d8aae15aa1ab173fd3c57f5806b6febae6b640af)
Matthias Bolte [Wed, 24 Oct 2012 17:50:15 +0000 (19:50 +0200)]
esx: Update version checks for vSphere 5.1
Also remove warnings for upcoming versions. There hadn't been any
compatibility problems with new ESX version over the whole lifetime
of the ESX driver, so I don't expect any in the future.
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.
Ján Tomko [Tue, 23 Oct 2012 11:33:21 +0000 (13:33 +0200)]
storage: don't shadow global 'wait' declaration
Rename the 'wait' parameter to 'loop'.
This silences the warning:
storage/storage_backend.c:1348:34: error: declaration of 'wait' shadows
a global declaration [-Werror=shadow]
and fixes the build with -Werror.
--
Note: loop is pool backwards.
(cherry picked from commit b326765c801ef5c291cbd9ab2c51b20128047b56)
Cole Robinson [Sun, 21 Oct 2012 16:53:20 +0000 (12:53 -0400)]
storage: Don't do wait loops from VolLookupByPath
virStorageVolLookupByPath is an API call that virt-manager uses
quite a bit when dealing with storage. This call use BackendStablePath
which has several usleep() heuristics that can be tripped up
and hang virt-manager for a while.
Current example: an empty mpath pool pointing to /dev/mapper makes
_any_ calls to virStorageVolLookupByPath take 5 seconds.
The sleep heuristics are actually only needed in certain cases
when we are waiting for new storage to appear, so let's skip the
timeout steps when calling from LookupByPath.
(cherry picked from commit 77eff5eeb2d2aada3c670d325d04a35b54428988)
Osier Yang [Mon, 24 Sep 2012 08:44:20 +0000 (16:44 +0800)]
storage: Add timeout for iscsi volume's stable path discovery
It might need some time till the LUN's stable path shows up on
initiator host, and although the time window is not foreseeable,
as a better than nothing fix, this patch adds timeout for the
stable path discovery process.
(cherry picked from commit de7f0774c34547776723378bf844ec5d0866bba3)
Laine Stump [Sat, 20 Oct 2012 08:39:18 +0000 (04:39 -0400)]
network: don't allow multiple default portgroups
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=868483
virNetworkUpdate, virNetworkDefine, and virNetworkCreate all three
allow network definitions to contain multiple <portgroup> elements
with default='yes'. Only a single default portgroup should be allowed
for each network.
This patch updates networkValidate() (called by both
virNetworkCreate() and virNetworkDefine()) and
virNetworkDefUpdatePortGroup (called by virNetworkUpdate() to not
allow multiple default portgroups.
(cherry picked from commit 6f8a8b30c9a0123d8c6f49c946084b94c580811b)
Previously, the dnsmasq hosts file (used for static dhcp entries, and
addnhosts file (used for additional dns host entries) were only
created/referenced on the dnsmasq commandline if there was something
to put in them at the time the network was started. Once we can update
a network definition while it's active (which is now possible with
virNetworkUpdate), this is no longer a valid strategy - if there were
0 dhcp static hosts (resulting in no reference to the hosts file on the
commandline), then one was later added, the commandline wouldn't have
linked dnsmasq up to the file, so even though we create it, dnsmasq
doesn't pay any attention.
The solution is to just always create these files and reference them
on the dnsmasq commandline (almost always, anyway). That way dnsmasq
can notice when a new entry is added at runtime (a SIGHUP is sent to
dnsmasq by virNetworkUdpate whenever a host entry is added or removed)
The exception to this is that the dhcp static hosts file isn't created
if there are no lease ranges *and* no static hosts. This is because in
this case dnsmasq won't be setup to listen for dhcp requests anyway -
in that case, if the count of dhcp hosts goes from 0 to 1, dnsmasq
will need to be restarted anyway (to get it listening on the dhcp
port). Likewise, if the dhcp hosts count goes from 1 to 0 (and there
are no dhcp ranges) we need to restart dnsmasq so that it will stop
listening on port 67. These special situations are handled in the
bridge driver's networkUpdate() by checking for ((bool)
nranges||nhosts) both before and after the update, and triggering a
dnsmasq restart if the before and after don't match.
(cherry picked from commit 1cb1f9dabf8e9c9fc8dfadbb3097776ca5f2c68c)
pointed out a crash due to virNetworkObjAssignDef free'ing
network->newDef without NULLing it afterward. A fix for this is in
upstream commit b7e9202401ebaa039b8f05acdefda8c24081537a. While the
NULLing of newDef was a legitimate fix, newDef should have already
been empty (NULL) anyway (as indicated in the comment that was deleted
by that commit).
The reason that newDef had a non-NULL value (i.e. the root cause) was
that networkStartNetwork() had failed after populating
network->newDef, but then neglected to free/NULL newDef in the
cleanup.
(A bit of background here: network->newDef should contain the
persistent config of a network when a network is active (and of course
only when it is persisten), and NULL at all other times. There is also
a network->def which should contain the persistent definition of the
network when it is inactive, and the current live state at all other
times. The idea is that you can make changes to network->newDef which
will take effect the next time the network is restarted, but won't
mess with the current state of the network (virDomainObj has a similar
pair of virDomainDefs that behave in the same fashion). Personally I
think there should be a network->live and network->config, and the
location of the persistent config should *always* be in
network->config, but that's for a later cleanup).
Since I love things to be symmetric, I created a new function called
virNetworkObjUnsetDefTransient(), which reverses the effects of
virNetworkObjSetDefTransient(). I don't really like the name of the
new function, but then I also didn't really like the name of the old
one either (it's just named that way to match a similar function in
the domain conf code).
(cherry picked from commit 78fab2770b19097fe5e92ec339a9dd2d62d04bdb)
Cole Robinson [Fri, 12 Oct 2012 23:50:19 +0000 (19:50 -0400)]
Autogenerate AUTHORS
AUTHORS.in tracks the maintainers, as well as some folks who were
previously in AUTHORS but don't have a git commit with proper
attribution.
Generated output is sorted alphabetically and lacks pretty spacing, so
tweak AUTHORS.in to follow the same format.
Additionally, drop the syntax-check rule that previously validated
AUTHORS against git log.
(cherry picked from commit 7b21981cdb4f5d6c492edb2face8a8159dcc212e)
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)
Guannan Ren [Fri, 19 Oct 2012 08:44:30 +0000 (16:44 +0800)]
selinux: relabel tapfd in qemuPhysIfaceConnect
Relabeling tapfd right after the tap device is created.
qemuPhysIfaceConnect is common function called both for static
netdevs and for hotplug netdevs.
(cherry picked from commit 4492ef7f485a7d42d84a714d2150e648b11e2740)
Michal Privoznik [Thu, 18 Oct 2012 14:28:35 +0000 (16:28 +0200)]
network: Set to NULL after virNetworkDefFree()
which frees all allocated memory but doesn't set the passed pointer to
NULL. Therefore, we must do it ourselves. This is causing actual
libvirtd crash: Basically, when doing 'virsh net-edit' the newDef should
be dropped. And the memory is freed, indeed. However, the pointer is
not set to NULL but kept instead. And the next duo of calls 'virsh
net-start' and 'virsh net-destroy' starts the disaster. The latter one
does the same as 'virsh destroy'; it sees that newDef is nonNULL so it
replaces def with newDef (which has been freed already as said a few
lines above). Therefore any subsequent call accessing def will hit the ground.
(cherry picked from commit b7e9202401ebaa039b8f05acdefda8c24081537a)
Guannan Ren [Wed, 17 Oct 2012 03:23:19 +0000 (11:23 +0800)]
selinux: fix wrong tapfd relablling
It should relabel tapfd of virtual network of type VIR_DOMAIN_NET_TYPE_DIRECT
rather than VIR_DOMAIN_NET_TYPE_NETWORK and VIR_DOMAIN_NET_TYPE_BRIDGE
(commit ae368ebfcc4923d0b32e83d4ca96a6f599625785 introduced this bug)
Caution: The context of the two hunks is identical other than indentation.
Please be extremely cautious of where the patch gets applied.
(cherry picked from commit 89b63f0ad448a0442f4afc5489748e2cc829e527)
Guannan Ren [Mon, 15 Oct 2012 09:03:49 +0000 (17:03 +0800)]
selinux: add security selinux function to label tapfd
BZ:https://bugzilla.redhat.com/show_bug.cgi?id=851981
When using macvtap, a character device gets first created by
kernel with name /dev/tapN, its selinux context is:
system_u:object_r:device_t:s0
Shortly, when udev gets notification when new file is created
in /dev, it will then jump in and relabel this file back to the
expected default context:
system_u:object_r:tun_tap_device_t:s0
There is a time gap happened.
Sometimes, it will have migration failed, AVC error message:
type=AVC msg=audit(1349858424.233:42507): avc: denied { read write } for
pid=19926 comm="qemu-kvm" path="/dev/tap33" dev=devtmpfs ino=131524
scontext=unconfined_u:system_r:svirt_t:s0:c598,c908
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
This patch will label the tapfd device before qemu process starts:
system_u:object_r:tun_tap_device_t:MCS(MCS from seclabel->label)
(cherry picked from commit ae368ebfcc4923d0b32e83d4ca96a6f599625785)
We are currently able to work only with non-translated SELinux
contexts, but we are using functions that work with translated
contexts throughout the code. This patch swaps all SELinux context
translation relative calls with their raw sisters to avoid parsing
problems.
The problems can be experienced with mcstrans for example. The
difference is that if you have translations enabled (yum install
mcstrans; service mcstrans start), fgetfilecon_raw() will get you
something like 'system_u:object_r:virt_image_t:s0', whereas
fgetfilecon() will return 'system_u:object_r:virt_image_t:SystemLow'
that we cannot parse.
I was trying to confirm that the _raw variants were here since the dawn of
time, but the only thing I see now is that it was imported together in
the upstream repo [1] from svn, so before 2008.
Benjamin Cama [Wed, 26 Sep 2012 19:02:20 +0000 (21:02 +0200)]
network: fix dnsmasq/radvd binding to IPv6 on recent kernels
I hit this problem recently when trying to create a bridge with an IPv6
address on a 3.2 kernel: dnsmasq (and, further, radvd) would not bind to
the given address, waiting 20s and then giving up with -EADDRNOTAVAIL
(resp. exiting immediately with "error parsing or activating the config
file", without libvirt noticing it, BTW). This can be reproduced with (I
think) any kernel >= 2.6.39 and the following XML (to be used with
"virsh net-create"):
The problem is that since commit [1] (which, ironically, was made to
“help IPv6 autoconfiguration”) the linux bridge code makes bridges
behave like “real” devices regarding carrier detection. This makes the
bridges created by libvirt, which are started without any up devices,
stay with the NO-CARRIER flag set, and thus prevents DAD (Duplicate
address detection) from happening, thus letting the IPv6 address flagged
as “tentative”. Such addresses cannot be bound to (see RFC 2462), so
dnsmasq fails binding to it (for radvd, it detects that "interface XXX
is not RUNNING", thus that "interface XXX does not exist, ignoring the
interface" (sic)). It seems that this behavior was enhanced somehow with
commit [2] by avoiding setting NO-CARRIER on empty bridges, but I
couldn't reproduce this behavior on my kernel. Anyway, with the “dummy
tap to set MAC address” trick, this wouldn't work.
To fix this, the idea is to get the bridge's attached device to be up so
that DAD can happen (deactivating DAD altogether is not a good idea, I
think). Currently, libvirt creates a dummy TAP device to set the MAC
address of the bridge, keeping it down. But even if we set this device
up, it is not RUNNING as soon as the tap file descriptor attached to it
is closed, thus still preventing DAD. So, we must modify the API a bit,
so that we can get the fd, keep the tap device persistent, run the
daemons, and close it after DAD has taken place. After that, the bridge
will be flagged NO-CARRIER again, but the daemons will be running, even
if not happy about the device's state (but we don't really care about
the bridge's daemons doing anything when no up interface is connected to
it).
Other solutions that I envisioned were:
* Keeping the *-nic interface up: this would waste an fd for each
bridge during all its life. May be acceptable, I don't really
know.
* Stop using the dummy tap trick, and set the MAC address directly
on the bridge: it is possible since quite some time it seems,
even if then there is the problem of the bridge not being
RUNNING when empty, contrary to what [2] says, so this will need
fixing (and this fix only happened in 3.1, so it wouldn't work
for 2.6.39)
* Using the --interface option of dnsmasq, but I saw somewhere
that it's not used by libvirt for backward compatibility. I am
not sure this would solve this problem, though, as I don't know
how dnsmasq binds itself to it with this option.
This is why this patch does what's described earlier.
This patch also makes radvd start even if the interface is
“missing” (i.e. it is not RUNNING), as it daemonizes before binding to
it, and thus sometimes does it after the interface has been brought down
by us (by closing the tap fd), and then originally stops. This also
makes it stop yelling about it in the logs when the interface is down at
a later time.
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.
Peter Krempa [Tue, 16 Oct 2012 12:34:35 +0000 (14:34 +0200)]
spec: Add runtime requirement for libssh2
libssh2 unfortunately doesn't support symbol versioning so RPM can't
figure out what version is needed for the currently installed libvirt
package. This patch adds a runtime requirement, so that the correct
version of libssh2 can be installed along with libvirt.
(cherry picked from commit cb4f41b8d0a2dc4258f1b097dff2ca2b34fbd086)
projects / thirdparty / libvirt.git / log
