libvirtd is the new name of the init script in Debian testing.
libvirt-bin is still in use on Debian Wheezy.
Since I222b71962f49896063910ff2a25e4f57be4bf819, libvirtd is the
default for Debian, this break the compatibility with Debian Wheezy.
With this patch, we use libvirt-bin only if there is no
/etc/init.d/libvirtd init script.
Change-Id: I13694fef93d36c2e128e15e7dbfaec9230335585
this patch checks if os_VENDOR is ubuntu to launch
libvirt-bin service. Previously, is_ubuntu() was used, but
this function only detects if a deb packaging is used, so
there were no distinction between Ubuntu and Debian.
Change-Id: I222b71962f49896063910ff2a25e4f57be4bf819
Closes-Bug: 1361260
firewalld interacts badly with the libvirt on f20, causing slow-downs
so great that it can timeout the gate.
Developers who want to leave it enabled should set FORCE_FIREWALLD=True
Change-Id: I5252a12223a35f7fb7a4ac3c58aa4a3cd1bc4799
The libvirt log filter settings match against the filename of
the libvirt source emitting the log message. Normally these
file names are relative to the source tree root, but in the
Ubuntu binary packages these have somehow ended up as absolute
filenames from the OS root. This means that a log filter of
'1:libvirt' which is only intended to match src/libvirt.c
will in fact match every single file. This caused enourmous
log files on Ubuntu hosts running the gate.
The fix is to use '1:libvirt.c' as a more specific filename
match, but we can't do this unconditionally because libvirt
>= 1.2.3 does not use filenames for log filter matching
anymore. So only change the match on Ubuntu hosts for now,
since that's where the original problem lies.
While doing this, also turn off the logging of object ref
and unref operations, since those pollute the logs with lots
of noise.
Change-Id: I71b67507a4e68a7bff0c358857aaaac08ef0c420
The official F20 cloud image does not contains the firewalld,
there is nothing to restart, and it fails the installation.
The previous workaround change, assumed all is_fedoras has
a restartable firewalld without ensuring is it installed at all.
RHEL6 even does not have a firewalld.
Closes-bug: #1329102
Change-Id: I3d119ce48af81b30bf02b01c2cd386612ac6ef90
An updated libvirt package to address [1] is in Fedora 20 now, so we
don't need this work-around. Modify the comments of the other part of
the work-around (restart of services) and link to the most relevant
bug
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1098376
Change-Id: I47fba7b4f273162c2af1e37902a512041449750b
Fedora libvirtd fails to start on Xen instances (i.e. rackspace
instances) due to [1]. This works around the issue until it can be
fixed upstream.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1098376
Change-Id: I3790b5025982730263a6a84fce596e80f09efd5a
Since at least 12.04, the kvm package is a transitional dummy
package intended to move users to the newer qemu-kvm package. This
removes the dependency on this dummy package, which will be going away
in 14.04, and instead depends on the proper qemu-kvm package.
Change-Id: I4a88ada3cf32106413a9fae6fe77c9c4c28a524e
Closes-bug: #1294557
Moves installation and setup of libvirt to a common functions-libvirt,
which can be used by other drivers in the future that may require
cross-distro libvirt installation and config but are not using
VIRT_DRIVER=libvirt (ie, Ironic).
Change-Id: I4a9255c8b4bacd5acfde9b8061c9e537aeea592c
