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

Reply via email to