On Wed, Jan 03, 2007 at 11:29:48AM -0500, Daniel Veillard wrote: > On Wed, Jan 03, 2007 at 04:06:29PM +0000, Daniel P. Berrange wrote: > > accelerated, with all the others just being software emulated. As per my > > other reply to Jeremy, I felt <type> to be refering to the virtualization > > strategy for the backend, and so implementation specific. For Xen world > > we have 'linux' or 'hvm', while for QEMU world we have the different 'qemu' > > 'kvm', 'kqemu' options. > > and 6 months from now people will start developping special paravirt drivers > and kernel for KVM (those kernel guys won't resist shaving 5% of performances > sooner or later :-) and then you will run a specific os type in a kvm > <domain type="kvm"> > <os> > <type>linux</type> > > will then be just fine. But if we override the os/type value now with something > which is not realated to the running os we will loose consistency later. Sorry > I'm still disagreeing, I really prefer to see > <domain type="qemu"> > <domain type="kvm"> > <domain type="kqemu"> > and keep a generic value in <os> <type> as long as the actual OS is indifferent > but still have provision to indicate a specific one there later if needed. Ok, given the possiblilty of doing a paravirt guest using QEMU+KVM + paravirt_ops, then it does sound reasonable to use the top level 'type' attribute to specify the different virtualization approach. 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 -=|