[Libvir] Request for additional entry points

Thu Apr 13 18:42:06 UTC 2006

On Wed, Apr 12, 2006 at 11:51:53AM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >I'd actually question whether libvirt should have any concept of 'passive'
> >or 'inactive' domains at all. Just to play out a few scenarios:
> >  
> 
> We've discussed this before and I think the most compelling argument for 
> passive domain support in libvirt (and even at a lower level such as 
> Xend) is the following scenario:
> 
> Let's say a user creates a virtual FC6 virtual machine that she is going 
> to use to test her apps under Gnome (she's a KDE user).  The machine 
> isn't always there b/c she rarely needs it.  She created it with some 
> nifty KDE tool that has yet to be written.
> 
> Of course, she finds out about this neat applet that you can use to 
> managing running domains.  If there isn't a common way of accessing 
> passive domains then she won't see the FC6 VM.

Indeed, that interoperability is the core problem, however, I think that 
solving it higher up the stack could result in a more flexible & effective
solution. Even if the solution is not part of libvirt, there is still
plenty of scope for defining a standard way to enumerate & interact with
passive domains. 

Storing the passive domains in libvirt in the low-level XML format
will mean that the KDE virt tool will need to either manage all its
passive domains in the libvirt XML format, or maintain a denormalization
of its real persistent format & keep that synced with libvirt, neither
of which are particularly nice. 

So say, the Virt Applet finds out about the passive domain 'Gnome test'
that was creted with the KDE virt tool, and wants to present a drop down
menu allowing the user to run it. Now it could get the XML def for the
passive domain from a registry in libvirt, and then pass it backk to
libvirt's create domain method - bypassing the original KDE virt tool 
which defined the domain. This would all work fine, however, it does
constrain what you can do when starting the domain.

For example, consider that the original KDE virt tool also has some idea
of policy to mediate between different VMs running on the host. WIth the
applet getting the config & launching the domain directly via libvirt, the
KDE tool is now cut out of the loop - it can merely *react* to the newly
started domain.

An alternate model for dealing with passive domains could revolve around
the provision of a standardized DBus service API, org.example.virt.Manager.
At its simplest, this could contain two APIs, 'list inactive domains' and
'start domain'. So the applet can obtain a list of inactive domains and 
present them in a menu allowing a user to choose one to start. When the
user asks the applet to start one, the applet can call the 'start domain'
method in the service. 

At the other end of the picture, the KDE virt tool would provide an
implementation of the org.example.virt.Manager DBus service. Thus the
applet's request to start the 'Gnome test' domain gets routed to the
KDE tool, which in turn talks to libvirt passing down the raw XML 
description of the domain.

The virt tool now has much more flexibility in how it deals with passive
domains. For example, it can maintain its master list of passive domains
in any format it likes - it might like to separate out its definition of 
the domain's hardware (# of CPUs, # of NICS, MAC addresses), from the
definition of policy (CPU priority, schedular settings, amount of memory).
If starting the new domain would over-commit on the host's resources, the
tool can now pro-actively suspend, pause  or shutdown other domains, or
give the user the option to reduce the memory for the new domain before 
starting. 

The virt tool could now even be fetching its list of inactive domain on
demand from an external source. Or if one has an external management server,
one could drop in an alternate implementation of the org.example.virt.Manager
DBus service, which talks to this remote server. Thus the applet would 
transparently be listing & activating domains which are defined & managed
remotely from the host itself. Going back to the original problem, the
CIM provider would also be able to trivially talk to the local DBus service
to get the listing of passive domains.

> Now, I don't think that *all* domains should have to have passive 
> equivalents (which is a requirement in the CIM provider today) because 
> of some of the scenarios you outlined.  However, I think not attempting 
> to have a common API for passive domains is going to creative a mess as 
> we get a larger number of management tools.

I defintely agree with the need for formalizing an API for dealing with
passive domains, just not neccessarily from within libvirt, since it
puts applications into a low level straight jacket of 'list domains' & 
'start this domain config', preventing the more interesting interactions
between both UI applications & other components such as virt policy
service all of which run higher up the stack where libvirt has pretty
limited visibility.

Regards,
Dan.

> 
> > * Definitions of inactive domains are stored on a remote server, libvirt
> >   has no visibilty into this system. virDomainSetConfig() would not help
> >   since there is no concept of a domain being inactive on a single host,
> >   rather inactive domains can be deployed to any host in the server farm
> >   at will.
> >
> > * Definitions are visible on the local filesystem, but this FS is shared
> >   NFS / SAN storage. Again while their config files may be technically
> >   visible via the shared filesystem, there is no meaningful association
> >   between an inactive config & a host.
> >
> > * Domains are created from config 'templates'. The template defines a
> >   generic resource configuration, turned into a fully fledged config
> >   on-demand - perhaps with the variables plugged into the template
> >   coming from an alternate datastore (SQL databsae perhaps). In this
> >   case there would be no sense in storing pre-made XML configs, since
> >   the master info is a combo of the template & SQL database entries.
> >
> >So, really the only case where there is any meaningful concept of 'passive'
> >domain configs associated with a static single host model - for example 
> >that
> >provided by XenD which happen to have a simple store of inactive domains
> >in /etc/xen. There are so many other interesting management scenarios where
> >inactive domains don't really have a persistent association with a single
> >host, or indeed any passive configuration at all, that I'm not sure there
> >would be much value in libvirt to representing passive domains at all.
> >
> >Thinking about what tools might need information on inactive domains:
> >
> > - Desktop management tool - cf VMWare Workstation. Possibly, but even
> >   here there is no reason such a tool represents inactive domains in
> >   terms of a libvirt XML config file. It may well have generic templates
> >   eg 'Linux Web Server  and instances 'web0.google.com', 
> >   'web1.google.com',
> >   'web2.google.com', where the only instance specific data is the hostname
> >   and master disk image.
> >
> > - Data center management tool - it may well have a concept of inactive
> >   domain configs, but it almost certainly won't be associated with a
> >   single host, so unlikely to be asking libvirt to list inactive domains. 
> >
> >I struggle to think of cases where libvirt would need to provide info on
> >inactive domains, which are not distorted to serve the needs of a specific 
> >application's representational model. If a local app wants to maintain
> >a local list of config files for inactive domains, let it do so itself.
> >
> >Dan.
> >  
> 

-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 