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