The previous patch was incomplete.

  CC       libvirt_util_la-vircgroup.lo
../../src/util/vircgroup.c:70:12: error: 'virCgroupPartitionEscape' declared 'static' but never defined [-Werror=unused-function]
 static int virCgroupPartitionEscape(char **path);
            ^

* src/util/vircgroup.c (virCgroupPartitionEscape): Move forward
declaration inside conditional.
Signed-off-by: NEric Blake <eblake@redhat.com>

The virCgroupValidateMachineGroup method calls some functions
which are only conditionally compiled, thus it too must be
made conditional. This fixes the build on non-Linux hosts.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

A VPATH build 'make check' was failing with:

  GEN      check-driverimpls
Can't open ../../src/../../src/lxc/lxc_monitor_protocol.h: No such file or directory at ../../src/check-driverimpls.pl line 29, <> line 27153.
Can't open ../../src/../../src/lxc/lxc_monitor_protocol.c: No such file or directory at ../../src/check-driverimpls.pl line 29, <> line 27153.
...
  GEN      check-aclrules
cannot read ../../src/../../src/remote/remote_protocol.x at ../../src/check-aclrules.pl line 128.

because $(srcdir) was being prepended to file names that already
included it.

* src/Makefile.am (check-driverimpls): Don't add srcdir twice.
Signed-off-by: NEric Blake <eblake@redhat.com>

File hasn't been really touched for 7 years. And with recent rawhide
changes it contributed to an RPM build failure. Let's drop it.

This also removes installation of a libvirt-python doc dir, so drop
handling of it from the RPM spec.

When the legacy Xen driver probes with a NULL URI, and
finds itself running on Xen, it will set conn->uri. A
little bit later though it checks to see if libxl support
exists, and if so declines the driver. This leaves the
conn->uri set to 'xen:///', so if libxl also declines
it, it prevents probing of the QEMU driver.

Once a driver has set the conn->uri, it must *never*
decline an open request. So we must move the libxl
check earlier
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

CPU data structure is refined, which causes one compile error for PPC.
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>

https://bugzilla.redhat.com/show_bug.cgi?id=981094
The commit 0ad9025e introduce qemu flag QEMU_CAPS_DEVICE_VIDEO_PRIMARY
for using -device VGA, -device cirrus-vga, -device vmware-svga and
-device qxl-vga. In use, for -device qxl-vga, mouse doesn't display
in guest window like the desciption in above bug.
This patch try to use -device for primary video when qemu >=1.6 which
contains the bug fix patch

Otherwise, with new enough gcc compiling at -O2, the build fails with:
../../src/conf/domain_conf.c: In function ‘virDomainDeviceDefPostParse’:
../../src/conf/domain_conf.c:2821:29: error: ‘cnt’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
             for (i = 0; i < *cnt; i++) {
                             ^
../../src/conf/domain_conf.c:2795:20: note: ‘cnt’ was declared here
         size_t i, *cnt;
                    ^
../../src/conf/domain_conf.c:2794:30: error: ‘arrPtr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
         virDomainChrDefPtr **arrPtr;
                              ^

* src/conf/domain_conf.c (virDomainChrGetDomainPtrs): Always
assign into output parameters.
Signed-off-by: NEric Blake <eblake@redhat.com>

By setting the default partition in libvirt_lxc it is not
visible when querying the live XML. Move setting of the
default partition into libvirtd virLXCProcessStart
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Adjust these drivers to handle their Autostart functionality after each
of the drivers has gone through their Initialization functions

Separation allows for dependent drivers to be make a connection during
the AutoStart phase of state initialization.

Ignore NULL pool in testSetVolumeType to silence Coverity,
even though we only call it with NULL pool when vol is also NULL.

(13) Event var_deref_model:	Passing null pointer "inputpool" to
function "testSetVolumeType(virStorageVolDefPtr, virStoragePoolDefPtr)",
which dereferences it. [details]
Also see events: [assign_zero]

95    testSetVolumeType(inputvol, inputpool);

ip has to be NULL at this point.

This fixes a crash if one of them is missing.

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

Decrementing it when it was already 0 causes an invalid free
in virNetworkDefUpdateDNSHost if virNetworkDNSHostDefParseXML
fails and virNetworkDNSHostDefClear gets called twice.

virNetworkForwardDefClear left the number untouched even if it
freed all the elements.

The outbound/@peak is ignored (since QoS was introduced). This is due to
kernel limitation of know allowing ingress filters to have peak just
average rate. However, we should document this limitation to not confuse
users.

Interestingly, we had <code>floor<code> ... </code>outbound</code> which
results in much larger block of text to be written in code style that
intended.

Signed-off-by: NAlex Jia <ajia@redhat.com>

Noticed that the expected "not supported" error is dropped when
invoking 'virsh snapshot-list dom' on a Xen installation running
the libxl driver

 virsh snapshot-list test
 error: Invalid snapshot: virDomainSnapshotFree

The error is overwritten by a call to virDomainSnapshotFree
in cleanup code within cmdSnapshotList.  Prevent overwritting
the real error by not calling virDomainSnapshotFree with a NULL
virDomainSnapshotPtr.

If the app has provided a whitelist of controllers to be used,
we skip detecting its mount point. We still, however, fill in
the placement info which later confuses the machine name
validation code. Skip detecting placement if the controller
mount point is not set
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When detecting cgroups we must honour any controllers
whitelist the driver may have.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When a VM has an 'emulator' child cgroup present, we must
strip off that suffix when detecting the cgroup for a
machine

Rename the virCgroupIsValidMachineGroup method to
virCgroupValidateMachineGroup to make a bit clearer
that this isn't simply a boolean check, it will make
changes to the object.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virCgroupIsValidMachine does not need to be called from
outside the cgroups file now, so make it static.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Instead of requiring drivers to use a combination of calls
to virCgroupNewDetect and virCgroupIsValidMachine, combine
the two into virCgroupNewDetectMachine
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

since sizeof(int) != sizeof(long long) on 32bit archs.

This unbreaks virdbustest which otherwise fails like:

 (gdb) bt
 #0  __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:50
 #1  0x405907d2 in ?? () from /lib/i386-linux-gnu/libdbus-1.so.3
 #2  0x4057c140 in ?? () from /lib/i386-linux-gnu/libdbus-1.so.3
 #3  0x4057e7ec in dbus_message_iter_append_basic () from /lib/i386-linux-gnu/libdbus-1.so.3
 #4  0x400742ec in virDBusMessageIterEncode (args=0xbfd4b8f0 "k\321\004\b.", types=0x804d260 "",
     rootiter=0xbfd4b844) at util/virdbus.c:560
 #5  virDBusMessageEncodeArgs (msg=msg@entry=0x893c278, types=types@entry=0x804d25c "sais",
     args=args@entry=0xbfd4b8d8 "r\320\004\b\003") at util/virdbus.c:921
 #6  0x40075917 in virDBusMessageEncode (msg=0x893c278, types=0x804d25c "sais") at util/virdbus.c:959
 #7  0x0804a4a1 in testMessageArray (args=0x0) at virdbustest.c:195
 #8  0x0804c404 in virtTestRun (title=title@entry=0x804cfcb "Test message array ",
     nloops=nloops@entry=1, body=body@entry=0x804a3f0 <testMessageArray>, data=data@entry=0x0)
     at testutils.c:168
 #9  0x08049346 in mymain () at virdbustest.c:384
 #10 0x0804cb2e in virtTestMain (argc=argc@entry=1, argv=argv@entry=0xbfd4bb24,
     func=func@entry=0x80492c0 <mymain>) at testutils.c:764
 #11 0x080491af in main (argc=1, argv=0xbfd4bb24) at virdbustest.c:393

This allows testing the command line for cloning file-based
volumes into logical volumes and vice versa.

Reuse the XML files in storagevolxml2xmlin.

(This requires changing a few backing files to /dev/null,
since virStorageBackendCreateQemuImgCmd checks for its
presence)

Reuse the pool definition from storagepoolxml2xmlin.

Reindent them to put the input volume on a separate line.

Check if PCI bridges with duplicate indexes are rejected.
PCI root controllers with non-zero indexes or addresses should
also be rejected.

Both virStoragePoolFree and virStorageVolFree reset the last error,
which might lead to the cryptic message:
An error occurred, but the cause is unknown

When the volume wasn't found, virStorageVolFree was called with NULL,
leading to an error:
invalid storage volume pointer in virStorageVolFree

This patch changes it to:
Storage volume not found: no storage vol with matching name 'tomato'

Add protection such that the virCgroupRemove and
virCgroupKill* do not do anything to the root cgroup.

Killing all PIDs in the root cgroup does not end well.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Convert the LXC driver code to use the new atomic API
for setup of cgroups
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Convert the QEMU driver code to use the new atomic API
for setup of cgroups
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Instead of requiring one API call to create a cgroup and
another to add a task to it, introduce a new API
virCgroupNewMachine which does both jobs at once. This
will facilitate the later code to talk to systemd to
achieve this job which is also atomic.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There's a race in lxc driver causing a deadlock. If a domain is
destroyed immediately after started, the deadlock can occur. When domain
is started, the even loop tries to connect to the monitor. If the
connecting succeeds, virLXCProcessMonitorInitNotify() is called with
@mon->client locked. The first thing that callee does, is
virObjectLock(vm). So the order of locking is: 1) @mon->client, 2) @vm.

However, if there's another thread executing virDomainDestroy on the
very same domain, the first thing done here is locking the @vm. Then,
the corresponding libvirt_lxc process is killed and monitor is closed
via calling virLXCMonitorClose(). This callee tries to lock @mon->client
too. So the order is reversed to the first case. This situation results
in deadlock and unresponsive libvirtd (since the eventloop is involved).

The proper solution is to unlock the @vm in virLXCMonitorClose prior
entering virNetClientClose(). See the backtrace as follows:

Thread 25 (Thread 0x7f1b7c9b8700 (LWP 16312)):
0  0x00007f1b80539714 in __lll_lock_wait () from /lib64/libpthread.so.0
1  0x00007f1b8053516c in _L_lock_516 () from /lib64/libpthread.so.0
2  0x00007f1b80534fbb in pthread_mutex_lock () from /lib64/libpthread.so.0
3  0x00007f1b82a637cf in virMutexLock (m=0x7f1b3c0038d0) at util/virthreadpthread.c:85
4  0x00007f1b82a4ccf2 in virObjectLock (anyobj=0x7f1b3c0038c0) at util/virobject.c:320
5  0x00007f1b82b861f6 in virNetClientCloseInternal (client=0x7f1b3c0038c0, reason=3) at rpc/virnetclient.c:696
6  0x00007f1b82b862f5 in virNetClientClose (client=0x7f1b3c0038c0) at rpc/virnetclient.c:721
7  0x00007f1b6ee12500 in virLXCMonitorClose (mon=0x7f1b3c007210) at lxc/lxc_monitor.c:216
8  0x00007f1b6ee129f0 in virLXCProcessCleanup (driver=0x7f1b68100240, vm=0x7f1b680ceb70, reason=VIR_DOMAIN_SHUTOFF_DESTROYED) at lxc/lxc_process.c:174
9  0x00007f1b6ee14106 in virLXCProcessStop (driver=0x7f1b68100240, vm=0x7f1b680ceb70, reason=VIR_DOMAIN_SHUTOFF_DESTROYED) at lxc/lxc_process.c:710
10 0x00007f1b6ee1aa36 in lxcDomainDestroyFlags (dom=0x7f1b5c002560, flags=0) at lxc/lxc_driver.c:1291
11 0x00007f1b6ee1ab1a in lxcDomainDestroy (dom=0x7f1b5c002560) at lxc/lxc_driver.c:1321
12 0x00007f1b82b05be5 in virDomainDestroy (domain=0x7f1b5c002560) at libvirt.c:2303
13 0x00007f1b835a7e85 in remoteDispatchDomainDestroy (server=0x7f1b857419d0, client=0x7f1b8574ae40, msg=0x7f1b8574acf0, rerr=0x7f1b7c9b7c30, args=0x7f1b5c004a50) at remote_dispatch.h:3143
14 0x00007f1b835a7d78 in remoteDispatchDomainDestroyHelper (server=0x7f1b857419d0, client=0x7f1b8574ae40, msg=0x7f1b8574acf0, rerr=0x7f1b7c9b7c30, args=0x7f1b5c004a50, ret=0x7f1b5c0029e0) at remote_dispatch.h:3121
15 0x00007f1b82b93704 in virNetServerProgramDispatchCall (prog=0x7f1b8573af90, server=0x7f1b857419d0, client=0x7f1b8574ae40, msg=0x7f1b8574acf0) at rpc/virnetserverprogram.c:435
16 0x00007f1b82b93263 in virNetServerProgramDispatch (prog=0x7f1b8573af90, server=0x7f1b857419d0, client=0x7f1b8574ae40, msg=0x7f1b8574acf0) at rpc/virnetserverprogram.c:305
17 0x00007f1b82b8c0f6 in virNetServerProcessMsg (srv=0x7f1b857419d0, client=0x7f1b8574ae40, prog=0x7f1b8573af90, msg=0x7f1b8574acf0) at rpc/virnetserver.c:163
18 0x00007f1b82b8c1da in virNetServerHandleJob (jobOpaque=0x7f1b8574dca0, opaque=0x7f1b857419d0) at rpc/virnetserver.c:184
19 0x00007f1b82a64158 in virThreadPoolWorker (opaque=0x7f1b8573cb10) at util/virthreadpool.c:144
20 0x00007f1b82a63ae5 in virThreadHelper (data=0x7f1b8574b9f0) at util/virthreadpthread.c:161
21 0x00007f1b80532f4a in start_thread () from /lib64/libpthread.so.0
22 0x00007f1b7fc4f20d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f1b83546740 (LWP 16297)):
0  0x00007f1b80539714 in __lll_lock_wait () from /lib64/libpthread.so.0
1  0x00007f1b8053516c in _L_lock_516 () from /lib64/libpthread.so.0
2  0x00007f1b80534fbb in pthread_mutex_lock () from /lib64/libpthread.so.0
3  0x00007f1b82a637cf in virMutexLock (m=0x7f1b680ceb80) at util/virthreadpthread.c:85
4  0x00007f1b82a4ccf2 in virObjectLock (anyobj=0x7f1b680ceb70) at util/virobject.c:320
5  0x00007f1b6ee13bd7 in virLXCProcessMonitorInitNotify (mon=0x7f1b3c007210, initpid=4832, vm=0x7f1b680ceb70) at lxc/lxc_process.c:601
6  0x00007f1b6ee11fd3 in virLXCMonitorHandleEventInit (prog=0x7f1b3c001f10, client=0x7f1b3c0038c0, evdata=0x7f1b8574a7d0, opaque=0x7f1b3c007210) at lxc/lxc_monitor.c:109
7  0x00007f1b82b8a196 in virNetClientProgramDispatch (prog=0x7f1b3c001f10, client=0x7f1b3c0038c0, msg=0x7f1b3c003928) at rpc/virnetclientprogram.c:259
8  0x00007f1b82b87030 in virNetClientCallDispatchMessage (client=0x7f1b3c0038c0) at rpc/virnetclient.c:1019
9  0x00007f1b82b876bb in virNetClientCallDispatch (client=0x7f1b3c0038c0) at rpc/virnetclient.c:1140
10 0x00007f1b82b87d41 in virNetClientIOHandleInput (client=0x7f1b3c0038c0) at rpc/virnetclient.c:1312
11 0x00007f1b82b88f51 in virNetClientIncomingEvent (sock=0x7f1b3c0044e0, events=1, opaque=0x7f1b3c0038c0) at rpc/virnetclient.c:1832
12 0x00007f1b82b9e1c8 in virNetSocketEventHandle (watch=3321, fd=54, events=1, opaque=0x7f1b3c0044e0) at rpc/virnetsocket.c:1695
13 0x00007f1b82a272cf in virEventPollDispatchHandles (nfds=21, fds=0x7f1b8574ded0) at util/vireventpoll.c:498
14 0x00007f1b82a27af2 in virEventPollRunOnce () at util/vireventpoll.c:645
15 0x00007f1b82a25a61 in virEventRunDefaultImpl () at util/virevent.c:273
16 0x00007f1b82b8e97e in virNetServerRun (srv=0x7f1b857419d0) at rpc/virnetserver.c:1097
17 0x00007f1b8359db6b in main (argc=2, argv=0x7ffff98dbaa8) at libvirtd.c:1512

The avail_vcpu bitmap has to be allocated before it can be used (using
the maximum allowed value for that). Then for each available VCPU the
bit in the mask has to be set (libxl_bitmap_set takes a bit position
as an argument, not the number of bits to set).

Without this, I would always only get one VCPU for guests created
through libvirt/libxl.
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>

As we do for other errors with an extra string.

Otherwise libvirtd fails to load the lockd plugin.