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 :|