This partially reverts 5eb4b04211 and 62774afb6b.
Rewrite the domsuspend example from scratch. This time do it right.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Commit ff76566 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).
The domain events demo program isn't really tied to domain
events anymore, so rename it to object events.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
- systemctl and the %systemd_* RPM macros can take multiple unit names
in the one invocation. Make use of this to avoid repeated systemd
daemon reloads.
- virtlockd was only properly enabled and disabled when using systemd,
but when systemd RPM macros were not available (e.g. on Fedora < 18).
Make sure it's enabled when systemd RPM macros are present, or when
using initscripts.
- Always use "reload" on virtlockd, not "condrestart". This allows it to
cleanly re-execute itself without losing running state. Ignore any
error should the reload fail.
- Move the reloading of virtlockd and libvirtd via their initscripts
into the daemon package's %postun scriptlet. These services must be
restarted after all of the libvirt-daemon-driver-* packages have
been upgraded during the same RPM transaction.
- Add a %triggerpostun executed only when upgrading an older
libvirt-daemon. As an older package would only reload libvirtd during
%post, and the newer package would only reload libvirtd during
%postun, such an upgrade would not reload libvirtd at all without the
trigger.
Signed-off-by: Michael Chapman <mike@very.puzzling.org>
The libvirt-daemon package contains several driver-specific files,
directories, and script, which can be problematic when building the
package with multiple hypervisor support, e.g. both QEMU and Xen.
E.g. installing a QEMU+Xen enabled libvirt-daemon on a Xen-only system
will result in the creation of qemu and kvm groups and a qemu user.
Move the driver-specific files, directories, and script to the
respective driver subpackages.
The daemon-config-{network,nwfilter} subpackages are built regardless
of whether or not with_driver_modules is defined, therefore don't
conditionally define their files list.
The domsuspend example code is a really old and bad exmample of (how not
to use) the libvirt API. Remove it as it's apparent that nobody tried to
use it. It was broken and nobody complained.
We support gluster volumes in domain XML, so we also ought to
support them as a storage pool. Besides, a future patch will
want to take advantage of libgfapi to handle the case of a
gluster device holding qcow2 rather than raw storage, and for
that to work, we need a storage backend that can read gluster
storage volume contents. This sets up the framework.
Note that the new pool is named 'gluster' to match a
<disk type='network'><source protocol='gluster'> image source
already supported in a <domain>; it does NOT match the
<pool type='netfs'><source><target type='glusterfs'>,
since that uses a FUSE mount to a local file name rather than
a network name.
This and subsequent patches have been tested against glusterfs
3.4.1 (available on Fedora 19); there are likely bugs in older
versions that may prevent decent use of gfapi, so this patch
enforces the minimum version tested. A future patch may lower
the minimum. On the other hand, I hit at least two bugs in
3.4.1 that will be fixed in 3.5/3.4.2, where it might be worth
raising the minimum: glfs_readdir is nicer to use than
glfs_readdir_r [1], and glfs_fini should only return failure on
an actual failure [2].
[1] http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00085.html
[2] http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00086.html
* configure.ac (WITH_STORAGE_GLUSTER): New conditional.
* m4/virt-gluster.m4: new file.
* libvirt.spec.in (BuildRequires): Support gluster in spec file.
* src/conf/storage_conf.h (VIR_STORAGE_POOL_GLUSTER): New pool
type.
* src/conf/storage_conf.c (poolTypeInfo): Treat similar to
sheepdog and rbd.
(virStoragePoolDefFormat): Don't output target for gluster.
* src/storage/storage_backend_gluster.h: New file.
* src/storage/storage_backend_gluster.c: Likewise.
* po/POTFILES.in: Add new file.
* src/storage/storage_backend.c (backends): Register new type.
* src/Makefile.am (STORAGE_DRIVER_GLUSTER_SOURCES): Build new files.
* src/storage/storage_backend.h (_virStorageBackend): Documet
assumption.
Signed-off-by: Eric Blake <eblake@redhat.com>
The python binding now lives in
http://libvirt.org/git/?p=libvirt-python.git
that repo also provides an RPM which is upgrade compatible
with the old libvirt-python sub-RPM.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The previous attempt (commit d65e0e1) removed just one of two
libvirt-guests restarts that happened on libvirt-client update. Let's
remove the last one too :-)
https://bugzilla.redhat.com/show_bug.cgi?id=962225
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Restarting an active libvirt-guests.service is the equivalent of
doing:
/usr/libexec/libvirt-guests.sh stop
/usr/libexec/libvirt-guests.sh start
Which in a default configuration will managedsave every running VM,
and then restore them. Certainly not something we should do every
time the libvirt-client RPM is updated.
Just drop the try-restart attempt, I don't know what purpose it
serves anyways.
https://bugzilla.redhat.com/show_bug.cgi?id=962225
https://bugzilla.redhat.com/show_bug.cgi?id=1033614
As virt-login-shell is an SUID binary, we should restrict its usage to
just the users chosen by an administrator to use virt-login-shell as
their login shell. This can easily be done by making the binary
executable only by users from a new virtlogin group.
RHEL-6's rpmbuild wipes the docdir for a (sub-)package if any %doc
directives are present, prior to copying in the marked documentation.
This means we can't prepopulate this directory with the HTML
documentation during the %install phase.
Instead, move the HTML documentation to a temporary directory during
%install and mark the contents of this temporary directory with %doc.
This fixes a build regression introduced in
commit e23216da9a
Author: Cole Robinson <crobinso@redhat.com>
Date: Wed Sep 25 13:20:40 2013 -0400
spec: Clean up distribution of ChangeLog (and others)
where the libvirt-docs sub-RPM gained a %doc directive, thus
triggering the RPM bug.
Signed-off-by: Michael Chapman <mike@very.puzzling.org>
For inexplicable reasons, many of the 3rd party package deps
were left against the 'libvirt-daemon' RPM when the drivers
were split out. This makes a minimal install heavier that
it should be. Push them all down into libvirt-daemon-driver-XXX
so they're only pulled in when truly needed
With this change applied, a minimal install of just the
libvirt-daemon-driver-lxc RPM is reduced by 41 MB on a
Fedora 19 host.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Many people will not want the setuid virt-login-shell binary
installed by default, so move it into a separate sub-RPM
named libvirt-login-shell. This RPM is only generated if
LXC is enabled
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
- Move COPYING* to libvirt-client, so every package pulls them in
- Move AUTHORS ChangeLog.gz NEWS README TODO from -daemon to -docs
- Drop duplicate distribution of docs in -python
https://bugzilla.redhat.com/show_bug.cgi?id=977099
With the existing pkcheck (pid, start time) tuple for identifying
the process, there is a race condition, where a process can make
a libvirt RPC call and in another thread exec a setuid application,
causing it to change to effective UID 0. This in turn causes polkit
to do its permission check based on the wrong UID.
To address this, libvirt must get the UID the caller had at time
of connect() (from SO_PEERCRED) and pass a (pid, start time, uid)
triple to the pkcheck program.
This fix requires that libvirt is re-built against a version of
polkit that has the fix for its CVE-2013-4288, so that libvirt
can see 'pkg-config --variable pkcheck_supports_uid polkit-gobject-1'
Signed-off-by: Colin Walters <walters@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Several recent patches cleaned up 'make rpm' for the situation
when client_only is true; these were done by manual spec file
editing (since it's relatively hard to come by a RHEL 5 s390
box). Make it easier to do in the future via a simpler command
line override.
* libvirt.spec.in (client_only): Allow for override.
Signed-off-by: Eric Blake <eblake@redhat.com>
Commit ba5f3c7 moved virtualBox support into libvirtd, but the spec
file was still unconditionally requesting it even when not building
the server side. Thankfully there were no ill effects for a
client_only build, as most uses of %{with_vbox} were guarded by
%{with_libvirtd}; but we might as well avoid confusion by more
closely matching the makefile.
* libvirt.spec.in (with_vbox): Hoist to server conditionals.
Signed-off-by: Eric Blake <eblake@redhat.com>
'make rpm' failed if ~/.rpmmacros contains '%_without_lxc 1',
which simulates the case of not having lxc available.
RPM build errors:
File not found: /home/eblake/rpmbuild/BUILDROOT/libvirt-1.1.1-1.fc19.x86_64/etc/libvirt/virt-login-shell.conf
File not found by glob: /home/eblake/rpmbuild/BUILDROOT/libvirt-1.1.1-1.fc19.x86_64/usr/share/man/man1/virt-login-shell.1*
File not found: /home/eblake/rpmbuild/BUILDROOT/libvirt-1.1.1-1.fc19.x86_64/usr/bin/virt-login-shell
make: *** [rpm] Error 1
Reported by Dan Berrange.
* libvirt.spec.in: Mark virt-login-shell as conditional on lxc.
Signed-off-by: Eric Blake <eblake@redhat.com>
The gnulib testsuite is relatively stable - the only times it is
likely to have a test change from pass to fail is on a gnulib
submodule update or a major system change (such as moving from
Fedora 18 to 19, or other large change to libc). While it is an
important test for end users on arbitrary machines (to make sure
that the portability glue works for their machine), it mostly
wastes time for development testing (as most developers aren't
making any of the major changes that would cause gnulib tests
to alter behavior). Thus, it pays to make the tests optional
at configure time, defaulting to off for development, on for
tarballs, with autobuilders requesting it to be on. It also
helps to allow a make-time override, via VIR_TEST_EXPENSIVE=[01]
(much the way automake sets up V=[01] for overriding the configure
time default of how verbose to be).
Automake has some pretty hard-coded magic with regards to the
TESTS variable; I had quite a job figuring out how to keep
'make distcheck' passing regardless of the configure option
setting in use, while still disabling the tests at runtime
when I did not configure them on and did not use the override
variable. Thankfully, we require GNU make, which lets me
hide some information from Automake's magic handling of TESTS.
* bootstrap.conf (bootstrap_epilogue): Munge gnulib test variable.
* configure.ac (--enable-expensive-tests): Add new enable switch.
(VIR_TEST_EXPENSIVE_DEFAULT, WITH_EXPENSIVE_TESTS): Set new
witnesses.
* gnulib/tests/Makefile.am (TESTS): Make tests conditional on
configure settings and the VIR_TEST_EXPENSIVE variable.
* tests/Makefile.am (TESTS_ENVIRONMENT): Expose VIR_TEST_EXPENSIVE
to all tests.
* autobuild.sh: Enable all tests during autobuilds.
* libvirt.spec.in (%configure): Likewise.
* mingw-libvirt.spec.in (%mingw_configure): Likewise.
* docs/hacking.html.in: Document the option.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=951637
Newer gnutls uses nettle, rather than gcrypt, which is a lot nicer
regarding initialization. Yet we were unconditionally initializing
gcrypt even when gnutls wouldn't be using it, and having two crypto
libraries linked into libvirt.so is pointless, but mostly harmless
(it doesn't crash, but does interfere with certification efforts).
There are three distinct version ranges to worry about when
determining which crypto lib gnutls uses, per these gnutls mails:
2.12: http://lists.gnu.org/archive/html/gnutls-devel/2011-03/msg00034.html
3.0: http://lists.gnu.org/archive/html/gnutls-devel/2011-07/msg00035.html
If pkg-config can prove version numbers and/or list the crypto
library used for static linking, we have our proof; if not, it
is safer (even if pointless) to continue to use gcrypt ourselves.
* configure.ac (WITH_GNUTLS): Probe whether to add -lgcrypt, and
define a witness WITH_GNUTLS_GCRYPT.
* src/libvirt.c (virTLSMutexInit, virTLSMutexDestroy)
(virTLSMutexLock, virTLSMutexUnlock, virTLSThreadImpl)
(virGlobalInit): Honor the witness.
* libvirt.spec.in (BuildRequires): Make gcrypt usage conditional,
no longer needed in Fedora 19.
Signed-off-by: Eric Blake <eblake@redhat.com>
The virtlockd daemon supports an /etc/libvirt/virtlockd.conf
config file, but we never installed a default config, nor
created any augeas scripts. This change addresses that omission.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Add a virt-login-shell binary that can be set as a user's
shell, such that when they login, it causes them to enter
the LXC container with a name matching their user name.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
As both /var/lib/libvirt/qemu and /var/lib/libvirt/qemu/channel/target
are owned by us, the intermediate /var/lib/libvirt/qemu/channel should
be owned by us too.
As RHEL provides a stable tool chain, we don't have to worry about
frequent changes in reported compiler warnings (which prevents us from
enabling -Werror unconditionally).
https://bugzilla.redhat.com/show_bug.cgi?id=905513
Libssh2 isn't reliable enough to support the libvirt transport using it.
The problems include mishandling of "known_hosts" files that may confuse
users.
If libapparmor-devel happens to be installed when building the
RPM, it will failed due to unlisted virt-aa-helper in %files.
Add support for apparmor in the spec, so that we can explicitly
turn it on/off, defaulting to off in all distros. This causes
--without-apparmor to be given to configure, preventing the
build failures if the user happens to have libapparmor-devel
present.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Current automake enables parallel test by default, which means test
details are only logged in test-suite.log and not printed to stderr.
This patch makes test failures directly visible in RPM build logs even
when parallel tests are turned on.
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 using 'rpmbuild --define "_without_xen 1"', but on a new enough
Fedora where %{with_libxl} still gets set to 1 by default, the
build dependencies were incomplete, which could result in 'make rpm'
failing because ./configure failed to build the libxl driver.
* libvirt.spec.in (BuildRequires): Fix xen-devel condition.
Signed-off-by: Eric Blake <eblake@redhat.com>
Add <features> and <compat> elements to volume target XML.
<compat> is a string which for qcow2 represents the QEMU version
it should be compatible with. Valid values are 0.10 and 1.1.
1.1 is implicit if the <features> element is present, otherwise
qemu-img default is used. 0.10 can be specified to explicitly
create older images after the qemu-img default changes.
<features> contains optional features, so far
<lazy_refcounts/> is available, which enables caching of reference
counters, improving performance for snapshots.
Our configure.ac says:
Not all versions of gnutls include -lgcrypt, and so we add
it explicitly for the calls to gcry_control/check_version
Thus we cannot rely on gnutls-devel to bring grcypt-devel as a
dependency.
Commit 6ab6bc19f0 has introduced separate
daemon/driver packages for vbox. These should only be built for x86
architectures which is done hereby.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
https://www.gnu.org/licenses/gpl-howto.html states:
You should also include a copy of the license itself somewhere in the
distribution of your program. All programs, whether they are released
under the GPL or LGPL, should include the text version of the GPL. In
GNU programs the license is usually in a file called COPYING.
If you are releasing your program under the LGPL, you should also
include the text version of the LGPL, usually in a file called
COPYING.LESSER. Please note that, since the LGPL is a set of
additional permissions on top of the GPL, it's important to include
both licenses so users have all the materials they need to understand
their rights.
* configure.ac (COPYING): No more games with non-git file.
* COPYING: New file, copied from gnulib.
* COPYING.LIB: Rename...
* COPYING.LESSER: ...to this.
* .gitignore: Track licenses in git.
* cfg.mk (exclude_file_name_regexp--sc_copyright_address): Tweak
rule.
* libvirt.spec.in (daemon, client, python): Reflect rename.
Signed-off-by: Eric Blake <eblake@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=963016 points out that
we don't use initscripts by default on Fedora any more.
* libvirt.spec.in (Requires): Better explanation of gettext.
Signed-off-by: Eric Blake <eblake@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=924501 tracks a
problem that occurs if uid 107 is already in use at the time
libvirt is first installed. In response that problem, Fedora
packaging guidelines were recently updated. This fixes the
spec file to comply with the new guidelines:
https://fedoraproject.org/wiki/Packaging:UsersAndGroups
* libvirt.spec.in (daemon): Follow updated Fedora guidelines.
Signed-off-by: Eric Blake <eblake@redhat.com>
It's not desired to force users imagine path for a socket they
are not even supposed to connect to. On the other hand, we
already have a release where the qemu agent socket path is
exposed to XML, so we cannot silently drop it from there.
The new path is generated in form:
$LOCALSTATEDIR/lib/libvirt/qemu/channel/target/$domain.$name
for qemu system mode, and
$XDG_CONFIG_HOME/qemu/lib/channel/target/$domain.$name
for qemu session mode.
Conditional BuildRequires: should be at the top level, rather
than appearing in conditional sub-package sections. This
appears to be the only offender.
* libvirt.spec.in (BuildRequires): Move libblkid-devel into
correct area.
Signed-off-by: Eric Blake <eblake@redhat.com>
Since commit b8a32e0e94, all man pages
depend on configure.ac so that they are properly regenerated whenever
libvirt version changes. Thus libvirt.spec needs to have a build
dependency on pod2man when %{enable_autotools} is set.
When a changelog entry references an RPM macro, % needs to be escaped so
that it does not appear expanded in package changelog.
Fri Mar 4 2009 is incorrect since Mar 4 was Wednesday. Since
libvirt-0.6.1 was released on Mar 4 2009, we should change Fri to Wed.
The macro was made to help installing broken packages that did not use
DESTDIR correctly by overriding individual path variables (prefix,
sysconfdir, ...). Newer rpm provides fixed make_install macro that calls
make install with just the correct DESTDIR, however it is not available
everywhere (e.g., RHEL 5 does not have it). On the other hand the
make_install macro is simple and straightforward enough for us to use
its expansion directly.
Nested conditionals are hard to read if they are not indented.
We can't add arbitrary whitespace to everything in spec files,
but we CAN add spaces before %if and %define. Use this trick,
plus a fancy sed script that rewrites a spec file into a C
file, so we can use cppi to keep our spec file nice.
For reference, the sed script converts code like:
|# RHEL-5 builds are client-only for s390, ppc
|%if 0%{?rhel} == 5
| %ifnarch %{ix86} x86_64 ia64
| %define client_only 1
| %endif
|%endif
into the following for cppi:
|// # RHEL-5 builds are client-only for s390, ppc
|#if a // 0%{?rhel} == 5
|# if a // %{ix86} x86_64 ia64
|# define client_only 1
|# endif
|#endif
and errors from 'make syntax-check' look like:
spec_indentation
cppi: mingw-libvirt.spec.in: line 130: not properly indented
maint.mk: incorrect preprocessor indentation
* libvirt.spec.in: Add some indentation to make it easier to follow
various conditionals.
* mingw-libvirt-spec.in: Likewise.
* cfg.mk (sc_spec_indentation): New syntax check to enforce it.
This patch introduces support for LXC specific public APIs. In
common with what was done for QEMU, this creates a libvirt_lxc.so
library and libvirt/libvirt-lxc.h header file.
The actual APIs are
int virDomainLxcOpenNamespace(virDomainPtr domain,
int **fdlist,
unsigned int flags);
int virDomainLxcEnterNamespace(virDomainPtr domain,
unsigned int nfdlist,
int *fdlist,
unsigned int *noldfdlist,
int **oldfdlist,
unsigned int flags);
which provide a way to use the setns() system call to move the
calling process into the container's namespace. It is not
practical to write in a generically applicable manner. The
nearest that we could get to such an API would be an API which
allows to pass a command + argv to be executed inside a
container. Even if we had such a generic API, this LXC specific
API is still useful, because it allows the caller to maintain
the current process context, in particular any I/O streams they
have open.
NB the virDomainLxcEnterNamespace() API is special in that it
runs client side, so does not involve the internal driver API.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
There are many aspects of the guest XML which result in the
SELinux driver applying file labelling. With the increasing
configuration options it is desirable to test this behaviour.
It is not possible to assume that the test suite has the
ability to set SELinux labels. Most filesystems though will
support extended attributes. Thus for the purpose of testing,
it is possible to extend the existing LD_PRELOAD hack to
override setfilecon() and getfilecon() to simply use the
'user.libvirt.selinux' attribute for the sake of testing.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This converts the libssh2 configure check to use LIBVIRT_CHECK_PKG.
Previously it would check version 1.0 and 1.3, but this simplifies
things to just require version 1.3
On rhel5, libs of avahi are packaged into avahi instead of avahi-libs.
Actually, there is no avahi-libs package shipped with rhel5. This patch
fixes this by requiring avahi on rhel5.
The daemon-driver-{qemu,lxc} packages are only built if
%{with_driver_modules} is specified, so they do not need to
further test this condition. Likewise, the daemon package
is only built if %{with_libvirtd} is specified, so it does
not need to further test this condition.
* libvirt.spec.in (daemon-driver-qemu, daemon-driver-lxc):
Unconditionally require libvirt-daemon-driver-network.
(daemon): Unconditionally include lock-driver files.
When building libvirt rpms on rhel5, I got the following error:
File must begin with "/": rm
File must begin with "/": -f
File must begin with "/": $RPM_BUILD_ROOT/etc/sysctl.d/libvirtd
Installed (but unpackaged) file(s) found:
/etc/sysctl.d/libvirtd
It is triggerd by the %files list of libvirt daemon:
%if 0%{?fedora} >= 14 || 0%{?rhel} >= 6
%config(noreplace) %{_prefix}/lib/sysctl.d/libvirtd.conf
%else
rm -f $RPM_BUILD_ROOT%{_prefix}/lib/sysctl.d/libvirtd.conf
%endif
After checking document of rpm spec file, I think it would be better
to move the file deleting line from %files list to %install script.
Bug introduced in commit a1fd56c.
In a non-systemd environment the post and preun scripts of libvirt-client
fail, since the required files are in libvirt-daemon. Moved them to client.
Doing that I noticed %{_unitdir}/libvirt-guests.service was contained in
both libvirt-client and libvirt-daemon, which I don't think was intended.
Removed the extra copy from daemon.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
https://bugzilla.redhat.com/show_bug.cgi?id=887017 reports that
even though libvirt attempts to set fs.aio-max-nr via sysctl,
the file was installed with the wrong name and gets ignored by
sysctl. Furthermore, 'man systcl.d' recommends that packages
install into hard-coded /usr/lib/sysctl.d (even when libdir is
/usr/lib64), so that sysadmins can use /etc/sysctl.d for overrides.
* daemon/Makefile.am (install-sysctl, uninstall-sysctl): Use
correct location.
* libvirt.spec.in (network_files): Reflect this.
Unfortunately, rpm is stupid enough to bytycompile python scripts even
though they are located in /usr/share/doc/libvirt-python-*/examples and
it does so after %install phase is finished. Thus there's no way we
could remove those files from BUILDROOT. As a workaround, we may safely
remove the examples subdirectory completely without losing anything. The
python scripts that were installed there are also copied directly into
/usr/share/doc/libvirt-python-*/ by
%doc python/tests/*.py
rule. And yes, the files are actually tests, not examples.
The virtlockd daemon maintains file locks on behalf of libvirtd
and any VMs it is running. These file locks must be held for as
long as any VM is running. If virtlockd itself ever quits, then
it is expected that a node would be fenced/rebooted. Thus to
allow for software upgrads on live systemd, virtlockd needs the
ability to re-exec() itself.
Upon receipt of SIGUSR1, virtlockd will save its current live
state out to a file /var/run/virtlockd-restart-exec.json
It then re-exec()'s itself with exactly the same argv as it
originally had, and loads the state file, reconstructing any
objects as appropriate.
The state file contains information about all locks held and
all network services and clients currently active. An example
state document is
{
"server": {
"min_workers": 1,
"max_workers": 20,
"priority_workers": 0,
"max_clients": 20,
"keepaliveInterval": 4294967295,
"keepaliveCount": 0,
"keepaliveRequired": false,
"services": [
{
"auth": 0,
"readonly": false,
"nrequests_client_max": 1,
"socks": [
{
"fd": 6,
"errfd": -1,
"pid": 0,
"isClient": false
}
]
}
],
"clients": [
{
"auth": 0,
"readonly": false,
"nrequests_max": 1,
"sock": {
"fd": 9,
"errfd": -1,
"pid": 0,
"isClient": true
},
"privateData": {
"restricted": true,
"ownerPid": 1722,
"ownerId": 6,
"ownerName": "f18x86_64",
"ownerUUID": "97586ba9-df27-9459-c806-f016c8bbd224"
}
},
{
"auth": 0,
"readonly": false,
"nrequests_max": 1,
"sock": {
"fd": 10,
"errfd": -1,
"pid": 0,
"isClient": true
},
"privateData": {
"restricted": true,
"ownerPid": 1784,
"ownerId": 7,
"ownerName": "f16x86_64",
"ownerUUID": "7b8e5e42-b875-61e9-b981-91ad8fa46979"
}
}
]
},
"defaultLockspace": {
"resources": [
{
"name": "/var/lib/libvirt/images/f16x86_64.raw",
"path": "/var/lib/libvirt/images/f16x86_64.raw",
"fd": 14,
"lockHeld": true,
"flags": 0,
"owners": [
1784
]
},
{
"name": "/var/lib/libvirt/images/shared.img",
"path": "/var/lib/libvirt/images/shared.img",
"fd": 12,
"lockHeld": true,
"flags": 1,
"owners": [
1722,
1784
]
},
{
"name": "/var/lib/libvirt/images/f18x86_64.img",
"path": "/var/lib/libvirt/images/f18x86_64.img",
"fd": 11,
"lockHeld": true,
"flags": 0,
"owners": [
1722
]
}
]
},
"lockspaces": [
],
"magic": "30199"
}
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This enhancement virtlockd so that it can receive a pre-opened
UNIX domain socket from systemd at launch time, and adds the
systemd service/socket unit files
* daemon/libvirtd.service.in: Require virtlockd to be running
* libvirt.spec.in: Add virtlockd systemd files
* src/Makefile.am: Install systemd files
* src/locking/lock_daemon.c: Support socket activation
* src/locking/virtlockd.service.in, src/locking/virtlockd.socket.in:
systemd unit files
* src/rpc/virnetserverservice.c, src/rpc/virnetserverservice.h:
Add virNetServerServiceNewFD() method
* src/rpc/virnetsocket.c, src/rpc/virnetsocket.h: Add virNetSocketNewListenFD
method
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The virtlockd daemon will maintain locks on behalf of libvirtd.
There are two reasons for it to be separate
- Avoid risk of other libvirtd threads accidentally
releasing fcntl() locks by opening + closing a file
that is locked
- Ensure locks can be preserved across libvirtd restarts.
virtlockd will need to be able to re-exec itself while
maintaining locks. This is simpler to achieve if its
sole job is maintaining locks
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Most of this deals with moving the libvirt-guests.sh script which
does all the work to /usr/libexec, so it can be shared by both
systemd and traditional init. Previously systemd depended on
the script being in /etc/init.d
Required to fix https://bugzilla.redhat.com/show_bug.cgi?id=789747
Based on a patch originally authored by Daniel De Graaf
http://lists.xen.org/archives/html/xen-devel/2012-05/msg00565.html
This patch converts the Xen libxl driver to support only Xen >= 4.2.
Support for Xen 4.1 libxl is dropped since that version of libxl is
designated 'technology preview' only and is incompatible with Xen 4.2
libxl. Additionally, the default toolstack in Xen 4.1 is still xend,
for which libvirt has a stable, functional driver.
https://bugzilla.redhat.com/show_bug.cgi?id=830201
In older Fedora, the spec file for libivrt depended on avahi, which
included avahi-daemon, which in turn depended on dbus. But now that
avahi libs and avahi-daemon are (correctly) in separate pacakges,
and since we REALLY don't want a mandatory dependency on avahi-daemon,
and considering that our init scripts require the messagebus service
from dbus, we need to explicitly require dbus ourselves.
* libvirt.spec.in (Requires): Add dbus for libvirt-daemon.
Implement the domainManagedSave, domainHasManagedSaveImage, and
domainManagedSaveRemove functions in the libvirt legacy xen driver.
domainHasManagedSaveImage check the managedsave image from filesystem
everytime. This is different from qemu and libxl driver. In qemu or
libxl driver, there is a hasManagesSave flag in virDomainObjPtr which
is not used in xen legacy driver. This flag could not add into xen
driver ptr either, because the driver ptr will be released at the end of
every libvirt api call. Meanwhile, AFAIK, xen store all the flags in
xen not in libvirt xen driver. There is no need to add this flag in xen.
Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
In Fedora 16, we quit enabling cgconfig because systemd set up
default cgroups that were good enough for our use. But in F17,
when we switched to systemd, we reverted and started up cgconfig
again. See also the tail of this thread:
https://www.redhat.com/archives/libvir-list/2012-October/msg01657.html
* libvirt.spec.in (with_systemd): Rely on systemd for cgroups.
* configure.ac docs/news.html.in libvirt.spec.in: update for the new release
* po/*.po*: update from transifex, a lot of added support e.g. Indian
languages, and regenerate
Make the post install script for the lock-sanlock package optional
to prevent break on non-x86 platforms.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
This should not make a big difference in real world since libvirt-daemon,
which is already required by libvirt-lock-sanlock, requires
libvirt-client and thus libvirt-lock-sanlock gets this dependency
transitively. However, since libvirt-lock-sanlock contains
sanlock_helper binary linked to libvirt.so, we should start requiring
libvirt-client directly.
The previous commit was incomplete. We need to also add explicit
Requires for the newer version since RPM's automatic dependencies won't
work with sanlock.
libssh2 unfortunately doesn't support symbol versioning so RPM can't
figure out what version is needed for the currently installed libvirt
package. This patch adds a runtime requirement, so that the correct
version of libssh2 can be installed along with libvirt.
Libssh2 transport support was enabled lately but the spec file wasn't
updated to take this into account. This caused libvirt to be built
without libssh2 support in Red Hat based OSes.
While the changes to sanlock driver should be stable, the actual
implementation of sanlock_helper is supposed to be replaced in the
future. However, before we can implement a better sanlock_helper, we
need an administrative interface to libvirtd so that the helper can just
pass a "leases lost" event to the particular libvirt driver and
everything else will be taken care of internally. This approach will
also allow libvirt to pass such event to applications and use
appropriate reasons when changing domain states.
The temporary implementation handles all actions directly by calling
appropriate libvirt APIs (which among other things means that it needs
to know the credentials required to connect to libvirtd).
I noticed that in two places, we require util-linux, and in a third,
we require util-linux-ng. On Fedora (I tested F15 through rawhide),
util-linux-ng is obsoleted by util-linux; on RHEL 6, util-linux
is obsoleted by util-linux-ng. That is, on either platform, either
name will get you the correct package installed (where the preferred
name on fedora is util-linux, and on RHEL 6 is util-linux-ng). But
on RHEL 5, there is no util-linux-ng
* libvirt.spec.in (Requires): Use util-linux, not util-linux-ng.
The Fedora policies don't want us installing the legacy initscripts
in parallel with the systemd ones, so switch to only install the
systemd unit
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Based exclusively on work by Eric Blake in a patch posted with the same
subject. However some modifications related to comments and my plans to
add another backend.
Added WITH_INTERFACE as the only automake variable deciding whether to
build the driver and using WITH_NETCF to identify that we're wanting to
use the netcf library as the backend.
* configure.ac: Added with_interface
* src/interface/netcf_driver.c: Renamed..
* src/interface/interface_backend_netcf.c: ..to this to match storage.
* src/interface/netcf_driver.h: Renamed..
* src/interface/interface_driver.h: ..to this.
* daemon/Makefile.am: Respect WITH_INTERFACE and WITH_NETCF.
* libvirt.spec.in: Add RPM support for --with-interface
When building RPMs the host kernel cannot be assumed to match
the target OS kernel. Thus auto-detecting /selinux vs
/sys/fs/selinux based on the host kernel can result in the
wrong choice (eg F18 builds on a RHEL6 host kernel)
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
A previous patch forced libnl-3 and netcf-0.2.2 (which itself requires
libnl-3) when *building* for Fedora 18+ (and RHEL 7+), but the
install-time Requires: for netcf has always been implicit due to
libvirtd linking with libnetcf.so. However, the since the API of netcf
didn't change when it was rebuilt to use libnl-3, the internal library
version didn't change either, making it possible (from rpm's point of
view) to upgrade libvirt without upgrading netcf (in reality, that
leads to a segfault - see
https://bugzilla.redhat.com/show_bug.cgi?id=853381).
The solution is to put an explicit Requires: line in libvirt's
specfile for fedora >= 18 and rhel >= 7.
The libvirt storage driver uses librbd.so for its functionality.
RPM will automatically add a dependency on the library, so there
is no need to have an explicit dependency on the ceph RPM itself.
This allows newer Fedora distros to avoid pulling in the huge
ceph RPM, in favour of just having the libraries installed
Everything is ready in both netcf and libvirt to switch over to libnl3
in future releases of both Fedora and RHEL. This needs to be done more
or less simultaneously in both packages, though, because you can't mix
libnl1.1 and libnl3 in the same process (e.g. libvirtd using
libnl-3.so and libnetcf.so, while libnetcf.so uses libnl.so)
This patch does two things when fedora >= 18 || rhel >= 7):
1) requires libnl3-devel
2) requires netcf-devel-0.2.2 or greater
(the idea is that a similar patch is going into netcf's specfile, so
that when a build of netcf is done on F18 or later (or RHEL7 or later)
netcf will be guaranteed to be built with libnl3 rather than
libnl-1.1)
* configure.ac, spec file: firewalld defaults to enabled if dbus is
available, otherwise is disabled. If --with_firewalld is explicitly
requested and dbus is not available, configure will fail.
* bridge_driver: add dbus filters to get the FirewallD1.Reloaded
signal and DBus.NameOwnerChanged on org.fedoraproject.FirewallD1.
When these are encountered, reload all the iptables reuls of all
libvirt's virtual networks (similar to what happens when libvirtd is
restarted).
* iptables, ebtables: use firewall-cmd's direct passthrough interface
when available, otherwise use iptables and ebtables commands. This
decision is made once the first time libvirt calls
iptables/ebtables, and that decision is maintained for the life of
libvirtd.
* Note that the nwfilter part of this patch was separated out into
another patch by Stefan in V2, so that needs to be revised and
re-reviewed as well.
================
All the configure.ac and specfile changes are unchanged from Thomas'
V3.
V3 re-ran "firewall-cmd --state" every time a new rule was added,
which was extremely inefficient. V4 uses VIR_ONCE_GLOBAL_INIT to set
up a one-time initialization function.
The VIR_ONCE_GLOBAL_INIT(x) macro references a static function called
vir(Ip|Eb)OnceInit(), which will then be called the first time that
the static function vir(Ip|Eb)TablesInitialize() is called (that
function is defined for you by the macro). This is
thread-safe, so there is no chance of any race.
IMPORTANT NOTE: I've left the VIR_DEBUG messages in these two init
functions (one for iptables, on for ebtables) as VIR_WARN so that I
don't have to turn on all the other debug message just to see
these. Even if this patch doesn't need any other modification, those
messages need to be changed to VIR_DEBUG before pushing.
This one-time initialization works well. However, I've encountered
problems with testing:
1) Whenever I have enabled the firewalld service, *all* attempts to
call firewall-cmd from within libvirtd end with firewall-cmd hanging
internally somewhere. This is *not* the case if firewall-cmd returns
non-0 in response to "firewall-cmd --state" (i.e. *that* command runs
and returns to libvirt successfully.)
2) If I start libvirtd while firewalld is stopped, then start
firewalld later, this triggers libvirtd to reload its iptables rules,
however it also spits out a *ton* of complaints about deletion failing
(I suppose because firewalld has nuked all of libvirt's rules). I
guess we need to suppress those messages (which is a more annoying
problem to fix than you might think, but that's another story).
3) I noticed a few times during this long line of errors that
firewalld made a complaint about "Resource Temporarily
unavailable. Having libvirtd access iptables commands directly at the
same time as firewalld is doing so is apparently problematic.
4) In general, I'm concerned about the "set it once and never change
it" method - if firewalld is disabled at libvirtd startup, causing
libvirtd to always use iptables/ebtables directly, this won't cause
*terrible* problems, but if libvirtd decides to use firewall-cmd and
firewalld is later disabled, libvirtd will not be able to recover.
The 'make check' was rebuilding the binaries just overrided,
so for more safety also override the C program
Also daemon-conf isn't built anymore so remove it from the list
Parallels Cloud Server is a cloud-ready virtualization
solution that allows users to simultaneously run multiple virtual
machines and containers on the same physical server.
More information can be found here: http://www.parallels.com/products/pcs/
Also beta version of Parallels Cloud Server can be downloaded there.
Signed-off-by: Dmitry Guryanov <dguryanov@parallels.com>
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.
