11:53 a.m.
From: "Daniel P. Berrange" <berrange(a)redhat.com>
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
---
docs/packaging.html.in | 106 ++++++++++
docs/sitemap.html.in | 4 +
libvirt.spec.in | 512 +++++++++++++++++++++++++++++++++++++-----------
3 files changed, 505 insertions(+), 117 deletions(-)
create mode 100644 docs/packaging.html.in
In v2:
- Split libvirt-daemon-configs into libvirt-daemon-config-network
and libvirt-daemon-config-nwfilter
- Fix ordering of QEMU/KVM bits
- Don't install nwfilter configs if the driver is turned off
- Enable nwfilter for LXC/UML drivers explicitly, not just KVM
- Fix docs typos
- Make all %files sections conditional
Tested build on F17 and RHEL-6.3
diff --git a/docs/packaging.html.in b/docs/packaging.html.in
new file mode 100644
index 0000000..0adffd3
--- /dev/null
+++ b/docs/packaging.html.in
@@ -0,0 +1,106 @@
+<?xml version="1.0"?>
+<html>
+ <body>
+ <h1>Distribution packaging</h1>
+
+ <ul id="toc"></ul>
+
+ <p>
+ This page describes the rationale behind the libvirt distribution
+packaging in RPM format. The RPM specfile provided with libvirt targets
+all Fedora and RHEL releases. It is split up into a number of sub-RPMs
+in order to facilitate minimal installations, targetting specific
+feature sets.
+ </p>
+
+ <h2><a name="real">Real packages</a></h2>
+
+ <p>
+ The so called "real" packages provide the actual file payloads
+ related to libvirt. If very specific / targetted functionality
+ is required, then applications can depend on one or more of these
+ real packages.
+ </p>
+
+ <dl>
+ <dt>libvirt-client</dt>
+ <dd>This package provides the main libvirt.so library along with
+ the virsh command line tool. If a C based application only wants
+ to be able to manage remote hypervisors, this is all that they
+ need depend on</dd>
+ <dt>libvirt-devel</dt>
+ <dd>This package provides the header files and libraries required
+ to compile and link C applications using libvirt</dd>
+ <dt>libvirt-python</dt>
+ <dd>This package provides the Python binding to the C libraries.
+ It will pull in the libvirt-client RPM. If a Python application
+ only wants to be able to manage remote hypervisors, this is all
+ that they need depend on</dd>
+ <dt>libvirt-daemon</dt>
+ <dd>This package provides server side libvirtd daemon, which is
+ required in order to manage any stateful hypervisors (currently
+ QEMU, KVM, Xen, LXC and UML).</dd>
+ <dt>libvirt-daemon-config-network</dt>
+ <dd>This package provides the standard configuration files for
+ setting up a NAT based network</dd>
+ <dt>libvirt-daemon-config-nwfilter</dt>
+ <dd>This package provides the standard configuration files for
+ network filter rules for ensuring clean VM traffic.</dd>
+ </dl>
+
+ <h2><a name="virtual">Virtual packages</a></h2>
+
+ <p>
+ The virtual packages provide convenient targets for application dependencies to
+ pull in functionality related to specific hypervisors. Since the packaging of
+ the <code>libvirt-daemon</code> RPM is expected to change in the future
to split
+ each hypervisor driver out into a separate RPM, applications are strongly
+ recommended to depend on one of the following virtual packages, instead of
+ depending directly on <code>libvirt-daemon</code>
+ </p>
+
+ <dl>
+ <dt>libvirt</dt>
+ <dd>This package, simply pulls in every single other server side RPM.
+ If an application wants to ensure all possible libvirt drivers are installed,
+ this is what they should depend on</dd>
+
+ <dt>libvirt-daemon-qemu</dt>
+ <dd>This package pulls in the server side daemon, drivers and the QEMU TCG
binaries
+ required to provide emulation of non-native architectures</dd>
+ <dt>libvirt-daemon-kvm</dt>
+ <dd>This package pulls in the server side daemon, drivers and the KVM
binaries
+ required to provide hardware accelerated virtualization of the native
+ architectures</dd>
+ <dt>libvirt-daemon-lxc</dt>
+ <dd>This package pulls in the server side daemon and drivers required to
+ run native Linux containers</dd>
+ <dt>libvirt-daemon-uml</dt>
+ <dd>This package pulls in the server side daemon and drivers required to
+ run User Mode Linux. The application must still provide the actual
+ UML binary kernels</dd>
+ <dt>libvirt-daemon-xen</dt>
+ <dd>This package pulls in the server side daemon and drivers required to
+ run guests on the Xen hypervisor.</dd>
+
+ <dt>libvirt-qemu</dt>
+ <dd>This package pulls in the server side daemon, drivers and the QEMU TCG
binaries
+ required to provide emulation of non-native architectures</dd>
+ <dt>libvirt-kvm</dt>
+ <dd>This package pulls in the server side daemon, drivers and the KVM
binaries
+ required to provide hardware accelerated virtualization of the native
+ architectures</dd>
+ <dt>libvirt-lxc</dt>
+ <dd>This package pulls in the server side daemon, drivers and default
+ configuration files required to run native Linux containers</dd>
+ <dt>libvirt-uml</dt>
+ <dd>This package pulls in the server side daemon, drivers and default
+ configuration files required to run User Mode Linux. The application
+ must still provide the actual UML binary kernels</dd>
+ <dt>libvirt-xen</dt>
+ <dd>This package pulls in the server side daemon, drivers and default
+ configuration files required to run guests on the Xen hypervisor.</dd>
+ </dl>
+
+ </body>
+</html>
diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in
index 1de2b20..620c989 100644
--- a/docs/sitemap.html.in
+++ b/docs/sitemap.html.in
@@ -84,6 +84,10 @@
<a href="hooks.html">Hooks</a>
<span>Hooks for system specific management</span>
</li>
+ <li>
+ <a href="packaging.html">Distribution
packaging</a>
+ <span>Rationale for distribution RPM packaging</span>
+ </li>
</ul>
</li>
<li>
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 67f1c33..8730881 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -52,6 +52,14 @@
%define with_libxl 0%{!?_without_libxl:%{server_drivers}}
%define with_vmware 0%{!?_without_vmware:%{server_drivers}}
+%define with_qemu_tcg %{with_qemu}
+# Change if we ever provide qemu-kvm binaries on non-x86 hosts
+%ifarch %{ix86} x86_64
+%define with_qemu_kvm %{with_qemu}
+%else
+%define with_qemu_kvm 0
+%endif
+
# Then the hypervisor drivers that talk via a native remote protocol
%define with_phyp 0%{!?_without_phyp:1}
%define with_esx 0%{!?_without_esx:1}
@@ -125,8 +133,10 @@
# RHEL-5 has restricted QEMU to x86_64 only and is too old for LXC
%if 0%{?rhel} == 5
+%define with_qemu_tcg 0
%ifnarch x86_64
%define with_qemu 0
+%define with_qemu_kvm 0
%endif
%define with_lxc 0
%endif
@@ -134,8 +144,10 @@
# RHEL-6 has restricted QEMU to x86_64 only, stopped including Xen
# on all archs. Other archs all have LXC available though
%if 0%{?rhel} >= 6
+%define with_qemu_tcg 0
%ifnarch x86_64
%define with_qemu 0
+%define with_qemu_kvm 0
%endif
%define with_xen 0
%endif
@@ -206,10 +218,13 @@
%define with_storage_disk 0
%endif
-%if %{with_qemu}
+%if %{with_qemu} || %{with_lxc} || %{with_uml}
%define with_nwfilter 0%{!?_without_nwfilter:%{server_drivers}}
# Enable libpcap library
%define with_libpcap 0%{!?_without_libpcap:%{server_drivers}}
+%endif
+
+%if %{with_qemu}
%define with_macvtap 0%{!?_without_macvtap:%{server_drivers}}
# numad is used to manage the CPU placement dynamically,
@@ -268,109 +283,22 @@ Source: http://libvirt.org/sources/libvirt-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
URL: http://libvirt.org/
-# All runtime requirements for the libvirt package (runtime requrements
-# for subpackages are listed later in those subpackages)
-
-# The client side, i.e. shared libs and virsh are in a subpackage
-Requires: %{name}-client = %{version}-%{release}
-
-# Used by many of the drivers, so turn it on whenever the
-# daemon is present
%if %{with_libvirtd}
-# for modprobe of pci devices
-Requires: module-init-tools
-# for /sbin/ip & /sbin/tc
-Requires: iproute
-%if %{with_avahi}
-Requires: avahi-libs
-%endif
-%endif
+Requires: libvirt-daemon = %{version}-%{release}
%if %{with_network}
-Requires: dnsmasq >= 2.41
-Requires: radvd
-%endif
-%if %{with_network} || %{with_nwfilter}
-Requires: iptables
-Requires: iptables-ipv6
+Requires: libvirt-daemon-config-network = %{version}-%{release}
%endif
%if %{with_nwfilter}
-Requires: ebtables
-%endif
-# needed for device enumeration
-%if %{with_hal}
-Requires: hal
-%endif
-%if %{with_udev}
-Requires: udev >= 145
-%endif
-%if %{with_polkit}
-%if 0%{?fedora} >= 12 || 0%{?rhel} >=6
-Requires: polkit >= 0.93
-%else
-Requires: PolicyKit >= 0.6
-%endif
-%endif
-%if %{with_storage_fs}
-Requires: nfs-utils
-# For mkfs
-Requires: util-linux-ng
-# For pool-build probing for existing pools
-BuildRequires: libblkid-devel >= 2.17
-# For glusterfs
-%if 0%{?fedora} >= 11
-Requires: glusterfs-client >= 2.0.1
-%endif
-%endif
-%if %{with_qemu}
-# From QEMU RPMs
-Requires: /usr/bin/qemu-img
-# For image compression
-Requires: gzip
-Requires: bzip2
-Requires: lzop
-Requires: xz
-%else
-%if %{with_xen}
-# From Xen RPMs
-Requires: /usr/sbin/qcow-create
-%endif
-%endif
-%if %{with_storage_lvm}
-# For LVM drivers
-Requires: lvm2
-%endif
-%if %{with_storage_iscsi}
-# For ISCSI driver
-Requires: iscsi-initiator-utils
-%endif
-%if %{with_storage_disk}
-# For disk driver
-Requires: parted
-Requires: device-mapper
-%endif
-%if %{with_storage_mpath}
-# For multipath support
-Requires: device-mapper
-%endif
-%if %{with_cgconfig}
-Requires: libcgroup
-%endif
-%ifarch %{ix86} x86_64 ia64
-# For virConnectGetSysinfo
-Requires: dmidecode
+Requires: libvirt-daemon-config-nwfilter = %{version}-%{release}
%endif
-# For service management
-%if %{with_systemd}
-Requires(post): systemd-units
-Requires(post): systemd-sysv
-Requires(preun): systemd-units
-Requires(postun): systemd-units
-%endif
-%if %{with_numad}
-Requires: numad
+# XXX when we turn on driver modules, we need to add
+# deps on each driver (Requires: libvirt-daemon-drv-qemu)
%endif
+Requires: libvirt-docs = %{version}-%{release}
+Requires: libvirt-client = %{version}-%{release}
-# All build-time requirements
+# All build-time requirements. Run-time requirements are
+# listed against each sub-RPM
%if 0%{?enable_autotools}
BuildRequires: autoconf
BuildRequires: automake
@@ -537,6 +465,279 @@ Libvirt is a C toolkit to interact with the virtualization
capabilities
of recent versions of Linux (and other OSes). The main package includes
the libvirtd server exporting the virtualization support.
+%package docs
+Summary: Documentation for libvirt library and daemon
+Group: Development/Libraries
+
+%description docs
+Copy of the libvirt website documentation
+
+%if %{with_libvirtd}
+%package daemon
+Summary: Server side daemon and supporting files for libvirt library
+Group: Development/Libraries
+
+# All runtime requirements for the libvirt package (runtime requrements
+# for subpackages are listed later in those subpackages)
+
+# The client side, i.e. shared libs and virsh are in a subpackage
+Requires: %{name}-client = %{version}-%{release}
+
+# Used by many of the drivers, so turn it on whenever the
+# daemon is present
+%if %{with_libvirtd}
+# for modprobe of pci devices
+Requires: module-init-tools
+# for /sbin/ip & /sbin/tc
+Requires: iproute
+%if %{with_avahi}
+Requires: avahi-libs
+%endif
+%endif
+%if %{with_network}
+Requires: dnsmasq >= 2.41
+Requires: radvd
+%endif
+%if %{with_network} || %{with_nwfilter}
+Requires: iptables
+Requires: iptables-ipv6
+%endif
+%if %{with_nwfilter}
+Requires: ebtables
+%endif
+# needed for device enumeration
+%if %{with_hal}
+Requires: hal
+%endif
+%if %{with_udev}
+Requires: udev >= 145
+%endif
+%if %{with_polkit}
+%if 0%{?fedora} >= 12 || 0%{?rhel} >=6
+Requires: polkit >= 0.93
+%else
+Requires: PolicyKit >= 0.6
+%endif
+%endif
+%if %{with_storage_fs}
+Requires: nfs-utils
+# For mkfs
+Requires: util-linux-ng
+# For pool-build probing for existing pools
+BuildRequires: libblkid-devel >= 2.17
+# For glusterfs
+%if 0%{?fedora} >= 11
+Requires: glusterfs-client >= 2.0.1
+%endif
+%endif
+%if %{with_qemu}
+# From QEMU RPMs
+Requires: /usr/bin/qemu-img
+# For image compression
+Requires: gzip
+Requires: bzip2
+Requires: lzop
+Requires: xz
+%else
+%if %{with_xen}
+# From Xen RPMs
+Requires: /usr/sbin/qcow-create
+%endif
+%endif
+%if %{with_storage_lvm}
+# For LVM drivers
+Requires: lvm2
+%endif
+%if %{with_storage_iscsi}
+# For ISCSI driver
+Requires: iscsi-initiator-utils
+%endif
+%if %{with_storage_disk}
+# For disk driver
+Requires: parted
+Requires: device-mapper
+%endif
+%if %{with_storage_mpath}
+# For multipath support
+Requires: device-mapper
+%endif
+%if %{with_cgconfig}
+Requires: libcgroup
+%endif
+%ifarch %{ix86} x86_64 ia64
+# For virConnectGetSysinfo
+Requires: dmidecode
+%endif
+# For service management
+%if %{with_systemd}
+Requires(post): systemd-units
+Requires(post): systemd-sysv
+Requires(preun): systemd-units
+Requires(postun): systemd-units
+%endif
+%if %{with_numad}
+Requires: numad
+%endif
+
+%description daemon
+Server side daemon required to manage the virtualization capabilities
+of recent versions of Linux. Requires a hypervisor specific sub-RPM
+for specific drivers.
+
+%if %{with_network}
+%package daemon-config-network
+Summary: Default configuration files for the libvirtd daemon
+Group: Development/Libraries
+
+Requires: libvirt-daemon = %{version}-%{release}
+
+%description daemon-config-network
+Default configuration files for setting up NAT based networking
+%endif
+
+%if %{with_nwfilter}
+%package daemon-config-nwfilter
+Summary: Network filter configuration files for the libvirtd daemon
+Group: Development/Libraries
+
+Requires: libvirt-daemon = %{version}-%{release}
+
+%description daemon-config-nwfilter
+Network filter configuration files for cleaning guest traffic
+%endif
+
+# XXX when we turn on driver modules, we will need to
+# create daemon-drv-XXX sub-RPMs and add them as deps
+# to all of the following daemon-XXX RPMs
+
+%if %{with_qemu_tcg}
+%package daemon-qemu
+Summary: Server side daemon & driver required to run QEMU guests
+Group: Development/Libraries
+
+Requires: libvirt-daemon = %{version}-%{release}
+Requires: qemu
+
+%description daemon-qemu
+Server side daemon and driver required to manage the virtualization
+capabilities of the QEMU TCG emulators
+
+%package qemu
+Summary: Server side daemon, driver & default configs required to run QEMU guests
+Group: Development/Libraries
+
+Requires: libvirt-daemon-qemu = %{version}-%{release}
+Requires: libvirt-daemon-config-network = %{version}-%{release}
+Requires: libvirt-daemon-config-nwfilter = %{version}-%{release}
+
+%description qemu
+Server side daemon, driver and default network & firewall configs
+required to manage the virtualization capabilities of QEMU.
+%endif
+
+
+%if %{with_qemu_kvm}
+%package daemon-kvm
+Summary: Server side daemon & driver required to run QEMU guests
+Group: Development/Libraries
+
+Requires: libvirt-daemon = %{version}-%{release}
+Requires: qemu-kvm
+
+%description daemon-kvm
+Server side daemon and driver required to manage the virtualization
+capabilities of the QEMU KVM hypervisor
+
+%package kvm
+Summary: Server side daemon, driver & default configs required to run KVM guests
+Group: Development/Libraries
+
+Requires: libvirt-daemon-kvm = %{version}-%{release}
+Requires: libvirt-daemon-config-network = %{version}-%{release}
+Requires: libvirt-daemon-config-nwfilter = %{version}-%{release}
+
+%description kvm
+Server side daemon, driver and default network & firewall configs
+required to manage the virtualization capabilities of KVM.
+%endif
+
+
+%if %{with_lxc}
+%package daemon-lxc
+Summary: Server side daemon & driver required to run LXC guests
+Group: Development/Libraries
+
+Requires: libvirt-daemon = %{version}-%{release}
+
+%description daemon-lxc
+Server side daemon and driver required to manage the virtualization
+capabilities of LXC
+
+%package lxc
+Summary: Server side daemon, driver & default configs required to run LXC guests
+Group: Development/Libraries
+
+Requires: libvirt-daemon-lxc = %{version}-%{release}
+Requires: libvirt-daemon-config-network = %{version}-%{release}
+Requires: libvirt-daemon-config-nwfilter = %{version}-%{release}
+
+%description lxc
+Server side daemon, driver and default network & firewall configs
+required to manage the virtualization capabilities of LXC.
+%endif
+
+
+%if %{with_uml}
+%package daemon-uml
+Summary: Server side daemon & driver required to run UML guests
+Group: Development/Libraries
+
+Requires: libvirt-daemon = %{version}-%{release}
+# There are no UML kernel RPMs in Fedora/RHEL to depend on.
+
+%description daemon-uml
+Server side daemon and driver required to manage the virtualization
+capabilities of UML
+
+%package uml
+Summary: Server side daemon, driver & default configs required to run UML guests
+Group: Development/Libraries
+
+Requires: libvirt-daemon-uml = %{version}-%{release}
+Requires: libvirt-daemon-config-network = %{version}-%{release}
+Requires: libvirt-daemon-config-nwfilter = %{version}-%{release}
+
+%description uml
+Server side daemon, driver and default network & firewall configs
+required to manage the virtualization capabilities of UML.
+%endif
+
+
+%if %{with_xen}
+%package daemon-xen
+Summary: Server side daemon & driver required to run XEN guests
+Group: Development/Libraries
+
+Requires: libvirt-daemon = %{version}-%{release}
+Requires: xen
+
+%description daemon-xen
+Server side daemon and driver required to manage the virtualization
+capabilities of XEN
+
+%package xen
+Summary: Server side daemon, driver & default configs required to run XEN guests
+Group: Development/Libraries
+
+Requires: libvirt-daemon-xen = %{version}-%{release}
+Requires: libvirt-daemon-config-network = %{version}-%{release}
+
+%description xen
+Server side daemon, driver and default network & firewall configs
+required to manage the virtualization capabilities of Xen.
+%endif
+%endif
+
%package client
Summary: Client side library and utilities of the libvirt library
Group: Development/Libraries
@@ -582,7 +783,7 @@ Group: Development/Libraries
Requires: sanlock >= 1.8
#for virt-sanlock-cleanup require augeas
Requires: augeas
-Requires: %{name} = %{version}-%{release}
+Requires: %{name}-daemon = %{version}-%{release}
%description lock-sanlock
Includes the Sanlock lock manager plugin for the QEMU
@@ -884,6 +1085,12 @@ rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d/libvirtd.lxc
rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d/libvirtd.uml
%endif
+mv $RPM_BUILD_ROOT%{_datadir}/doc/libvirt-%{version}
$RPM_BUILD_ROOT%{_datadir}/doc/libvirt-docs-%{version}
+
+%if ! %{with_nwfilter}
+rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/nwfilter
+%endif
+
%clean
rm -fr %{buildroot}
@@ -898,7 +1105,8 @@ do
done
make check
-%pre
+%if %{with_libvirtd}
+%pre daemon
%if 0%{?fedora} >= 12 || 0%{?rhel} >= 6
# Normally 'setup' adds this in /etc/passwd, but this is
# here for case of upgrades from earlier Fedora/RHEL. This
@@ -910,22 +1118,9 @@ getent passwd qemu >/dev/null || \
-c "qemu user" qemu
%endif
-%post
+%post daemon
-%if %{with_libvirtd}
%if %{with_network}
-# We want to install the default network for initial RPM installs
-# or on the first upgrade from a non-network aware libvirt only.
-# We check this by looking to see if the daemon is already installed
-if ! /sbin/chkconfig libvirtd && test ! -f
%{_sysconfdir}/libvirt/qemu/networks/default.xml
-then
- UUID=`/usr/bin/uuidgen`
- sed -e "s,</name>,</name>\n <uuid>$UUID</uuid>,"
\
- < %{_datadir}/libvirt/networks/default.xml \
- > %{_sysconfdir}/libvirt/qemu/networks/default.xml
- ln -s ../default.xml %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml
-fi
-
# All newly defined networks will have a mac address for the bridge
# auto-generated, but networks already existing at the time of upgrade
# will not. We need to go through all the network configs, look for
@@ -991,8 +1186,8 @@ fi
%endif
%endif
-%preun
%if %{with_libvirtd}
+%preun daemon
%if %{with_systemd}
if [ $1 -eq 0 ] ; then
# Package removal, not upgrade
@@ -1007,8 +1202,8 @@ fi
%endif
%endif
-%postun
%if %{with_libvirtd}
+%postun daemon
%if %{with_systemd}
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
if [ $1 -ge 1 ] ; then
@@ -1019,6 +1214,20 @@ fi
%endif
%if %{with_libvirtd}
+%if %{with_network}
+%post daemon-config-network
+if test $1 -eq 1 && test ! -f %{_sysconfdir}/libvirt/qemu/networks/default.xml ;
then
+ UUID=`/usr/bin/uuidgen`
+ sed -e "s,</name>,</name>\n <uuid>$UUID</uuid>,"
\
+ < %{_datadir}/libvirt/networks/default.xml \
+ > %{_sysconfdir}/libvirt/qemu/networks/default.xml
+ ln -s ../default.xml %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml
+fi
+%endif
+%endif
+
+
+%if %{with_libvirtd}
%if %{with_systemd}
%triggerun -- libvirt < 0.9.4
%{_bindir}/systemd-sysv-convert --save libvirtd >/dev/null 2>&1 ||:
@@ -1064,10 +1273,19 @@ fi
/bin/systemctl try-restart libvirt-guests.service >/dev/null 2>&1 || :
%endif
-%if %{with_libvirtd}
%files
%defattr(-, root, root)
+%files docs
+%defattr(-, root, root)
+%dir %{_datadir}/doc/libvirt-docs-%{version}
+%dir %{_datadir}/doc/libvirt-docs-%{version}/html
+%{_datadir}/doc/libvirt-docs-%{version}/html/*
+
+%if %{with_libvirtd}
+%files daemon
+%defattr(-, root, root)
+
%doc AUTHORS ChangeLog.gz NEWS README COPYING.LIB TODO
%dir %attr(0700, root, root) %{_sysconfdir}/libvirt/
@@ -1078,7 +1296,6 @@ fi
%endif
%dir %attr(0700, root, root) %{_sysconfdir}/libvirt/nwfilter/
-%{_sysconfdir}/libvirt/nwfilter/*.xml
%{_sysconfdir}/rc.d/init.d/libvirtd
%if %{with_systemd}
@@ -1190,6 +1407,67 @@ rm -f $RPM_BUILD_ROOT%{_sysconfdir}/sysctl.d/libvirtd
%{_mandir}/man8/libvirtd.8*
%doc docs/*.xml
+
+%if %{with_network}
+%files daemon-config-network
+%defattr(-, root, root)
+%endif
+
+%if %{with_nwfilter}
+%files daemon-config-nwfilter
+%defattr(-, root, root)
+%{_sysconfdir}/libvirt/nwfilter/*.xml
+%endif
+
+%if %{with_qemu_tcg}
+%files daemon-qemu
+%defattr(-, root, root)
+%endif
+
+%if %{with_qemu_kvm}
+%files daemon-kvm
+%defattr(-, root, root)
+%endif
+
+%if %{with_lxc}
+%files daemon-lxc
+%defattr(-, root, root)
+%endif
+
+%if %{with_uml}
+%files daemon-uml
+%defattr(-, root, root)
+%endif
+
+%if %{with_xen}
+%files daemon-xen
+%defattr(-, root, root)
+%endif
+
+%if %{with_qemu_tcg}
+%files qemu
+%defattr(-, root, root)
+%endif
+
+%if %{with_qemu_kvm}
+%files kvm
+%defattr(-, root, root)
+%endif
+
+%if %{with_lxc}
+%files lxc
+%defattr(-, root, root)
+%endif
+
+%if %{with_uml}
+%files uml
+%defattr(-, root, root)
+%endif
+
+%if %{with_xen}
+%files xen
+%defattr(-, root, root)
+%endif
%endif
%if %{with_sanlock}
--
1.7.7.6
2 p.m.
On 03/30/2012 12:53 PM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange(a)redhat.com>
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'
I did a successful "make rpm" on Fedora 16, which resulted in 21 rpm's
(including the source rpm).
When I tried to update using rpm -U, I was told that I didn't have the
required "qemu" and "xen" packages installed (not surprising, since I
never use them). Installing qemu cost 52MB on my disk, and xen another
27. This isn't a bother to me, but I suppose it could be for someone who
was trying to make images as small as possible. On the other hand, that
person will just need to start using the "libvirt-kvm" package instead
of "libvirt".
I guess the only concern I have left is whether or not this change in
package grouping will create any unsavory situations when somebody upgrades.
(there are a few lines in the docs that are still > 80 characters (for
some reason, all of them end in "binaries")).
Beyond that, it all looks good to me and I'm willing to give my ACK for
what it's worth, but I think it would be a "very good idea" to have it
looked over by someone with a better knowledge of specfiles than mine.
2:30 p.m.
On Fri, Mar 30, 2012 at 03:00:03PM -0400, Laine Stump wrote:
On 03/30/2012 12:53 PM, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange" <berrange(a)redhat.com>
>
> 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'
I did a successful "make rpm" on Fedora 16, which resulted in 21 rpm's
(including the source rpm).
When I tried to update using rpm -U, I was told that I didn't have the
required "qemu" and "xen" packages installed (not surprising, since
I
never use them). Installing qemu cost 52MB on my disk, and xen another
27. This isn't a bother to me, but I suppose it could be for someone who
was trying to make images as small as possible. On the other hand, that
person will just need to start using the "libvirt-kvm" package instead
of "libvirt".
I assume that is because you did 'rpm -Uvh *.rpm', which means it
would have included libvirt-qemu and libvirt-xen which in turn
dep on 'qemu' and 'xen' respectively. If you had merely asked to
install 'libvirt', it would not have required libvirt-qemu or
libvirt-xen.
To clarify the dependancy chain is this:
libvirt -> libvirt-daemon, libvirt-config-network, libvirt-config-nwfilter
libvirt-daemon-qemu -> libvirt-daemon, qemu
libvirt-daemon-kvm -> libvirt-daemon, qemu-kvm
libvirt-daemon-xen -> libvirt-daemon, xen
libvirt-qemu -> libvirt-daemon-qemu, libvirt-config-network, libvirt-config-nwfilter
libvirt-kvm -> libvirt-daemon-kvm, libvirt-config-network, libvirt-config-nwfilter
libvirt-xen -> libvirt-daemon-xen, libvirt-config-network
Notice there is no direct dep from 'libvirt' to 'qemu' or 'xen',
only
from the libvirt-qemu RPMs, which are not required by anything else.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
2:57 p.m.
On 03/30/2012 03:30 PM, Daniel P. Berrange wrote:
On Fri, Mar 30, 2012 at 03:00:03PM -0400, Laine Stump wrote:
> On 03/30/2012 12:53 PM, Daniel P. Berrange wrote:
>> From: "Daniel P. Berrange" <berrange(a)redhat.com>
>>
>> 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'
> I did a successful "make rpm" on Fedora 16, which resulted in 21 rpm's
> (including the source rpm).
>
> When I tried to update using rpm -U, I was told that I didn't have the
> required "qemu" and "xen" packages installed (not surprising,
since I
> never use them). Installing qemu cost 52MB on my disk, and xen another
> 27. This isn't a bother to me, but I suppose it could be for someone who
> was trying to make images as small as possible. On the other hand, that
> person will just need to start using the "libvirt-kvm" package instead
> of "libvirt".
I assume that is because you did 'rpm -Uvh *.rpm', which means it
would have included libvirt-qemu and libvirt-xen which in turn
dep on 'qemu' and 'xen' respectively. If you had merely asked to
install 'libvirt', it would not have required libvirt-qemu or
libvirt-xen.
You assume correctly. I had always (incorrectly) assumed that rpm -U
would only update the machine rpms that were already installed. I'd
never actually checked.
So everything with this change seems okay to me.
5:40 p.m.
On 03/30/2012 10:53 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange(a)redhat.com>
There are a number of flaws with our packaging of the libvirtd
daemon:
+
+%if %{with_libvirtd}
+%package daemon
+Summary: Server side daemon and supporting files for libvirt library
+Group: Development/Libraries
+
+# All runtime requirements for the libvirt package (runtime requrements
+# for subpackages are listed later in those subpackages)
+
+# The client side, i.e. shared libs and virsh are in a subpackage
+Requires: %{name}-client = %{version}-%{release}
+
+# Used by many of the drivers, so turn it on whenever the
+# daemon is present
+%if %{with_libvirtd}
You've now nested %if %{with_libvirtd} twice; this could be simplified,
but cleanups can be saved for another day if we are under the gun to get
this out now (is there a cppi equivalent for spec files to help show
nesting? Can you even indent %if directives for sanity in a spec file?)
+# for modprobe of pci devices
...
+# For glusterfs
+%if 0%{?fedora} >= 11
+Requires: glusterfs-client >= 2.0.1
+%endif
+%endif
+%if %{with_qemu}
+# From QEMU RPMs
+Requires: /usr/bin/qemu-img
Should this Requires: be pushed down to libvirt-daemon-qemu...
+# For image compression
+Requires: gzip
+Requires: bzip2
+Requires: lzop
+Requires: xz
+%else
+%if %{with_xen}
+# From Xen RPMs
+Requires: /usr/sbin/qcow-create
and this one to libvirt-daemon-kvm?
But I can live with them here.
...
+# For virConnectGetSysinfo
+Requires: dmidecode
+%endif
+# For service management
+%if %{with_systemd}
+Requires(post): systemd-units
+Requires(post): systemd-sysv
+Requires(preun): systemd-units
+Requires(postun): systemd-units
These four requires deal with services, but we already pushed services
into libvirt-daemon-config-network; I'm guessing these should be
relocated to that section.
Or maybe I'm misunderstanding - is it that these enable libvirtd to run
as a service, but libvirtd will do nothing to cause interference (like
trying to set up the 'default' NAT network at 192.168.122.0) unless you
also have the config files? In that case, what you did looks okay.
+%endif
+%if %{with_numad}
+Requires: numad
+%endif
+
+%description daemon
+Server side daemon required to manage the virtualization capabilities
+of recent versions of Linux. Requires a hypervisor specific sub-RPM
+for specific drivers.
It looks weird to have the %description so far down from the %package
with all the Requires in between. But that's cosmetic.
I spotted a few things you can clean up, but nothing was a show-stopper
to pushing this as-is, so you have my ACK.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
6:18 a.m.
On Fri, Mar 30, 2012 at 04:40:09PM -0600, Eric Blake wrote:
On 03/30/2012 10:53 AM, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange" <berrange(a)redhat.com>
>
> There are a number of flaws with our packaging of the libvirtd
> daemon:
>
> +
> +%if %{with_libvirtd}
> +%package daemon
> +Summary: Server side daemon and supporting files for libvirt library
> +Group: Development/Libraries
> +
> +# All runtime requirements for the libvirt package (runtime requrements
> +# for subpackages are listed later in those subpackages)
> +
> +# The client side, i.e. shared libs and virsh are in a subpackage
> +Requires: %{name}-client = %{version}-%{release}
> +
> +# Used by many of the drivers, so turn it on whenever the
> +# daemon is present
> +%if %{with_libvirtd}
You've now nested %if %{with_libvirtd} twice; this could be simplified,
but cleanups can be saved for another day if we are under the gun to get
this out now (is there a cppi equivalent for spec files to help show
nesting? Can you even indent %if directives for sanity in a spec file?)
Yes, i'll kill that nesting.
> +# for modprobe of pci devices
...
> +# For glusterfs
> +%if 0%{?fedora} >= 11
> +Requires: glusterfs-client >= 2.0.1
> +%endif
> +%endif
> +%if %{with_qemu}
> +# From QEMU RPMs
> +Requires: /usr/bin/qemu-img
Should this Requires: be pushed down to libvirt-daemon-qemu...
This is used by the storage driver, which is shared amongst
xen, qemu, libxl, lxc & uml hypervisor drivers.
> +# For image compression
> +Requires: gzip
> +Requires: bzip2
> +Requires: lzop
> +Requires: xz
> +%else
> +%if %{with_xen}
> +# From Xen RPMs
> +Requires: /usr/sbin/qcow-create
and this one to libvirt-daemon-kvm?
Likewise, shared.
> +# For virConnectGetSysinfo
> +Requires: dmidecode
> +%endif
> +# For service management
> +%if %{with_systemd}
> +Requires(post): systemd-units
> +Requires(post): systemd-sysv
> +Requires(preun): systemd-units
> +Requires(postun): systemd-units
These four requires deal with services, but we already pushed services
into libvirt-daemon-config-network; I'm guessing these should be
relocated to that section.
Or maybe I'm misunderstanding - is it that these enable libvirtd to run
as a service, but libvirtd will do nothing to cause interference (like
trying to set up the 'default' NAT network at 192.168.122.0) unless you
also have the config files? In that case, what you did looks okay.
I only pushed the install of the network XML into the daemon-config-network
RPM. There is still a '%post daemon' section which deals with the init
scrpits which is what these requires are for.
> +%endif
> +%if %{with_numad}
> +Requires: numad
> +%endif
> +
> +%description daemon
> +Server side daemon required to manage the virtualization capabilities
> +of recent versions of Linux. Requires a hypervisor specific sub-RPM
> +for specific drivers.
It looks weird to have the %description so far down from the %package
with all the Requires in between. But that's cosmetic.
This is layout normal practice - it just looks a bit wierd because we
have soooo many requires.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
12:55 a.m.
On Fri, Mar 30, 2012 at 05:53:19PM +0100, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange(a)redhat.com>
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
like ? configuration files should by definition be under
/etc/libvirt, how can they cause problems to something else ?
- It is not possible to explicitly required all the peices
required to manage a specific hypervisor
yes you require the hypervisor and libvirt, where is the actual
problem ? I don't see how:
Requires: xen
Requires: libvirt
is any worse than
Requires: libvirt-daemon-xen
Requires: libvirt
can you explain ?
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
So people who used to install libvirt and be all set will now wonder
why x y and z features don't work anymore. I don't see the service to
the users here.
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
To be honnest I don't like this, I discover the 20 or so rpms being
built now, most of them empty. If there is a dependancy problem I
would have hoped we could fix this by a different way than a *physical*
empty rpm (they are definitely not virtual as they are built and seems
to be needed for proper setup).
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.
Then making the split will be fine, but that would depend on the
decision to activate the driver modules, which is not the case now.
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'
I have a hard time believing that we have a good justification to
break all the "clients" rpms and tools.
I see very little in terms of justification for such a huge change
and pushing this 2 days before the release, I'm very tempted to roll
this back (I didn't see this coming, sorry I was sick, and didn't
monitor properly, still that's a big change and very late for this
release)
At least I don't see any user feeback indicative that such a complete
overhaul was urgent and to be pushed just before the release without
any testing.
NACK from my POV, at least not at this stage !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
3:37 a.m.
On Tue, Apr 03, 2012 at 01:55:32PM +0800, Daniel Veillard wrote:
On Fri, Mar 30, 2012 at 05:53:19PM +0100, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange" <berrange(a)redhat.com>
>
> 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
like ? configuration files should by definition be under
/etc/libvirt, how can they cause problems to something else ?
The scenario is this:
- Fedora 17 LiveCD includes GNOME Boxes by default
- GNOME Boxes dependancy on libvirtd pulls in configs
- Libvirtd is set to autostart on boot
- User boots LiveCD in a virtual machine
- LiveCD is given an address in 192.168.122.0/24
- libvirtd in the guest starts and activates the default
network config, which has an address 192.168.122.0/24
Kaboom, you now have broken networking in the guest.
The second scenario is where libvirt is used by oVirt
or OpenStack. They (and many other users) have long
complained that they don't want virbr0 to be pulled
into their installs.
Both of these scenarios mean we need to make it possible to
install libvirtd, without providing any of the config files.
The reason for splitting the RPM with network vs nwfilter
config files, so that some applications (OpenStack) *do*
still want the nwfilter config files to be present.
> - It is not possible to explicitly required all the peices
> required to manage a specific hypervisor
yes you require the hypervisor and libvirt, where is the actual
problem ? I don't see how:
Requires: xen
Requires: libvirt
is any worse than
Requires: libvirt-daemon-xen
Requires: libvirt
You would not actually want the 'Requires libvirt' line
here at all - that would pull in everything - as it does
today. You *only* want the 'libvirt-daemon-xen' RPM,
which will pull in just the parts required to run Xen.
Much of this split was design to be forward looking to the
next change to actually use dlopen'd loadable modules in
libvirtd. So the 'libvirt-daemon-xen' RPM will depend on
the set of .so libraries required to run Xen.
So the difference between the two examples you give is
- No longer need to explicitly add a dep on 'xen' in application
RPMs
- Only the Xen parts of libvirt get installed - not the KVM
driver code. This means that auto-probing of the URIs should
enable Xen as expected, and not enable KVM.
> 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
So people who used to install libvirt and be all set will now wonder
why x y and z features don't work anymore. I don't see the service to
the users here.
No you mis-understand. If you do 'yum install libvirt' you get
*exactly* the same stuff installed as you have always done. ie
you get everything. I absolutely did *not* want to break the
upgrade path for people who already have libvirtd installed.
People who want a smaller install, would *not* depend on libvirt
anymore, but rather one of the hypervisor specific sub-RPMs.
> 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
To be honnest I don't like this, I discover the 20 or so rpms being
built now, most of them empty. If there is a dependancy problem I
would have hoped we could fix this by a different way than a *physical*
empty rpm (they are definitely not virtual as they are built and seems
to be needed for proper setup).
> 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.
Then making the split will be fine, but that would depend on the
decision to activate the driver modules, which is not the case now.
> 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'
I have a hard time believing that we have a good justification to
break all the "clients" rpms and tools.
We have not broken anything - that was an absolutely critical goal.
The upgrade path is 100% preserved. The new fine-grained RPM installs
deps are a opt-in for applications - if they do not want to take
advantage of this, they can go on having a dep on 'libvirt' and get
no change in behaviour.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
4616
days inactive
4620
days old
7 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Eric Blake -
Laine Stump