Old versions of CIL did not understand the 'bool' data type,
but at least 1.7.3 does now cope. We can remove the old hack
which redefined bool and no longer compiles successfully.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently the virDBusAddWatch does

  virEventAddHandle(fd, flags,
                    virDBusWatchCallback,
                    watch, NULL);
  dbus_watch_set_data(watch, info, virDBusWatchFree);

Unfortunately this is racy - since the event loop is in a
different thread, the virDBusWatchCallback method may be
run before we get to calling dbus_watch_set_data. We must
reverse the order of these calls

See https://bugzilla.redhat.com/show_bug.cgi?id=885445Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Starting from commit 2e82c18c in Xen (will be included in Xen 4.4)
both libxl_get_max_cpus() and libxl_get_max_nodes() start returning
a proper libxl error code, in case of failure. This patch fixes
this in the libxl driver.

Note that, although it is now basically impossible for them to return
0, that would, theoretically, still be wrong. Also, checking that the
returned value is '<= 0' makes the code correct for both Xen 4.4 and
Xen 4.3 (and 4.2), and that is why we go for it (rather than
just '< 0').
Signed-off-by: NDario Faggioli <dario.faggioli@citrix.com>
Cc: Jim Fehlig <jfehlig@suse.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The undefine code that removes the storage along with the VM didn't take
into account the existence of 'volume' type disks. Add the functionality.

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

When undefining a VM with storage the man page doesn't explicitly
mention that the volumes need to be a part of the storage pool otherwise
it won't work.

On a system that is enforcing FIPS, most libraries honor the
current mode by default.  Qemu, on the other hand, refused to
honor FIPS mode unless you add the '-enable-fips' command
line option; worse, this option is not discoverable via QMP,
and is only present on binaries built for Linux.  So, if we
detect FIPS mode, then we unconditionally ask for FIPS; either
qemu is new enough to have the option and then correctly
cripple insecure VNC passwords, or it is so old that we are
correctly avoiding a FIPS violation by preventing qemu from
starting.  Meanwhile, if we don't detect FIPS mode, then
omitting the argument is safe whether the qemu has the option
(but it would do nothing because FIPS is disabled) or whether
qemu lacks the option (including in the case where we are not
running on Linux).

The testsuite was a bit interesting: we don't want our test
to depend on whether it is being run in FIPS mode, so I had
to tweak things to set the capability bit outside of our
normal interaction with capability parsing.

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1035474

* src/qemu/qemu_capabilities.h (QEMU_CAPS_ENABLE_FIPS): New bit.
* src/qemu/qemu_capabilities.c (virQEMUCapsInitQMP): Conditionally
set capability according to detection of FIPS mode.
* src/qemu/qemu_command.c (qemuBuildCommandLine): Use it.
* tests/qemucapabilitiestest.c (testQemuCaps): Conditionally set
capability to test expected output.
* tests/qemucapabilitiesdata/caps_1.2.2-1.caps: Update list.
* tests/qemucapabilitiesdata/caps_1.6.0-1.caps: Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

Our option '--with-test-suite' could have never worked since it was
defined as AC_ARG_ENABLE([with-test-suite], ...), thus working only as
'--enable-with-test-suite', but documented in configure.ac as
AC_HELP_STRING([--with-test-suite], ...).
In my opinion, the help string is as it should be, but the option is
wrong.

The option has been broken since the introduction in commit 3a2fc277.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Systemd specified that any /dev/pts/NNN device on which it
is expected to spawn a agetty login, should be listed in
the 'container_ttys' env variable. It should just contain
the relative paths, eg 'pts/0' not '/dev/pts/0' and should
be space separated.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d97ff7dd71902a5604c2fed8964925d54e09de9Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently, 'vol-resize --allocate' allocates new space at the
vol->capacity offset. But the vol->capacity is not necessarily the same
as vol->allocation. For instance:.

	[root@localhost ~]# virsh vol-list --pool tmp-pool --details
	 Name      Path                   Type  Capacity  Allocation
	-------------------------------------------------------------
	 tmp-vol  /root/tmp-pool/tmp-vol  file  1.00 GiB  1.00 GiB

	[root@localhost ~]# virsh vol-resize tmp-vol --pool tmp-pool 2G

	[root@localhost ~]# virsh vol-list --pool tmp-pool --details
	 Name      Path                   Type  Capacity  Allocation
	-------------------------------------------------------------
	 tmp-vol  /root/tmp-pool/tmp-vol  file  2.00 GiB  1.00 GiB

So, if we want to allocate more bytes, so the file is say 3G big, the
real allocated size is 2G actually:

	[root@localhost ~]# virsh vol-resize tmp-vol --pool tmp-pool 3G --allocate

	[root@localhost ~]# virsh vol-list --pool tmp-pool --details
	 Name      Path                   Type  Capacity  Allocation
	-------------------------------------------------------------
	 tmp-vol  /root/tmp-pool/tmp-vol  file  3.00 GiB  2.00 GiB

This commit uses the correct vol->allocation instead of incorrect
vol->capacity, so the output of the commands above looks like this:

	[root@localhost ~]# virsh vol-resize tmp-vol --pool tmp-pool 3G --allocate

	[root@localhost ~]# virsh vol-list --pool tmp-pool --details
	 Name      Path                   Type  Capacity  Allocation
	-------------------------------------------------------------
	 tmp-vol  /root/tmp-pool/tmp-vol  file  3.00 GiB  3.00 GiB

Moreover, if the '--alocate' flag was used, we must update the
vol->allocation member in storageVolResize API too, not just
vol->capacity.
Reported-by: NWang Sen <wangsen@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

vmx/vmx.c ignores the transient attribute on the disk xml format. This patch
adds a 1-1 relationship between it and [disk].mode = "independent-nonpersistent".

The other modes are ignored as before. It works in my testing.

https://bugzilla.redhat.com/show_bug.cgi?id=1044023Signed-off-by: NEric Blake <eblake@redhat.com>

As the python generator scripts are written in python2,
the ./configure script must check for python2 before checking for python
otherwise, on platforms where both python2 and python3 are available and
on which the default python points to python3, ./configure will try to use
the wrong one.
Signed-off-by: NLénaïc Huard <lenaic@lhuard.fr.eu.org>

Commit ff76566e moved around things in the specfiles to put
driver-specific files into their appropriate sub-packages (when
with_driver_modules == 1), but accidentally changed things so that the
deamon-driver-network and daemon-config-network files were only
included in a package when with_driver_modules == 0. This broke "make
rpm" on fedora (where with_driver_modules == 1).

This patch follows the pattern (already used for the files in other
sub-modules) of duplicating the files for the main package
(!with_driver_modules) and the sub-package (with_driver_modules).

Disks have type='drive', not type='disk'.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The URI parameter is optional and xen:/// is not the default connection
URI.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The newroot is not mounted as tmpfs, we bind root->src to it.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The event namespace concept is mostly redundant information.
With the re-written dispatcher, the namespace is only used
for equality comparisons between event IDs. This can be solved
by just comparing virClassPtr instances instead.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Instead of having the object event code have to know about each
type of event and their dispatch functions, associate a dispatch
function with the object instance. The dispatch code can thus be
significantly simplified.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Inject a virNetworkEvent class between virObjectEvent
and virNetworkEventLifecycle to mirror virDomainEvent.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

While the public API & wire protocol included the 'detail'
arg for network lifecycle events, the internal event handling
code did not process it. This meant that if a future libvirtd
server starts sending non-0 'detail' args, the current libvirt
client will not process them.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The domain events demo program isn't really tied to domain
events anymore, so rename it to object events.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

While running objecteventtest, it was found that valgrind pointed out the
following memory leak:

==13464== 5 bytes in 1 blocks are definitely lost in loss record 7 of 134
==13464==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==13464==    by 0x341F485E21: strdup (strdup.c:42)
==13464==    by 0x4CAE28F: virStrdup (virstring.c:554)
==13464==    by 0x4CF3CBE: virObjectEventCallbackListAddID (object_event.c:286)
==13464==    by 0x4CF49CA: virObjectEventStateRegisterID (object_event.c:729)
==13464==    by 0x4CF73FE: virDomainEventStateRegisterID (domain_event.c:1424)
==13464==    by 0x4D7358F: testConnectDomainEventRegisterAny (test_driver.c:6032)
==13464==    by 0x4D600C8: virConnectDomainEventRegisterAny (libvirt.c:19128)
==13464==    by 0x402409: testDomainStartStopEvent (objecteventtest.c:232)
==13464==    by 0x403451: virtTestRun (testutils.c:138)
==13464==    by 0x402012: mymain (objecteventtest.c:395)
==13464==    by 0x403AF2: virtTestMain (testutils.c:593)
==13464==

The support for <boot rebootTimeout="12345"/> was added before we were
checking for qemu command line options in QMP, so we haven't properly
adapted virQEMUCaps when using it and thus we report unsupported
option with new enough qemu.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1042690Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We missed a return when virProcessKillPainfully
failed to kill lxc process
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

Recent changes to events (commit 8a29ffcf) resulted in new compile
failures on some targets (such as ARM OMAP5):
conf/domain_event.c: In function 'virDomainEventDispatchDefaultFunc':
conf/domain_event.c:1198:30: error: cast increases required alignment of
target type [-Werror=cast-align]
conf/domain_event.c:1314:34: error: cast increases required alignment of
target type [-Werror=cast-align]
cc1: all warnings being treated as errors

The error is due to alignment; the base class is merely aligned
to the worst of 'int' and 'void*', while the child class must
be aligned to a 'long long'.  The solution is to include a
'long long' (and for good measure, a function pointer) in the
base class to ensure correct alignment regardless of what a
child class may add, but to wrap the inclusion in a union so
as to not incur any wasted space.  On a typical x86_64 platform,
the base class remains 16 bytes; on i686, the base class remains
12 bytes; and on the impacted ARM platform, the base class grows
from 12 bytes to 16 bytes due to the increase of alignment from
4 to 8 bytes.

Reported by Michele Paolino and others.

* src/util/virobject.h (_virObject): Use a union to ensure that
subclasses never have stricter alignment than the parent.
* src/util/virobject.c (virObjectNew, virObjectUnref)
(virObjectRef): Adjust clients.
* src/libvirt.c (virConnectRef, virDomainRef, virNetworkRef)
(virInterfaceRef, virStoragePoolRef, virStorageVolRef)
(virNodeDeviceRef, virSecretRef, virStreamRef, virNWFilterRef)
(virDomainSnapshotRef): Likewise.
* src/qemu/qemu_monitor.c (qemuMonitorOpenInternal)
(qemuMonitorClose): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

Map the new <panic> device in XML to the '-device pvpanic' command
line of qemu.  Clients can then couple the <panic> device and the
<on_crash> directive to control behavior when the guest reports
a panic to qemu.
Signed-off-by: NHu Tao <hutao@cn.fujitsu.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

panic device is a device that enables libvirt to receive notification
of guest panic event.
Signed-off-by: NEric Blake <eblake@redhat.com>

For example:
<address type='isa' iobase='0x505' irq='0x1'/>
Signed-off-by: NEric Blake <eblake@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NLaine Stump <laine@laine.org>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The throttle blkio cgroup will reuse this struct.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

virDomainBlkioDeviceWeightParseXML will be used to parse
the xml element read_bps, write_bps, read_iops, write_iops.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

Adding output to 'virsh --version=long' makes it easier to
tell if a distro built with particular libraries (it doesn't
tell you what a remote libvirtd is built with, but is still
better than nothing).  But we forgot to mention gluster.

* tools/virsh.c (vshShowVersion): Add gluster witness.
Signed-off-by: NEric Blake <eblake@redhat.com>

Hitting this should be pretty rare, but at least developers will know
that they are providing a weird event ID. Otherwise for namespace that
are added in the normal way, gcc will raise a warning about unhandled
case in the switch.