[Libvir] [RFC] Life-cycle Management of the domain take2

[Daniel P. Berrange]

On Wed, May 16, 2007 at 03:28:14PM +0900, Saori Fukuta wrote:
> Hi,
> 
> Thank you for your comment.
> 
> On Fri, 11 May 2007 19:29:48 +0100 "Daniel P. Berrange" wrote:
> > On Fri, May 11, 2007 at 07:15:33PM +0100, Daniel P. Berrange wrote:
> > > 
> > > If the guest was created by libvirt, then I consider it a bug if the XML
> > > dump does not allow re-creation in exact same config. 
> > > 
> > > If the guest was created by non-libvirt app, then there may be some xen 
> > > specific bits we don't support in libvirt. So be it - there are some things
> > > we simply don't want to support. For any of the latter  case, we can at 
> > > least evaluate whether it makes sense to support them throughout libvirt,
> > > and/or accept patches.
> 
> That means the libvirt basically supports a guest that was created by libvirt
> ( or virt-install ), right ?

That is almost correct. We support management of guests that were created by
non-libvirt based applictions - if the config options they used are capable
of being expressed in terms of libvirt XML.

> I think that would be a waste because we would miss an opportunity to get 
> new customers. I personally want to support the guest was created by non-libvirt
> app too.

That is almost correct. We do support management of guests that were created 
by non-libvirt based applictions - if the config options they used are capable
of being expressed in terms of libvirt XML.

Now there are certainly a number of Xen configuration options that we don't
currently support in libvirt. We've perhaps got the 75% common case that 
people use. I don't think we'll ever get 100% because there are some things
that are really very Xen specific, but that shouldn't stop us aiming to 
improve our coverage. There's plenty of scope for more work to let us deal
with 95%+ of the Xen config options. IMHO, not hitting the remaining few %
is a worthwhile tradeoff given the huge benefits of having a config representation
which isn't tied to Xen, particularly if that remaining 5% is the type of
niche edge case config rarely used.

As always, I'd welcome suggestions & patches for representing more of the Xen
config options in the generic XML format. The obvious big outstanding areas
we've currently got are, USB (we've already agreed on format, now just need
to implement it),  serial/parallel devices (cf other thread suggesting a way
to represent it),  sound devices (no suggestions yet, but several end-user
feature requests).

Regards,
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  -=|