On 9/8/07, Fernando Cassia <[EMAIL PROTECTED]> wrote: > Point #3: Xen vs KVM... I'm confused > > The above move by RedHat is a bit confusing... what can Xen do that KVM > cannot?. In other words, why should anyone even bother with Xen with KVM > around ??.
Xen is probably more mature, and has more more management tools. Plus it's already known and deployed in the enterprise world. On the downside Xen is big, while KVM is simpler. > I've read Xen is "more robust" because it has a "one year lead" > over KVM. But really, how does this translate, if performance of Xen could > be worse due to more paravirtualization?. Paravirtualization is not a bad thing ;-) If you cannot modify the guest then of course a fully virtualized VM is needed, but if you can modify it (by e.g. loading a special driver) then PV is likely to give some speed enhancements. The first obvious area for PV is device drivers: emulating a network card (or a disk controller, or...) wastes a lot of cycles, it makes lots of sense to use a special driver virtualization-aware driver that speeds up the communication between the guest and the host. VirtIO for example is all about flipping pages between guest and host. Another class of operations the can be PVirtualized are privileged instructions that may affect the global state of the machine. E.g. you don't want the guest to be able to _really_ turn interrupts off; instead you trap the 'cli' and stop sending interrupts to it. If the guest is aware of the virtualization it can politely ask the guest to stop interrupt delivery (instead of going through trap+emulate). ATM Linux supports the paravirt_ops infrastructure that covers interrupts delivery, page table / MMU management, APIC, MSR (and maybe other stuff). This second class of PV ops requires modification of core parts of the guest operating system; while it's certainly possible to create a win32 driver for e.g. a PV network card it's impossible to do the same for paravirt_ops. > Or is Xen more optimized to > provide the "greatest possible consolidation" on servers (ie less resource > usage, less impact on cpu usage of a high number of VMs?). Xen supported paravirt-only guest, but gained support for full virtualization. KVM started as full virtualization solution but is now gaining PV support (at least for network and block devices - I think kvm-lite will go further). > Finally... after reading about Xen and KVM(this KVM, not Sun's ;), I > wonder... the FAQ says Xen does more paravirtualization, whereas KVM uses > the CPU's own virtualization features. Yet I visit some articles like this > one > > http://aplawrence.com/Linux/kvm_virtualization.html > > which claims that Xen is "THE FASTEST" approach to virtualization. How can > it be faster since it uses paravirtualization (software) instead of direct > hardware virtualization features as KVM? See above. Doing software _emulation_ of the guest is slow. A PV guest can coordinate very efficiently with the host. Luca ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel