[libvirt] [RFC PATCH 0/4] Implementation of a dependency relation between domains

Daniel P. Berrange berrange at redhat.com
Wed Mar 23 09:51:20 UTC 2016


On Wed, Mar 23, 2016 at 09:55:18AM +0100, Valentin BOUSSON wrote:
> This patch series adds a feature that enables libvirt domains to have other
> domains as dependencies.
> 
> One possible target is the simulation of a complex computing system composed of
> multiple CPUs, each of which represented by a different libvirt domain. CPUs in
> this example are virtualized separately, by a dedicated QEMU instance, because
> all of them are booting independently. Moreover, if those CPU must share some
> physical property (for example power supply or ACPI), it is meaningful to
> consider them as a group.
> 
> Another possible target is Asymmetric Multi Processor (AMP) systems. Where a
> master processor uses one or more slave processors to offload computation.
> Master and slave have often different architectures.  This patch series makes
> possible to define the slave domains as dependencies of the master domain. And
> the whole system to be booted with one single libvirt command.
> 
> A use-case for this libvirt extension are the recent patch series in QEMU that
> enable modeling an AMP-like system with multiple QEMU instances.

[snip]

I wish you had raised this for discussion before spending time & effort to
implement it :-(

Personally I don't really think this kind of thing belongs in libvirt at all.
In any non-trivial system there are going to be dependancies on more than
just domains having been started. For example, dependancies on networking or
firewall setup. There may also be dependancy on actually waiting for the guest
OS to startup.

So in general I think this is the kind of thing belongs in the higher level
management applications like oVirt and OpenStack which have visibility into
the entire picture.

This really goes back to our mantra that libvirt provides the mechanism only,
while the application using libvirt provides the policy. Startup ordering
between domains really is policy, not mechanism.


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




More information about the libvir-list mailing list