7:43 a.m.
On Wed, Apr 12, 2006 at 04:25:49AM -0400, Daniel Veillard wrote:
On Wed, Apr 12, 2006 at 04:08:53AM +0100, 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:
The 2 first scenarios assume the passive domains are stored on the
disk. This doesn't has to be the case, libvirt could just cache those
informations in the management tool memory, also xenstore is acessed via
RPC, those might be extended for remote machines.
> * 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.
In general I agree that reliance on some filesystem storage for them
is a serious problem.
I'm not refering to any particular storage mechanism for libvirt - that's
a backend implementation detail. I'm questioning whether it is relevant at
all & what the semantics are for various use cases & what the value of such
an API is for applications which might need such capabilities.
If the inactive domains are stored in some higher level descriptive format
rather than the raw domain XML defintion, any list of inactive domains configs
would always be empty. So what is the value to an application, if an API for
'list inactive domains' returned an empty list in 50% of common uses ?
> 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.
No that could work too if libvirt used to manage remote domains from a
centralized location and keep the passive domain definitions on that
centralized server.
This central management server could have an arbitrary backend for storing
its master list of inactive domains, in a potentially application specific
model. What would the value be in having the application take all these
definitions from its master storage & convert their format & load them into
libvirt - its just introduced a large burden on the application to ensure
that its master store is always in sync with what it has loaded into libvirt
- with no clear benefit for the application, since its still going to want to
operate on its master store, not the denormalization. It has not obviously
helped application inter-operability either, because the domains loaded into
libvirt on the management server, would not be visible to an application
using libvirt on the remote host itself.
> 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.
The need comes from the second one, this is part of the CIM model.
Its hard to reconcile the needs without knowing the conceptual requirements
of the CIM model, rather than just an API implementation requirements. While
I can see the value in CIM using libvirt to getting information on active
domains since there is a very clear semantic & representational model which
is not application specific. This is not true of inactive domains, since if
you get ito any more detail than just 'there is an inactive domain with a
UUID XYZ', you'd really be imposing an arbitrary representational model on
applications using the UI that may make no sense for them.
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 -=|