[Libvir] Request for additional entry points

[Anthony Liguori]

Daniel P. Berrange wrote:
> On Fri, Mar 31, 2006 at 04:47:38PM -0500, Daniel Veillard wrote:
>   
>> On Fri, Mar 31, 2006 at 10:56:06AM -0700, Jim Fehlig wrote:
>>     
>>> As discussed on the xen-cim call on 3/31, the Xen CIM provider needs 
>>> some additional entry points in libvirt.  I would like to open a 
>>> discussion about adding the following entry points to libvirt.
>>>
>>> virDomainSetConfig(virConnectPtr conn, const char *xmlDesc)
>>> Stores the domU config data in xenstore.  The domU is not running yet 
>>> but enumerating domains would return the config for the domain as well 
>>> as any running domains.  This would support the notion of a defined but 
>>> inactive virtual machine.  Daniel noted that the config could be cached 
>>> in libvirt, preventing (to some degree) modifying the config out-of-band 
>>> prior to activating the domain.  Note that the current 
>>> virConnectListDomains() implies enumerating only running domains since a 
>>> list of domain IDs is returned.  Perhaps virConnectListDomains() will 
>>> have to be expanded to include defined domains or another entry point to 
>>> enumerate defined domains.
>>>       
>>   Well libvirt doesn't have the notion of 'passive' domain yet, i.e. domain
>> we know exists but are not running or activated at a given point in time.
>> If we define virDomainSetConfig() then we have to be able to extract at least
>> the name (and uuid) from the xmlDesc. And that routine could then returm
>> a virDomainPtr associated to this unactive domain (or the associated 
>> active domain if it exists). Those unactive domains could then be listed
>> in virConnectListDomains(). In general libvirt doesn't yet create a unique 
>> proxy object per running domain, the unicity need to be garanteed, it's a TODO
>> and add other constraints like reference counting and mutex when modifying
>> a domain.
>>     
>
> 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.

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.

Regards,

Anthony Liguori

>  * 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.
>