On Wed, Jan 03, 2007 at 10:27:03AM -0500, Jeremy Katz wrote: > On Wed, 2007-01-03 at 15:11 +0000, Daniel P. Berrange wrote: > > Since KVM is the new "shiny thing" in the virtualization world for Linux I > > figure its time to resurrect & finish the prototype QEMU backend I started > > developing for libvirt. Thanks to the design of KVM, it ought to be possible > > to support KVM & QEMU in a single driver with near-zero extra effort to add > > the bits for KVM support. > > Note that KVM can conceivably be used with something other than qemu as > the device model. Although there isn't anything else currently doing > so, someone on the kvm list is working on something. Also, there is > some investigation underway on ways to do some paravirt with KVM. Well KVM with a non-QEMU driver model would require a different libvirt backend, because the manner of starting/stoppping/managing the driver model would be completely different. So in this scenario we're only really interested in differentiating the different means of using QEMU itself, of which KVM is one option. > [snip] > > 1. Use the <type> element within the <os> block to describe the > > CPU accelerator to use, accepting the values 'qemu', 'kvm', > > 'kqemu' or 'qvm86'. > > Given the above, I'd lean a bit towards doing something like > <type accel="kvm">qemu</type> > > instead. This feels a little bit more consistent with the rest of the > proposal. Having the contents of <type> always be 'qemu' is a little redudant, since we already specify 'qemu' as the guest type in the top-level XML element. I see 'type' as referring the to virtualization strategy for the driver backend, eg Xen has 'linux' or 'hvm' approaches. QEMU has 'qemu', kvm or kqemu approaches. 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 -=|