libvirt-daemon-driver-XXX should be a dependency only when with_driver_modules
is 1.
libvirt-daemon-driver-libxl should be a dependency only when with_libxl is 1.
libvirt-daemon-driver-lxc should be a dependency only when with_lxc is 1.
libvirt-daemon-driver-qemu should be a dependency only when with_qemu is 1.
libvirt-daemon-driver-uml should be a dependency only when with_uml is 1.
libvirt-daemon-driver-xen should be a dependency only when with_xen is 1.
Turning on the building of driver modules in libvirt.spec.in
means that installing 'libvirt' no longer pulls in all the
drivers. For upgrade compatibility we need to list all drivers
module sub-RPMs against the 'libvirt' RPM.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch brings support to manage sheepdog pools and volumes to libvirt.
It uses the "collie" command-line utility that comes with sheepdog for that.
A sheepdog pool in libvirt maps to a sheepdog cluster.
It needs a host and port to connect to, which in most cases
is just going to be the default of localhost on port 7000.
A sheepdog volume in libvirt maps to a sheepdog vdi.
To create one specify the pool, a name and the capacity.
Volumes can also be resized later.
In the volume XML the vdi name has to be put into the <target><path>.
To use the volume as a disk source for virtual machines specify
the vdi name as "name" attribute of the <source>.
The host and port information from the pool are specified inside the host tag.
<disk type='network'>
...
<source protocol="sheepdog" name="vdi_name">
<host name="localhost" port="7000"/>
</source>
</disk>
To work right this patch parses the output of collie,
so it relies on the raw output option. There recently was a bug which caused
size information to be reported wrong. This is fixed upstream already and
will be in the next release.
Signed-off-by: Sebastian Wiedenroth <wiedi@frubar.net>
Apart from the non-sanlock check build, there is also a little fix for
qemu (EXTRA_DIST had qemu.conf and others inside even if the build was
supposed to be without qemu).
Turn on loadable modules for libvirtd. Add new sub-RPMs
libvirt-daemon-driver-XXX, one for each loadable .so.
Modify the libvirt-daemon-YYY RPMs to depend on each of
the individual drivers they required
* libvirt.spec.in: Enable driver modules
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch adds support for a new storage backend with RBD support.
RBD is the RADOS Block Device and is part of the Ceph distributed storage
system.
It comes in two flavours: Qemu-RBD and Kernel RBD, this storage backend only
supports Qemu-RBD, thus limiting the use of this storage driver to Qemu only.
To function this backend relies on librbd and librados being present on the
local system.
The backend also supports Cephx authentication for safe authentication with
the Ceph cluster.
For storing credentials it uses the built-in secret mechanism of libvirt.
Signed-off-by: Wido den Hollander <wido@widodh.nl>
Introduce a set sub-RPMs, one per hypervisor, which can be used
as dependency targets by applications wishing to pull in the
full stack of packages required for a specific hypervisor. This
avoids the application needing to know what the hypervisor specific
package set is.
ie, applications should not need to know that using the libvirt
Xen hypervisor requires the 'xen' RPM - libvirt should take care
of that knowledge. All the application wants is 'libvirt-daemon-xen'
There are 5 sub-RPMs:
libvirt-daemon-qemu - non-native TCG based emulators
libvirt-daemon-kvm - native KVM hypervisor
libvirt-daemon-uml - User Mode linux
libvirt-daemon-xen - Xen, either via XenD or libxl
libvirt-daemon-lxc - Linux native containers
When driver modules get turned on, these sub-RPMs will also
gain dependencies on the appropriate driver module .so files
Take the libvirt RPM and split it into three pieces
- libvirt-daemon - libvirtd & other mandatory bits for its operation
- libvirt-daemon-config-network - the virbr0 config definition
- libvirt-daemon-config-nwfilter - the firewall config rules
For backwards compatibility with existing installs / application RPM
deps, the 'libvirt' RPM is retained, but will have a dependency on
the 3 new RPMs.
Currently documentation is split between the libvirt RPM and the
libvirt-devel RPM. In the client-only build there is no libvirt
RPM, so the docs need to live elsewhere. The obvious answer is a
dedicated libvirt-docs RPM. For back-compatibility make the
libvirt-devel RPM require the libvirt-docs RPM
* libvirt.spec.in: Create separate libvirt-docs RPM
* configure.ac docs/news.html.in libvirt.spec.in: update for the release
* po/*.po*: updated a number of languages translation including new
indian languages and regenerated
* libvirt.spec.in: Remove obsolete --with-remote-pid-file arg.
Add missing %{without_libxl} statement. Fix handling of docs
in client only build. Put systemtap files in -client RPM
instead of -daemon RPM
* examples/xml/nwfilter/Makefile.am: Don't install examples if
nwfilter is disabled.
There are a number of flaws with our packaging of the libvirtd
daemon:
- Installing 'libvirt' does not install 'qemu-kvm' or 'xen'
etc which are required to actually run the hypervisor in
question
- Installing 'libvirt' pulls in the default configuration
files which may not be wanted & cause problems if installed
inside a guest
- It is not possible to explicitly required all the peices
required to manage a specific hypervisor
This change takes the 'libvirt' RPM and and changes it thus
- libvirt: just a virtual package with dep on libvirt-daemon,
libvirt-daemon-config-network & libvirt-daemon-config-nwfilter
- libvirt-daemon: the libvirt daemon and related pieces
- libvirt-daemon-config-network: the default network config
- libvirt-daemon-config-nwfilter: the network filter configs
- libvirt-docs: the website HTML
We then introduce some more virtual (empty) packages
- libvirt-daemon-qemu: Deps on libvirt-daemon & 'qemu'
- libvirt-daemon-kvm: Deps on libvirt-daemon & 'qemu-kvm'
- libvirt-daemon-lxc: Deps on libvirt-daemon
- libvirt-daemon-uml: Deps on libvirt-daemon
- libvirt-daemon-xen: Deps on libvirt-daemon & 'xen'
- libvirt-qemu: Deps on libvirt-daemon-qemu & libvirt-daemon-config-{network,nwfilter}
- libvirt-kvm: Deps on libvirt-daemon-kvm & libvirt-daemon-config-{network,nwfilter}
- libvirt-lxc: Deps on libvirt-daemon-lxc & libvirt-daemon-config-{network,nwfilter}
- libvirt-uml: Deps on libvirt-daemon-uml & libvirt-daemon-config-{network,nwfilter}
- libvirt-xen: Deps on libvirt-daemon-xen & libvirt-daemon-config-network
My intent in the future is to turn on the driver modules by
default, at which time 'libvirt-daemon' will cease to include
any specific drivers, instead we'll get libvirt-daemon-driver-XXXX
packages for each driver. The libvirt-daemon-XXX packages will
then pull in each driver that they require.
It is recommended that applications required a locally installed
libvirtd daemon, use either 'Requires: libvirt-daemon-XXXX' or
'Requires: libvirt-XXX' and *not* "Requires: libvirt-daemon"
or 'Requires: libvirt'
* libvirt.spec.in: Refactor RPMs
* docs/packaging.html.in, docs/sitemap.html.in: Document
new RPM split rationale
After adding the libvirt-guests service into usual runlevels, we used
to start the libvirt-guests service. However this is usually not a
good practice. As mentioned on fedoraproject wiki, the installations
can be in changeroots, in an installer context, or in other situations
where we don't want the services autostarted.
Currently, if scrub (used for wiping algorithms) is not present
at compile time, we don't support any other wiping algorithms than
zeroing, even if it was installed later. Switch to runtime detection
instead.
Language bindings may well want to use the libvirt-api.xml and
libvirt-qemu-api.xml files to either auto-generate themselves,
or sanity check the manually written bindings for completeness.
Currently these XML files are not installed as standard, merely
ending up as a %doc file in the RPM.
This changes them to be installed into $prefix/share/libvirt/apis/
The *-refs.xml files are not installed, since those are only
useful during generation of the online API doc files.
The pkg-config file is enhanced so that you can query the install
location of the API files. eg
# pkg-config --variable=libvirt_qemu_api libvirt
/home/berrange/builder/i686-pc-mingw32/sys-root/mingw/share/libvirt/libvirt-qemu-api.xml
* docs/Makefile.am: Install libvirt-api.xml & libvirt-qemu-api.xml
* libvirt.pc.in: Add vars for querying API install location
* libvirt.spec.in, mingw32-libvirt.spec.in: Include API XML files
See: https://bugzilla.redhat.com/show_bug.cgi?id=785269
The specfile requires avahi during install if libvirt was built with
avahi support, but there are many situations where it is undesirable
to install avahi due to security concerns. This patch requires only
the avahi-libs package, which is needed by libvirt to call the
function that tries to attach to the avahi daemon, but will instead
silently fail because the avahi-daemon is in the main avahi package,
and that package isn't installed.
To assist people in verifying that their host is operating in an
optimal manner, provide a 'virt-host-validate' command. For each
type of hypervisor, it will check any pre-requisites, or other
good recommendations and report what's working & what is not.
eg
# virt-host-validate
QEMU: Checking for device /dev/kvm : FAIL (Check that the 'kvm-intel' or 'kvm-amd' modules are loaded & the BIOS has enabled virtualization)
QEMU: Checking for device /dev/vhost : WARN (Load the 'vhost_net' module to improve performance of virtio networking)
QEMU: Checking for device /dev/net/tun : PASS
LXC: Checking for Linux >= 2.6.26 : PASS
This warns people if they have vmx/svm, but don't have /dev/kvm. It
also warns about missing /dev/vhost net.
Commit d336dbdb tried to refactor sanlock to avoid building it
on RHEL for architectures where it is not available, but used
the wrong conditional.
* libvirt.spec.in (with_sanlock): Use %ifarch, not %ifnarch.
https://bugzilla.redhat.com/show_bug.cgi?id=738725
Commit ecd8725 tried to silence a spurious warning on the initial
libvirt install, and commit ba6cbb1 tried to fix up the logic to the
correct Fedora version, but the warning was still present due to a
logic bug: since %{fedora} and %{rhel} are never simulatanously
set, then 0%{rhel} <= 6 made the %if always true. Checking for
minimum versions (via >=) is okay, but checking for maximum versions
(via <=) requires a prerequisite test that the platform being tested
is non-zero.
Also fix a bogus setting of with_libxl (although we previously
hard-code with_libxl to 0 for rhel earlier in the file, so this
was not as severe a bug).
* libvirt.spec.in (with_cgconfig): Don't enable cgconfig on F16.
Over time, Fedora and RHEL RPMs have often backported upstream
patches that touched configure.ac and/or Makefile.am; this
necessitates rerunning the autotools for the patch to be effective.
Making this a one-liner spec tweak will make it easier for future
backports to pull patches without having to find all the places
to touch to properly use the autotools. Meanwhile, there have been
historical instances where an update in the autotools caused FTBFS
situations, so this is not on by default.
* libvirt.spec.in (enable_autotools): New variable, default off.
(BuildRequires): Conditionally add autotools.
(%build): Conditionally use them before configure.
* mingw32-libvirt.spec.in: Likewise.
The %makeinstall macro does not set DESTDIR, instead of explicitly
prefixes %{buildroot} onto all paths. Thus we need to do the same
when setting the systemd unit dir
* libvirt.spec.in: Prefix %{buildroot} onto %{unitdir}
https://bugzilla.redhat.com/show_bug.cgi?id=694403 reports that
the specfile is incorrectly checking for a running libvirt-guests
service. For example,
$ LC_ALL=es_ES chkconfig --list libvirt-guests
libvirt-guests 0:desactivado 1:desactivado 2:desactivado 3:activo 4:activo 5:activo 6:desactivado
will fail to find 5:on, even though it is active. But chkconfig
already has a mode where you can silently use the exit status to
check for an active service.
* libvirt.spec.in (%post): Use simpler chkconfig options, to avoid
issues with localization.
https://bugzilla.redhat.com/show_bug.cgi?id=754909 complains that
because libvirt didn't require dmidecode, that the logs are noisy
and virConnectGetSysinfo needlessly fails. Even 'virt-what' requires
dmidecode, so it's not that onerous of a dependency. We may be
able to drop this in the future when we move to parsing sysfs data,
but for now, listing the dependency will help matters.
* libvirt.spec.in (Requires): Sort Requires before BuildRequires.
Add dmidecode.
We have several directories that are created on the fly, and which
only contain state relevant to a running libvirtd process (all
located in /var/run). Since the directories are created as needed,
and make no sense without a running libvirtd, we want them deleted
if libvirt is uninstalled. And in F15 and newer, /var/run is on
tmpfs (forcing us to recreate on the fly); which means that someone
trying to verify a complete rpm will fail if the directory does not
currently exist because libvirtd has not been started since boot.
The solution, then, is to mark the directories as %ghost, so that
rpm knows that we own them and will clean it up if libvirt is
uninstalled, but will no longer create the directory for us at
install, nor complain at verify time if the directory does not exist.
See https://bugzilla.redhat.com/show_bug.cgi?id=656611.
* libvirt.spec.in (%files): Add %ghost to temporary directories
that we don't install, but want cleaned up on libvirt removal.
This patch exports KVM Host Power Management capabilities as XML so that
higher-level systems management software can make use of these features
available in the host.
The script "pm-is-supported" (from pm-utils package) is run to discover if
Suspend-to-RAM (S3) or Suspend-to-Disk (S4) is supported by the host.
If either of them are supported, then a new tag "<power_management>" is
introduced in the XML under the <host> tag.
However in case the query to check for power management features succeeded,
but the host does not support any such feature, then the XML will contain
an empty <power_management/> tag. In the event that the PM query itself
failed, the XML will not contain any "power_management" tag.
To use this, new APIs could be implemented in libvirt to exploit power
management features such as S3/S4.
This patch adds support for a systemd init service for libvirtd
and libvirt-guests. The libvirtd.service is *not* written to use
socket activation, since we want libvirtd to start on boot so it
can do guest auto-start.
The libvirt-guests.service is pretty lame, just exec'ing the
original init script for now. Ideally we would factor out the
functionality, into some shared tool.
Instead of
./configure --with-init-script=redhat
You can now do
./configure --with-init-script=systemd
Or better still:
./configure --with-init-script=systemd+redhat
We can also now support install of the upstart init script
* configure.ac: Add systemd, and systemd+redhat options to
--with-init-script option
* daemon/Makefile.am: Install systemd services
* daemon/libvirtd.sysconf: Add note about unused env variable
with systemd
* daemon/libvirtd.service.in: libvirtd systemd service unit
* libvirt.spec.in: Add scripts to installing systemd services
and migrating from legacy init scripts
* tools/Makefile.am: Install systemd services
* tools/libvirt-guests.init.sh: Rename to tools/libvirt-guests.init.in
* tools/libvirt-guests.service.in: systemd service unit
Convert the virNetDevBridgeSetSTP and virNetDevBridgeSetSTPDelay
to use ioctls instead of spawning brctl.
Implement the virNetDevBridgeGetSTP and virNetDevBridgeGetSTPDelay
methods which were declared in the header but never existed
* src/util/bridge.c: Convert to use bridge ioctls instead of brctl
We already have a /var/lib/libvirt/images for OS install images.
We need a separate /var/lib/libvirt/filesystems for OS install
trees, since SELinux labelling will be different
* libvirt.spec.in: Add /var/lib/libvirt/filesystems
* src/Makefile.am: Create /var/lib/libvirt/filesystems
This adds support for a libvirt client configuration file
either /etc/libvirt/libvirt.conf for privileged clients,
or $HOME/.libvirt/libvirt.conf for unprivileged clients.
It allows one parameter
uri_aliases = [
"hail=qemu+ssh://root@hail.cloud.example.com/system",
"sleet=qemu+ssh://root@sleet.cloud.example.com/system",
]
Any call to virConnectOpen with a non-NULL URI will first
attempt to match against the uri_aliases list. An application
can disable this by using VIR_CONNECT_NO_ALIASES
* docs/uri.html.in: Document URI aliases
* include/libvirt/libvirt.h.in: Add VIR_CONNECT_NO_ALIASES
* libvirt.spec.in, mingw32-libvirt.spec.in: Add /etc/libvirt/libvirt.conf
* src/Makefile.am: Install default config file
* src/libvirt.c: Add support for URI aliases
* src/remote/remote_driver.c: Don't try to handle URIs
with no scheme and which clearly are not paths
* src/util/conf.c: Don't raise error on virConfFree(NULL)
* src/xen/xen_driver.c: Don't raise error on URIs
with no scheme
* libvirt.spec.in (%configure): Drop unused %{one} macro.
* mingw32-libvirt.spec.in (%{rhel}): Compile ESX but not HyperV on
mingw build for RHEL.
(%build): Make configure honor spec conditionals. Reorder to
match libvirt.spec.
* autobuild.sh (mingw): Update list to match.
Suggested by Daniel P. Berrange.
when building libvirt in Fedora/s390x I've found that xenlight needs to
be explicitly disabled in the spec file. Configure properly sets the
library as non-existent, but the %files section still wants to package
the 3 /var/*/libvirt/libxl directories. See also
https://bugzilla.redhat.com/show_bug.cgi?id=745020
https://bugzilla.redhat.com/show_bug.cgi?id=740899 documents that
if qemu uses aio=native for its disks, then it consumes 128 aio
requests per disk. On a host with multiple guests, this can quickly
run out of kernel aio requests with the default aio-max-nr of
65536. Kernel developers have confirmed that there is no up-front
cost to raising this limit (a larger limit merely implies that more
aio requests can be issued in parallel, which in turn will result
in more kernel memory allocation, only if the system really does use
that many requests). Since the system default limit prevents 256
disks, which is well within libvirt's current scalability, this
patch installs a file to raise the limit and document it in case a
system administrator has further cause to tune the limit. The
install only works on platforms new enough to source /etc/sysctl.d/*
alongside /etc/sysctl.conf (F14 and RHEL 6).
* daemon/libvirtd.sysctl: New file.
* daemon/Makefile.am (EXTRA_DIST): Ship it.
(install-init, uninstall-init): Install it.
* libvirt.spec.in (%files): Include it in rpm.
Commit ecd8725c dropped attempts to probe the cgconfig service on
new enough Fedora where systemd took over that aspect of the system,
but mistakenly used F14 instead of F15 as the cutoff point.
https://bugzilla.redhat.com/show_bug.cgi?id=741358
Also, RHEL does not include HyperV support yet.
* libvirt.spec.in (with_cgconfig): Check cgconfig service in F15.
(%{?rhel}): Provide default for with_hyperv.
Inexplicably the sanlock code all got placed under the GPLv2-only,
so libvirt's use of sanlock introduces a license incompatibility.
The sanlock developers have now rearranged the code such that there
is a 'sanlock_client.so' which is LGPLv2+ while their daemon remains
GPLv2-only. To use the new client library we need to call the new
sanlock_init and sanlock_align APIs instead of sanlock_direct_init
and sanlock_direct_align. These APIs calls are now routed via the
sanlock daemon, instead of doing direct I/O calls to disk.
For all this we require sanlock >= 1.8
* configure.ac: Check for sanlock_client.so instead of sanlock.so
and fix various comments
* libvirt.spec.in: Mandate sanlock >= 1.8
* src/Makefile.am: Link to -lsanlock_client
* src/locking/lock_driver_sanlock.c: Use sanlock_init and
sanlock_align
https://bugzilla.redhat.com/show_bug.cgi?id=738725 documents that
'yum install libvirt' in Fedora 16 is rather noisy. This fixes
the problems.
* libvirt.spec.in (%post client): Silence chkconfig warning about
SysV services.
(%post) [with_cgconfig]: Drop for Fedora 15 and newer, where
systemd does this automatically.
This patch will probably cause merge conflicts to those trying
to do backports. The end goal is simple - domaincommon.rng
should be the state of domain.rng pre-patch, with a few lines
tweaked in the header, while domain.rng post-patch is now just
a shell that includes domaincommon.rng and sets the <start>.
* docs/schemas/domain.rng: Move guts...
* docs/schemas/domaincommon.rng: ...to new file.
* docs/schemas/domainsnapshot.rng: Allow new xml.
* docs/schemas/Makefile.am (schema_DATA): Distribute new file.
* tests/domainsnapshotxml2xmlout/full_domain.xml: New test.
* libvirt.spec.in (%files client): Ship new file. Sort lines.
* mingw32-libvirt.spec.in: Likewise.
* configure.ac docs/news.html.in libvirt.spec.in: updates for new
release
* po/*.po*: pulled translations from the transifex teams and regenerated
localizations
The sanlock plugin for libvirt expects the directory
/var/lib/libvirt/sanlock to exist. Create this and add
it to the RPM
* libvirt.spec.in: Add /var/lib/libvirt/sanlock
* src/Makefile.am: Create /var/lib/libvirt/sanlock
virtPortProfiles are currently only used in the domain XML, but will
soon also be used in the network XML. To prepare for that change, this
patch moves the structure definition into util/network.h and the parse
and format functions into util/network.c (I decided that this was a
better choice than macvtap.h/c for something that needed to always be
available on all platforms).
We disable some drivers when building without libvirtd in configure,
but we do not do the same thing in libvirt.spec. It may break rpm
building without libvirtd.
domain.rng, network.rng, and interface.rng already use a few of the
same types (or in some cases *should* but don't), and an upcoming code
change will have them sharing even more. To prepare for that, this
patch takes those common data type definitions and moves them into
basictypes.rng.
This may break some rule about the need to RNG files to be autonomous
or something, but I saw that storageencryption.rng is used in this
way, so I figured it must not be completely against the law...
The current sanlock plugin requires a central management
application to manually add <lease> elements to each guest,
to protect resources that are assigned to it (eg writable
disks). This makes the sanlock plugin useless for usage
in more ad hoc deployment environments where there is no
central authority to associate disks with leases.
This patch adds a mode where the sanlock plugin will
automatically create leases for each assigned read-write
disk, using a md5 checksum of the fully qualified disk
path. This can work pretty well if guests are using
stable disk paths for block devices eg /dev/disk/by-path/XXXX
symlinks, or if all hosts have NFS volumes mounted in
a consistent pattern.
The plugin will create one lockspace for managing disks
with filename /var/lib/libvirt/sanlock/__LIBVIRT__DISKS__.
For each VM disks, there will be another file to hold
a lease /var/lib/libvirt/sanlock/5903e5d25e087e60a20fe4566fab41fd
Each VM disk lease is usually 1 MB in size. The script
virt-sanlock-cleanup should be run periodically to remove
unused lease files from the lockspace directory.
To make use of this capability the admin will need to do
several tasks:
- Mount an NFS volume (or other shared filesystem)
on /var/lib/libvirt/sanlock
- Configure 'host_id' in /etc/libvirt/qemu-sanlock.conf
with a unique value for each host with the same NFS
mount
- Toggle the 'auto_disk_leases' parameter in qemu-sanlock.conf
Technically the first step can be skipped, in which case
sanlock will only protect against 2 vms on the same host
using the same disk (or the same VM being started twice
due to error by libvirt).
* src/locking/libvirt_sanlock.aug,
src/locking/sanlock.conf,
src/locking/test_libvirt_sanlock.aug: Add config params
for configuring auto lease setup
* libvirt.spec.in: Add virt-sanlock-cleanup program, man
page
* tools/virt-sanlock-cleanup.in: Script to purge unused
disk resource lease files
Introduce a configuration file with a single parameter
'require_lease_for_disks', which is used to decide whether
it is allowed to start a guest which has read/write disks,
but without any leases.
* libvirt.spec.in: Add sanlock config file and augeas
lens
* src/Makefile.am: Install sanlock config file and
augeas lens
* src/locking/libvirt_sanlock.aug: Augeas master lens
* src/locking/test_libvirt_sanlock.aug: Augeas test file
* src/locking/sanlock.conf: Example sanlock config
* src/locking/lock_driver_sanlock.c: Wire up loading
of configuration file
When building rpms for newer Fedora or RHEL, take advantage of the
newer netcf packaging to guarantee interface snapshot support.
* libvirt.spec.in (BuildRequires): Bump minimum version on
platforms that support netcf 0.1.8.
Sanlock is a project that implements a disk-paxos locking
algorithm. This is suitable for cluster deployments with
shared storage.
* src/Makefile.am: Add dlopen plugin for sanlock
* src/locking/lock_driver_sanlock.c: Sanlock driver
* configure.ac: Check for sanlock
* libvirt.spec.in: Add a libvirt-lock-sanlock RPM
* configure.ac libvirt.spec.in docs/news.html.in: update and document
the release
* po/*.po*: update localizations for german, polish, spanish, ukrainian
and vietnamese coming from transifex, regenerate
To install it, disable libvirtd sysv initscript:
chkconfig libvirtd off
service libvirtd stop
and enable libvirtd upstart job:
cp /usr/share/doc/libvirt-*/libvirtd.upstart \
/etc/init/libvirtd.conf
initctl reload-configuration
initctl start libvirtd
Test:
initctl status libvirtd
libvirtd start/running, process 3929
killall -9 libvirtd
initctl status libvirtd
libvirtd start/running, process 4047
I looked into the possibility to use the upstart script from Ubuntu or
at least getting inspiration from it but that's not possible. "expect
daemon" is a nice thing but it only works if the process is defined with
exec stanza instead of script ... no script. Unfortunately, with exec
stanza environment variables can only be set within upstart script
(i.e., configuration in /etc/sysconfig/libvirtd can't work). Hence, we
need to use script stanza, source sysconfig, and execute libvirtd
without --daemon. For similar reasons we can't use limit stanza and need
to handle DAEMON_COREFILE_LIMIT in job's script.
The systemtap directory for tapsets is called
/usr/share/systemtap/tapset
Not
/usr/share/systemtap/tapsets
* daemon/Makefile.am,libvirt.spec.in: s/tapsets/tapset/
The Open Nebula driver has been unmaintained since it was first
introduced. The only commits have been for tree-wide cleanups.
It also has a major design flaw, in that it only knows about guests
that it has created itself, which makes it of very limited use.
Discussions wrt evolution of the VMWare ESX driver, concluded that
it should limit itself to single-node ESX operation and not try to
manage the multi-node architecture of VirtualCenter. Open Nebula
is a cluster like Virtual Center, not a single node system, so
the same reasoning applies.
The DeltaCloud project includes an Open Nebula driver and is a much
better fit architecturally, since it is explicitly targetting the
distributed multihost cluster scenario.
Thus this patch deletes the libvirt Open Nebula driver with the
recommendation that people use DeltaCloud for managing it instead.
* configure.ac: Remove probe for xmlrpc & --with-one arg
* daemon/Makefile.am, daemon/libvirtd.c, src/Makefile.am: Remove
ONE driver build
* src/opennebula/one_client.c, src/opennebula/one_client.h,
src/opennebula/one_conf.c, src/opennebula/one_conf.h,
src/opennebula/one_driver.c, src/opennebula/one_driver.c: Delete
files
* autobuild.sh, libvirt.spec.in, mingw32-libvirt.spec.in: Remove
build rules for Open Nebula
* docs/drivers.html.in, docs/sitemap.html.in: Remove reference
to OpenNebula
* docs/drvone.html.in: Delete file
Among others, the missing radvd dependency showed up as:
error: Failed to start network ipv6net
error: Cannot find radvd - Possibly the package isn't installed: No such file
or directory
even when radvd was installed, because the RADVD preprocessor
symbol was missing at configure time.
* libvirt.spec.in (with_network): Add BuildRequires for radvd,
iptables, and ip6tables.
(BuildRequires): Add libxslt and augeas for docs and test.
(with_libvirtd): Add module-init-tools for modprobe.
(with_nwfilter): Add BuildRequires for ebtables.
(with_esx): Fix esx build on RHEL 5, thanks to curl-devel rename.
Add a new xen driver based on libxenlight [1], which is the primary
toolstack starting with Xen 4.1.0. The driver is stateful and runs
privileged only.
Like the existing xen-unified driver, the libxenlight driver is
accessed with xen:// URI. Driver selection is based on the status
of xend. If xend is running, the libxenlight driver will not load
and xen:// connections are handled by xen-unified. If xend is not
running *and* the libxenlight driver is available, xen://
connections are deferred to the libxenlight driver.
V6:
- Address several code style issues noted by Daniel Veillard
- Make drive work with xen:/// URI
- Hold domain object reference while domain is injected in
libvirt event loop. Race found and fixed by Markus Groß.
V5:
- Ensure events are unregistered when domain private data
is destroyed. Discovered and fixed by Markus Groß.
V4:
- Handle restart of libvirtd, reconnecting to previously
started domains
- Rebased to current master
- Tested against Xen 4.1 RC7-pre (c/s 22961:c5d121fd35c0)
V3:
- Reserve vnc port within driver when autoport=yes
V2:
- Update to Xen 4.1 RC6-pre (c/s 22940:5a4710640f81)
- Rebased to current master
- Plug memory leaks found by Stefano Stabellini and valgrind
- Handle SHUTDOWN_crash domain death event
[1] http://lists.xensource.com/archives/html/xen-devel/2009-11/msg00436.html
When building for an older distro, it's convenient to just
tell rpmbuild to define dist (for example, to .el6_0), rather
than also remembering to define rhel to 6.
* libvirt.spec.in: Guess %{rhel} based on %{dist}.
Based on an idea by Jiri Denemark.
As the file may grow quite a bit especially with debug turned on.
* daemon/libvirtd.logrotate.in daemon/Makefile.am libvirt.spec.in:
add new logrotate file for the daemon log
libvirt-guests invokes functions in gettext.sh, so we need to
require gettext package in spec file.
Demo with the fix:
% rpm -q gettext
package gettext is not installed
% rpm -ivh libvirt-client-0.8.8-1.fc14.x86_64.rpm
error: Failed dependencies:
gettext is needed by libvirt-client-0.8.8-1.fc14.x86_64
* libvirt.spec.in
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=609463
The problem was that, since a bridge always acquires the MAC address
of the connected interface with the numerically lowest MAC, as guests
are started and stopped, it was possible for the MAC address to change
over time, and this change in the network was being detected by
Windows 7 (it sees the MAC of the default route change), so on each
reboot it would bring up a dialog box asking about this "new network".
The solution is to create a dummy tap interface with a MAC guaranteed
to be lower than any guest interface's MAC, and attach that tap to the
bridge as soon as it's created. Since all guest MAC addresses start
with 0xFE, we can just generate a MAC with the standard "0x52, 0x54,
0" prefix, and it's guaranteed to always win (physical interfaces are
never connected to these bridges, so we don't need to worry about
competing numerically with them).
Note that the dummy tap is never set to IFF_UP state - that's not
necessary in order for the bridge to take its MAC, and not setting it
to UP eliminates the clutter of having an (eg) "virbr0-nic" displayed
in the output of the ifconfig command.
I chose to not auto-generate the MAC address in the network XML
parser, as there are likely to be consumers of that API that don't
need or want to have a MAC address associated with the
bridge.
Instead, in bridge_driver.c when the network is being defined, if
there is no MAC, one is generated. To account for virtual network
configs that already exist when upgrading from an older version of
libvirt, I've added a %post script to the specfile that searches for
all network definitions in both the config directory
(/etc/libvirt/qemu/networks) and the state directory
(/var/lib/libvirt/network) that are missing a mac address, generates a
random address, and adds it to the config (and a matching address to
the state file, if there is one).
docs/formatnetwork.html.in: document <mac address.../>
docs/schemas/network.rng: add nac address to schema
libvirt.spec.in: %post script to update existing networks
src/conf/network_conf.[ch]: parse and format <mac address.../>
src/libvirt_private.syms: export a couple private symbols we need
src/network/bridge_driver.c:
auto-generate mac address when needed,
create dummy interface if mac address is present.
tests/networkxml2xmlin/isolated-network.xml
tests/networkxml2xmlin/routed-network.xml
tests/networkxml2xmlout/isolated-network.xml
tests/networkxml2xmlout/routed-network.xml: add mac address to some tests
The name convention of device mapper disk is different, and 'parted'
can't be used to delete a device mapper disk partition. e.g.
Name Path
-----------------------------------------
3600a0b80005ad1d7000093604cae912fp1 /dev/mapper/3600a0b80005ad1d7000093604cae912fp1
Error: Expecting a partition number.
This patch introduces 'dmsetup' to fix it.
Changes:
- New function "virIsDevMapperDevice" in "src/utils/utils.c"
- remove "is_dm_device" in "src/storage/parthelper.c", use
"virIsDevMapperDevice" instead.
- Requires "device-mapper" for 'with-storage-disk" in "libvirt.spec.in"
- Check "dmsetup" in 'configure.ac' for "with-storage-disk"
- Changes on "src/Makefile.am" to link against libdevmapper
- New entry for "virIsDevMapperDevice" in "src/libvirt_private.syms"
Changes from v1 to v3:
- s/virIsDeviceMapperDevice/virIsDevMapperDevice/g
- replace "virRun" with "virCommand"
- sort the list of util functions in "libvirt_private.syms"
- ATTRIBUTE_NONNULL(1) for virIsDevMapperDevice declaration.
e.g.
Name Path
-----------------------------------------
3600a0b80005ad1d7000093604cae912fp1 /dev/mapper/3600a0b80005ad1d7000093604cae912fp1
Vol /dev/mapper/3600a0b80005ad1d7000093604cae912fp1 deleted
Name Path
-----------------------------------------
* configure.ac docs/news.html.in libvirt.spec.in: bump version and add docs
* po/*.po*: updated Gujarati, Polish and Dutch localisations and regenerated
The logging functions are enhanced so that immediately prior to
the first log message being printed to any output channel, the
libvirt package version will be printed.
eg
$ LIBVIRT_DEBUG=1 virsh
18:13:28.013: 17536: info : libvirt version: 0.8.7
18:13:28.013: 17536: debug : virInitialize:361 : register drivers
...
The 'configure' script gains two new arguments which can be
used as
--with-packager="Fedora Project, x86-01.phx2.fedoraproject.org, 01-27-2011-18:00:10"
--with-packager-version="1.fc14"
to allow distros to append a custom string with package specific
data.
The RPM specfile is modified so that it appends the RPM version,
the build host, the build date and the packager name.
eg
$ LIBVIRT_DEBUG=1 virsh
18:14:52.086: 17551: info : libvirt version: 0.8.7, package: 1.fc13 (Fedora Project, x86-01.phx2.fedoraproject.org, 01-27-2011-18:00:10)
18:14:52.086: 17551: debug : virInitialize:361 : register drivers
Thus when distro packagers receive bug reports they can clearly
see what version was in use, even if the bug reporter mistakenly
or intentionally lies about version/builds
* src/util/logging.c: Output version data prior to first log message
* libvirt.spec.in: Include RPM release, date, hostname & packager
* configure.ac: Add --with-packager & --with-packager-version args
When I build libvirt without libvirtd, I receive some errors:
cp: cannot stat `/home/wency/rpmbuild/BUILDROOT/libvirt-0.8.6-1.el6.x86_64/etc/libvirt/qemu/networks/default.xml': No such file or directory
My build step:
# ./autogen.sh --without-libvirtd
# make dist
# rpmbuild --nodeps --define "_sourcedir `pwd`" --define "_without_libvirtd 1" -ba libvirt.spec
The reason is we disable network when we do not build libvirt daemon in configure.ac.
After fixing this bug, I build libvirt without libvirtd, I receive other errors:
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/share/doc/libvirt-0.8.6/html/32favicon.png
/usr/share/doc/libvirt-0.8.6/html/api.html
..
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
A number of the libvirt APIs require the use of cgroups. This is not
enabled by default on a RHEL6 install. After discussion with cgroups
team, it was decided that upon installation of the libvirt RPM, we
should automatically turn on the cgroups service. This will activate a
default configuration that turns on all cgroups controllers libvirt
requires for full operation.
https://bugzilla.redhat.com/show_bug.cgi?id=649511
Regression of forcing 0700 permissions (which breaks guest startup
because the qemu user can't see /var/lib/libvirt/*.monitor) was
introduced in commit 66823690e, as part of libvirt 0.8.2.
* libvirt.spec.in (%files): Drop %{_localstatedir}/lib/libvirt,
since libvirt depends on libvirt-client.
(%files client): Guarantee 755 permissions on
%(_localstatedir}/lib/libvirt, since the qemu user must be able to
do pathname resolution to a subdirectory.
Adds initial support for dtrace static probes in libvirtd
daemon, assuming use of systemtap dtrace compat shim on
Linux. The probes are inserted for network client connect,
disconnect, TLS handshake states and authentication protocol
states.
This can be tested by running the xample program and then
attempting to connect with any libvirt client (virsh,
virt-manager, etc).
# stap examples/systemtap/client.stp
Client fd=44 connected readonly=0
Client fd=44 auth polkit deny pid:24997,uid:500
Client fd=44 disconnected
Client fd=46 connected readonly=1
Client fd=46 auth sasl allow test
Client fd=46 disconnected
The libvirtd.stp file should also really not be required,
since it is duplicated info that is already available in
the main probes.d definition file. A script to autogenerate
the .stp file is needed, either in libvirtd tree, or better
as part of systemtap itself.
* Makefile.am: Add examples/systemtap subdir
* autobuild.sh: Disable dtrace for mingw32
* configure.ac: Add check for dtrace
* daemon/.gitignore: Ignore generated dtrace probe file
* daemon/Makefile.am: Build dtrace probe header & object
files
* daemon/libvirtd.stp: SystemTAP convenience probeset
* daemon/libvirtd.c: Add connect/disconnect & TLS probes
* daemon/remote.c: Add SASL and PolicyKit auth probes
* daemon/probes.d: Master probe definition
* daemon/libvirtd.h: Add convenience macro for probes
so that compilation is a no-op when dtrace is not available
* examples/systemtap/Makefile.am, examples/systemtap/client.stp
Example systemtap script using dtrace probe markers
* libvirt.spec.in: Enable dtrace on F13/RHEL6
* mingw32-libvirt.spec.in: Force disable dtrace
Integrate with libaudit.so for auditing of important operations.
libvirtd gains a couple of config entries for auditing. By
default it will enable auditing, if its enabled on the host.
It can be configured to force exit if auditing is disabled
on the host. It will can also send audit messages via libvirt
internal logging API
Places requiring audit reporting can use the VIR_AUDIT
macro to report data. This is a no-op unless auditing is
enabled
* autobuild.sh, mingw32-libvirt.spec.in: Disable audit
on mingw
* configure.ac: Add check for libaudit
* daemon/libvirtd.aug, daemon/libvirtd.conf,
daemon/test_libvirtd.aug, daemon/libvirtd.c: Add config
options to enable auditing
* include/libvirt/virterror.h, src/util/virterror.c: Add
VIR_FROM_AUDIT source
* libvirt.spec.in: Enable audit
* src/util/virtaudit.h, src/util/virtaudit.c: Simple internal
API for auditing messages
Vdsm needs to communicate with its guest agent via unix domain socket,
which qemu creates due to the following domain xml device:
<channel type='unix'>
<target type='virtio' name='com.redhat.rhevm.vdsm'/>
<source mode='bind' path='/var/lib/libvirt/qemu/channels/fcp-xp-1.com.redhat.rhevm.vdsm'/>
</channel>
The location of the socket below /var/lib/libvirt/qemu/channels makes
sense, to humans and selinux policy alike. However, that socket should
be accessible to vdsm, too.
Due to other (storage) reasons, vdsm is to join the "qemu" group. With
this patch, vdsm can look below /var/lib/libvirt/qemu and connect to the
socket.
The socket itself should be chmod'ed to allow qemu group read/write, but
that's for another project.
BZ#643407
--dhcp-no-override description from dnsmasq man page:
Disable re-use of the DHCP servername and filename fields as
extra option space. If it can, dnsmasq moves the boot server and
filename information (from dhcp-boot) out of their dedicated
fields into DHCP options. This make extra space available in the
DHCP packet for options but can, rarely, confuse old or broken
clients. This flag forces "simple and safe" behaviour to avoid
problems in such a case.
It seems some virtual network card ROMs are this old/buggy so let's add
--dhcp-no-override as a workaround for them. We don't use extra DHCP
options so this should be safe. The option was added in dnsmasq-2.41,
which becomes the minimum required version.
This patch removes the individual author names from the libvirtd and virsh
man pages, instead referring to the main AUTHORS file distributed with
libvirt. This approach is needed, as we can't guarantee unicode support
across all versions of pod2man used with libvirt.
Additionally, this patch includes the libvirtd man page in the spec file
used with "make rpm". Without this patch "make rpm" is broken.
Firstly, the init script has to touch its file under /var/lock/subsys
when started, otherwise the system would think it's not running and
won't stop it during shutdown.
Secondly, for some reason there is a policy to automatically enable
init scripts when they are installed, so let the specfile do this. We
also need to start the init script to ensure it will be stopped during
the first shutdown after installing the package.
Also $LISTFILE should be enclosed by quotes everywhere as suggested by
Eric.
This patch introduces a dependency on libnl, which subsequent patches
will then use.
Changes from V1 to V2:
- added diffstats
- following changes in tree
Example output during shutdown:
Running guests on default URI: console, rhel6-1, rhel5-64
Running guests on lxc:/// URI: lxc-shell
Running guests on xen:/// URI: error: no hypervisor driver available for xen:///
error: failed to connect to the hypervisor
Running guests on vbox+tcp://orkuz/system URI: no running guests.
Suspending guests on default URI...
Suspending console: done
Suspending rhel6-1: done
Suspending rhel5-64: done
Suspending guests on lxc:/// URI...
Suspending lxc-shell: error: Failed to save domain 9cba8bfb-56f4-6589-2d12-8a58c886dd3b state
error: this function is not supported by the hypervisor: virDomainManagedSave
Note, the "Suspending $guest: " shows progress during the suspend phase
if domjobinfo gives meaningful output.
Example output during boot:
Resuming guests on default URI...
Resuming guest rhel6-1: done
Resuming guest rhel5-64: done
Resuming guest console: done
Resuming guests on lxc:/// URI...
Resuming guest lxc-shell: already active
Configuration used for generating the examples above:
URIS='default lxc:/// xen:/// vbox+tcp://orkuz/system'
The script uses /var/lib/libvirt/libvirt-guests files to note all active
guest it should try to resume on next boot. It's content looks like:
default 7f8b9d93-30e1-f0b9-47a7-cb408482654b 085b4c95-5da2-e8e1-712f-6ea6a4156af2 fb4d8360-5305-df3a-2da1-07d682891b8c
lxc:/// 9cba8bfb-56f4-6589-2d12-8a58c886dd3b
Add ebtables,iptables & iptables-ipv6 dependency to rpm.
Changes from V1 to V2:
-passing --without-libpcap to configure script, if libpcap is not to be used
This includes various things:
- fix the Requires: libvirt-client to use %{name} to allow easy
renaming
- when building ESX support one need libcurl-devel
- remove Makefile[.in] from xml/nwfilter in the docs, as this breaks
parallel install ation of i686 and x86_64 packages
- don't include nwfilter config files if not building with the daemon
all relatively trivial which is why I packed them together
* libvirt.spec.in: fix various small bugs
use /var/lib/libvirt/dnsmasq since /var/lib/libvirt/network is
unreadable by the dnsmasq binary
* src/network/bridge_driver.c: update DNSMASQ_STATE_DIR
* src/Makefile.am: create it on make install
* libvirt.spec.in: take the new directory into account
To ensure that patches in the RPM don't break any functionality
it is neccessary to run the test suites during build. It currently
has 3 tests disabled
- daemon-conf: this is totally broken, since it relies on
being able to resolve the 'libvirt' group & being able to
resolve hostnames at daemon startup. This isn't possible
in a mock build root
- seclabeltest: fails to initialize selinux in the mock
build root. Possibly fixable
- nodeinfotest: broken on s390 + ppc - this is a real bug
* libvirt.spec.in: Add a %check section, with 3 tests
temporarily disabled
* configure.ac docs/news.html.in libvirt.spec.in src/libvirt_public.syms:
updates for release of 0.8.0
* po/*.po po/libvirt.pot: updated a lar set of localizations, and merge
the messages
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
This patch adds a relaxng nwfilter schema along with a test that
verifies all the test output XML against the schema. The input XMLs
contain a lot of intentional out-of-range values that make them fail the
schema verification, so I am not verifying against those.
* cfg.mk (sc_prohibit_test_minus_ao): Also check for [.
* docs/Makefile.am (%.html, html/index.html): Avoid non-portable
test usage.
* libvirt.spec.in (%post): Likewise.
* tools/virt-pki-validate.in (servercert.pem): Likewise.
* configure.ac (LOGNAME): Use test, not [, in files processed by
autoconf.
Detected by Matthias Bolte.
* examples/xml/nwfilter/Makefile.am: add all xml to the distribution
* libvirt.spec.in: reference them from the rpm spec file to have them
available in the main libvirt package
Having a single logrotate configuration file for all hypervisors
did not work as logrotate would get confused if an hypervisor not
supported on that platform was still listed. Simplest is to split
the logrotate as separate per hypervisor files and change the
spec file to only install the ones compiled in.
* daemon/libvirtd.lxc.logrotate.in daemon/libvirtd.qemu.logrotate.in
daemon/libvirtd.uml.logrotate.in: copy and split the original
daemon/libvirtd.logrotate.in file
* daemon/Makefile.am: update to support the different files and
cleanup in sed suggested by Eric Blake
* libvirt.spec.in: only install the relevant logrotate configs
* daemon/.gitignore: update logrotate generated list
* configure.ac libvirt.spec.in: update with new version
* docs/news.html.in: add list of changes in 0.7.7
* po/*po*: updated spanish and russian localisations, rebuilt
