The libvirt.pc file we install is ending up polluted with a
load of compiler flags that should be private to the libvirt
build. eg

Libs: -L${libdir} -lvirt -ldl -O2 -g -pipe -Wall \
      -Wp,-D_FORTIFY_SOURCE=2 -fexceptions \
      -fstack-protector-strong --param=ssp-buffer-size=4 \
      -grecord-gcc-switches  -m64 -mtune=generic

this is caused by including @libs@ in the Libs: line of the
pkgconfig.pc.in file.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 1167751f)

We have the following matrix of possible arguments handled by the logic
statement touched by this patch:
       | flags & _REUSE_EXT | !(flags & _REUSE_EXT)
-------+--------------------+----------------------
 format| (1)                | (2)
-------+--------------------+----------------------
!format| (3)                | (4)
-------+--------------------+----------------------

In cases 1 and 2 the user provided a format, in cases 3 and 4 not. The
user requests to use a pre-existing image in 1 and 3 and libvirt will
create a new image in 2 and 4.

The difference between cases 3 and 4 is that for 3 the format is probed
from the user-provided image, whereas in 4 we just use the existing disk
format.

The current code would treat cases 1,3 and 4 correctly but in case 2 the
format provided by the user would be ignored.

The particular piece of code was broken in commit 35c7701c
but since it was introduced a few commits before that it was never
released as working.

(cherry picked from commit 42619ed0)
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	src/qemu/qemu_driver.c - no refactoring of commits 7b7bf001, 4f202266

Newer git doesn't like the maint.mk rule 'public-submodule-commit'
run during 'make check', as inherited from our checkout of gnulib.
I tracked down that libvirt commit 8531301d picked up a gnulib fix
that makes git happy.  Rather than try and do a full .gnulib
submodule update to gnulib.git d18d1b802 (as used in that libvirt
commit), it was easier to just backport the fixed maint.mk from
gnulib on top of our existing submodule level.  I did it as follows,
where these steps will have to be repeated when cherry-picking this
commit to any other maintenance branch:

mkdir -p gnulib/local/top
cd .gnulib
git checkout d18d1b802 top/maint.mk
git diff HEAD > ../gnulib/local/top/maint.mk.diff
git reset --hard
cd ..
git add gnulib/local/top
Signed-off-by: NEric Blake <eblake@redhat.com>

We publish libvirt-api.xml for others to use, and in fact, the
libvirt-python bindings use it to generate python constants that
correspond to our enum values.  However, we had an off-by-one bug
that any enum that relied on C's rules for implicit initialization
of the first enum member to 0 got listed in the xml as having a
value of 1 (and all later members of the enum were equally
botched).

The fix is simple - since we add one to the previous value when
encountering an enum without an initializer, the previous value
must start at -1 so that the first enum member is assigned 0.

The python generator code has had the off-by-one ever since DV
first wrote it years ago, but most of our public enums were immune
because they had an explicit = 0 initializer.  The only affected
enums are:
- virDomainEventGraphicsAddressType (such as
VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4), since commit 987e31ed
(libvirt v0.8.0)
- virDomainCoreDumpFormat (such as VIR_DOMAIN_CORE_DUMP_FORMAT_RAW),
since commit 9fbaff00 (libvirt v1.2.3)
- virIPAddrType (such as VIR_IP_ADDR_TYPE_IPV4), since commit
03e0e79e (not yet released)

Thanks to Nehal J Wani for reporting the problem on IRC, and
for helping me zero in on the culprit function.

* docs/apibuild.py (CParser.parseEnumBlock): Fix implicit enum
values.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 9b291bbe)

When creating a new disk mirror the new struct is stored in a separate
variable until everything went well. The removed hunk would actually
remove existing mirror information for example when the api would be run
if a mirror still exists.

(cherry picked from commit 02b364e1)

This fixes a regression introduced in commit ff5f30b6.
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	src/qemu/qemu_driver.c - no refactoring of commits 7b7bf001, 4f202266

If the XML_PARSE_NOENT flag is passed to libxml2, then any
entities in the input document will be fully expanded. This
allows the user to read arbitrary files on the host machine
by creating an entity pointing to a local file. Removing
the XML_PARSE_NOENT flag means that any entities are left
unchanged by the parser, or expanded to "" by the XPath
APIs.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit d6b27d3e)

libxl uses the libxl_vnc_info and libxl_sdl_info fields from the
hvm union in libxl_domain_build_info struct when generating QEMU
args for VNC or SDL.  These fields were left unset by the libxl
driver, causing libxl to ignore any user settings.  E.g. with

  <graphics type='vnc' port='5950'/>

port would be ignored and QEMU would instead be invoked with

  -vnc 127.0.0.1:0,to=99

Unlike the libxl_domain_config struct, the libxl_domain_build_info
contains only a single libxl_vnc_info and libxl_sdl_info, so
populate these fields from the first vfb in
libxl_domain_config->vfbs.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDavid Kiarie <davidkiarie4@gmail.com>
(cherry picked from commit b55cc5f4)

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

Whenever we check for ABI stability, we have new xml (e.g. provided by
user, or obtained from snapshot, whatever) which we compare to old xml
and see if ABI won't break. However, if the new xml was produced via
virDomainGetXMLDesc(..., VIR_DOMAIN_XML_MIGRATABLE) it lacks some
devices, e.g. 'pci-root' controller. Hence, the ABI stability check
fails even though it is stable. Moreover, we can't simply fix
virDomainDefCheckABIStability because removing the correct devices is
task for the driver. For instance, qemu driver wants to remove the usb
controller too, while LXC driver doesn't. That's why we need special
qemu wrapper over virDomainDefCheckABIStability which removes the
correct devices from domain XML, produces MIGRATABLE xml and calls the
check ABI stability function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 7d704812)

Other drivers in libvirt (e.g. network, qemu) will automatically
return the "inactive" (persistent configuration) XML of an object when
that object is inactive. The netcf backend of the interface driver
would always try to return the live status XML of the interface, even
when it was down. Although netcf does return valid XML in that case,
for bond interfaces it is missing almost all of its content, including
the <bond> subelement itself, leading to this error message from
"virsh iface-dumpxml" of a bond interface that is inactive:

  error: XML error: bond interface misses the bond element

(this is because libvirt's validation of the XML returned by netcf
always requires a <bond> element be present).

This patch modifies the interface driver netcf backend to check if the
interface is inactive, and in that case always return the inactive XML
(which will always have a <bond> element, thus eliminating the error
message, as well as making operation more in line with other drivers.

This fixes the following bug:

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

(cherry picked from commit 7284c499)

This function barely wraps ncf_if_status() and error handling code.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 50f5468c)

There has been a new field introduced in iscsiadm --mode session
output [1], but our regex only expects four fields. This breaks
startup of iscsi pools:
error: Failed to start pool iscsi
error: internal error: cannot find session

Fix this by ignoring anything after the fourth field.

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

[1] https://github.com/mikechristie/open-iscsi/commit/181af9a

(cherry picked from commit 57e17a74)

If a domain network interface that contains a <filterref> is modified
"live" using "virsh update-device --live", libvirtd would crash. This
was because the code supporting live update of an interface's
filterref was assuming that a filterref might be added or modified,
but didn't account for removing the filterref, resulting in a null
dereference of the filter name.

Introduced with commit 258fb278, which was first in libvirt v1.0.1.

This addresses https://bugzilla.redhat.com/show_bug.cgi?id=1093301

(cherry picked from commit 0eac9d1e)

QEMU only supports it on x86, but we've been assuming it for
all QEMUs when doing QMP capability detection.

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

The systemd journal expects log record PRIORITY values to
be encoded using the syslog compatible numbering scheme,
not libvirt's own native numbering scheme. We must therefore
apply a conversion.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 21d370f0)

Conflicts:
	src/util/virlog.c - whitespace (commit c7c84fa5)

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

Commit 5b3492fa aimed to fix this and caught one error but exposed
another one.  When agent command is being executed and the thread
waiting for the reply is woken up by an event (e.g. EOF in case of
shutdown), the command finishes with no data (rxObject == NULL), but
no error is reported, since this might be desired by the caller
(e.g. suspend through agent).  However, in other situations, when the
data are required (e.g. getting vCPUs), we proceed to getting desired
data out of the reply, but none of the virJSON*() functions works well
with NULLs.  I chose the way of a new parameter for qemuAgentCommand()
function that specifies whether reply is required and behaves
according to that.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1058149Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 736e017e)

by moving qemuAgentCommand() after qemuAgentCheckError().
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit e9d09fe1)

Conflicts:
	src/qemu/qemu_agent.c -- label indentation (5922d05a)

(cherry picked from commit f22a98d3d3602e3037404c4cfaee0d45605e59fc)

On all the places where qemuAgentComand() was called, we did a check
for errors in the reply.  Unfortunately, some of the places called
qemuAgentCheckError() without checking for non-null reply which might
have resulted in a crash.

So this patch makes the error-checking part of qemuAgentCommand()
itself, which:

 a) makes it look better,

 b) makes the check mandatory and, most importantly,

 c) checks for the errors if and only if it is appropriate.

This actually fixes a potential crashers when qemuAgentComand()
returned 0, but reply was NULL.  Having said that, it *should* fix the
following bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1058149Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 5b3492fa)

Without this, using /dev/mapper as a directory pool
fails in virStorageBackendUpdateVolTargetInfoFD:
cannot seek to end of file '/dev/mapper/control': Illegal seek

Skip over character devices by default.

https://bugzilla.redhat.com/show_bug.cgi?id=710866
(cherry picked from commit 0edfc9ef)

If we cannot stat/open a file on pool refresh, returning -1 aborts
the refresh and the pool is undefined.

Only treat missing files as fatal unless VolOpenCheckMode is called
with the VIR_STORAGE_VOL_OPEN_ERROR flag. If this flag is missing
(when it's called from virStorageBackendProbeTarget in
virStorageBackendFileSystemRefresh), only emit a warning and return
-2 to let the caller skip over the file.

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

We are calling fstat() at least twice per storage volume in
a directory storage pool; this is rather wasteful.  Refactoring
this is also a step towards making code reusable for gluster,
where gluster can provide struct stat but cannot use fstat().

* src/storage/storage_backend.h
(virStorageBackendVolOpenCheckMode)
(virStorageBackendUpdateVolTargetInfoFD): Update signature.
* src/storage/storage_backend.c
(virStorageBackendVolOpenCheckMode): Pass stat results back.
(virStorageBackendUpdateVolTargetInfoFD): Use existing stats.
(virStorageBackendVolOpen, virStorageBackendUpdateVolTargetInfo):
Update callers.
* src/storage/storage_backend_fs.c (virStorageBackendProbeTarget):
Likewise.
* src/storage/storage_backend_scsi.c
(virStorageBackendSCSIUpdateVolTargetInfo): Likewise.
* src/storage/storage_backend_mpath.c
(virStorageBackendMpathUpdateVolTargetInfo): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 9cac8639)

Do not leave the PCI address of the primary video card set
to the legacy default (0000:00:02.0) if we're doing two-pass
allocation.

Since QEMU 1.6 (QEMU_CAPS_VIDEO_PRIMARY) we allow the primary
video card to be on other slots than 0000:00:02.0 (as we use
-device instead of -vga).

However we fail to assign it an address if:
* another device explicitly uses 0000:00:02.0 and
* the primary video device has no address specified

On the first pass, we have set the address to default, then checked
if it's available, leaving it set even if it wasn't. This address
got picked up by the second pass, resulting in a conflict:

XML error: Attempted double use of PCI slot 0000:00:02.0
(may need "multifunction='on'" for device on function 0)

Also fix the test that was supposed to catch this.

(cherry picked from commit ec128e69)

Currently, we use pthread_sigmask(SIG_BLOCK, ...) prior to calling
poll(). This is okay, as we don't want poll() to be interrupted.
However, then - immediately as we fall out from the poll() - we try to
restore the original sigmask - again using SIG_BLOCK. But as the man
page says, SIG_BLOCK adds signals to the signal mask:

SIG_BLOCK
      The set of blocked signals is the union of the current set and the set argument.

Therefore, when restoring the original mask, we need to completely
overwrite the one we set earlier and hence we should be using:

SIG_SETMASK
      The set of blocked signals is set to the argument set.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 3d4b4f5a)

$ touch /var/lib/libvirt/images/'a<b>c'
$ virsh pool-refresh default
$ virsh vol-dumpxml 'a<b>c' default | head -n2
<volume>
  <name>a<b>c</name>

Oops.  That's not valid XML.  And when we fix the XML
generation, it fails RelaxNG validation.

I'm also tired of seeing <key>(null)</key> in the example
output for volume xml; while we used NULLSTR() to avoid
a NULL deref rather than relying on glibc's printf
extension behavior, it's even better if we avoid the issue
in the first place.  But this requires being careful that
we don't invalidate any storage backends that were relying
on key being unassigned during virStoragVolCreateXML[From].

I would have split this into two patches (one for escaping,
one for avoiding <key>(null)</key>), but since they both
end up touching a lot of the same test files, I ended up
merging it into one.

Note that this patch allows pretty much any volume name
that can appear in a directory (excluding . and .. because
those are special), but does nothing to change the current
(unenforced) RelaxNG claim that pool names will consist
only of letters, numbers, _, -, and +.  Tightening the C
code to match RelaxNG patterns and/or relaxing the grammar
to match the C code for pool names is a task for another
day (but remember, we DID recently tighten C code for
domain names to exclude a leading '.').

* src/conf/storage_conf.c (virStoragePoolSourceFormat)
(virStoragePoolDefFormat, virStorageVolTargetDefFormat)
(virStorageVolDefFormat): Escape user-controlled strings.
(virStorageVolDefParseXML): Parse key, for use in unit tests.
* src/storage/storage_driver.c (storageVolCreateXML)
(storageVolCreateXMLFrom): Ensure parsed key doesn't confuse
volume creation.
* docs/schemas/basictypes.rng (volName): Relax definition.
* tests/storagepoolxml2xmltest.c (mymain): Test it.
* tests/storagevolxml2xmltest.c (mymain): Likewise.
* tests/storagepoolxml2xmlin/pool-dir-naming.xml: New file.
* tests/storagepoolxml2xmlout/pool-dir-naming.xml: Likewise.
* tests/storagevolxml2xmlin/vol-file-naming.xml: Likewise.
* tests/storagevolxml2xmlout/vol-file-naming.xml: Likewise.
* tests/storagevolxml2xmlout/vol-*.xml: Fix fallout.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 6cc4d6a3)

Most of our code base uses space after comma but not before;
fix the remaining uses before adding a syntax check.

* src/conf/capabilities.c: Consistently use commas.
* src/conf/domain_conf.c: Likewise.
* src/conf/network_conf.c: Likewise.
* src/conf/storage_conf.c: Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 6f4901e1)

Systemd does not forget about the cases, where client service needs to
wait for daemon service to initialize and start accepting new clients.
Setting a dependency in client is not enough as systemd doesn't know
when the daemon has initialized itself and started accepting new
clients. However, it offers a mechanism to solve this. The daemon needs
to call a special systemd function by which the daemon tells "I'm ready
to accept new clients". This is exactly what we need with
libvirtd-guests (client) and libvirtd (daemon). So now, with this
change, libvirt-guests.service is invoked not any sooner than
libvirtd.service calls the systemd notify function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 68954fb2)

I've noticed that in some cases systemd was quick enough and even
if libvirt-guests.service is marked to be started after the
libvirtd.service my guests were not resumed as
libvirt-guests.sh failed to connect. This is because of a
simple fact: systemd correctly starts libvirt-guests after it
execs libvirtd. However, the daemon is not able to accept
connections right from the start. It's doing some
initialization which may take ages. This problem is not limited
to systemd only, indeed. Any init system that is able to startup
services in parallel (e.g. OpenRC) may run into this situation.
The fix is to try connecting not only once, but continuously a few
times with a small sleep in between tries.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 4e7fc830)

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

When creating a new domain, we let systemd know about it by calling
CreateMachine() function via dbus. Systemd then creates a scope and
places domain into it. However, later when the host is shutting
down, systemd computes the shutdown order to see what processes can
be shut down in parallel. And since we were not setting
dependencies at all, the slices (and thus domains) were most likely
killed before libvirt-guests.service. So user domains that had to
be saved, shut off, whatever were in fact killed.  This problem can
be solved by letting systemd know that scopes we're creating must
not be killed before libvirt-guests.service.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit ba79e387)

We point to the manpages where available and redirect to libvirt's
homepage as a last resort.

(cherry picked from commit 1b9f5aa7)

The nwfilter conf update mutex previously serialized
updates to the internal data structures for firewall
rules, and updates to the firewall itself. The latter
was recently turned into a read/write lock, and filter
instantiation allowed to proceed in parallel. It was
believed that this was ok, since each filter is created
on a separate iptables/ebtables chain.

It turns out that there is a subtle lock ordering problem
on virNWFilterObjPtr instances. __virNWFilterInstantiateFilter
will hold a lock on the virNWFilterObjPtr it is instantiating.
This in turn invokes virNWFilterInstantiate which then invokes
virNWFilterDetermineMissingVarsRec which then invokes
virNWFilterObjFindByName. This iterates over every single
virNWFilterObjPtr in the list, locking them and checking their
name. So if 2 or more threads try to instantiate a filter in
parallel, they'll all hold 1 lock at the top level in the
__virNWFilterInstantiateFilter method which will cause the
other thread to deadlock in virNWFilterObjFindByName.

The fix is to add an exclusive mutex to serialize the
execution of __virNWFilterInstantiateFilter.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 925de19e)

Needed for architectures that don't use gcc atomic ops but pthread. This
fixes the armel build that otherwise breaks like:

 CCLD     virt-login-shell
 ../src/.libs/libvirt-setuid-rpc-client.a(libvirt_setuid_rpc_client_la-virobject.o): In function `virClassNew':
 /«PKGBUILDDIR»/debian/build/src/../../../src/util/virobject.c:150: undefined reference to `virAtomicLock'
 ../src/.libs/libvirt-setuid-rpc-client.a(libvirt_setuid_rpc_client_la-virobject.o): In function `virObjectNew':
 /«PKGBUILDDIR»/debian/build/src/../../../src/util/virobject.c:202: undefined reference to `virAtomicLock'
 ../src/.libs/libvirt-setuid-rpc-client.a(libvirt_setuid_rpc_client_la-virobject.o): In function `virObjectUnref':
 /«PKGBUILDDIR»/debian/build/src/../../../src/util/virobject.c:274: undefined reference to `virAtomicLock'
 ../src/.libs/libvirt-setuid-rpc-client.a(libvirt_setuid_rpc_client_la-virobject.o): In function `virObjectRef':
 /«PKGBUILDDIR»/debian/build/src/../../../src/util/virobject.c:295: undefined reference to `virAtomicLock'
 collect2: error: ld returned 1 exit status

See https://buildd.debian.org/status/fetch.php?pkg=libvirt&arch=armel&ver=1.1.4-1&stamp=1383588268

(cherry picked from commit 12dc729a)

aebbcdd3 didn't change the non-linux definition of the function,
breaking the build on FreeBSD:

../../src/util/virinitctl.c:164: error: conflicting types for
'virInitctlSetRunLevel'
../../src/util/virinitctl.h:40: error: previous declaration of
'virInitctlSetRunLevel' was here

(cherry picked from commit adc8b2af)

Rewrite multiple hotunplug functions to to use the
virProcessRunInMountNamespace helper. This avoids
risk of a malicious guest replacing /dev with an absolute
symlink, tricking the driver into changing the host OS
filesystem.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 5fc590ad)

Rewrite lxcDomainAttachDeviceHostdevMiscLive function
to use the virProcessRunInMountNamespace helper. This avoids
risk of a malicious guest replacing /dev with a absolute
symlink, tricking the driver into changing the host OS
filesystem.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 1cadeafc)

Rewrite lxcDomainAttachDeviceHostdevStorageLive function
to use the virProcessRunInMountNamespace helper. This avoids
risk of a malicious guest replacing /dev with a absolute
symlink, tricking the driver into changing the host OS
filesystem.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 1754c7f0)

Rewrite lxcDomainAttachDeviceHostdevSubsysUSBLive function
to use the virProcessRunInMountNamespace helper. This avoids
risk of a malicious guest replacing /dev with a absolute
symlink, tricking the driver into changing the host OS
filesystem.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 7fba01c1)

Rewrite lxcDomainAttachDeviceDiskLive function to use the
virProcessRunInMountNamespace helper. This avoids risk of
a malicious guest replacing /dev with a absolute symlink,
tricking the driver into changing the host OS filesystem.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 4dd3a7d5)

Use helper virProcessRunInMountNamespace in lxcDomainShutdownFlags and
lxcDomainReboot.  Otherwise, a malicious guest could use symlinks
to force the host to manipulate the wrong file in the host's namespace.

Idea by Dan Berrange, based on an initial report by Reco
<recoverym4n@gmail.com> at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732394Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit aebbcdd3)

Implement virProcessRunInMountNamespace, which runs callback of type
virProcessNamespaceCallback in a container namespace. This uses a
child process to run the callback, since you can't change the mount
namespace of a thread. This implies that callbacks have to be careful
about what code they run due to async safety rules.

Idea by Dan Berrange, based on an initial report by Reco
<recoverym4n@gmail.com> at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732394Signed-off-by: NDaniel Berrange <berrange@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 7c72ef6f)