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