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