Re: Intel-only or AMD Opteron as well?

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

On Sat, 2007-09-08 at 19:01 +0200, Luca wrote:
> On 9/8/07, Fernando Cassia <fcassia-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.

Keep in mind, the referenced article is very old (it's from February).

> >  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).

One thing to keep in mind is that in this example, hardware
virtualization eliminates the need to trap and emulate cli/sti.

In general, there are two classes of paravirtualizations. The first are
related to functionality on non-virtualization aware hardware (32-bit
startup, cooperative descriptor table management, memory hole, etc.).
The second class would be optimizations which includes things like page
table update batching, paravirtual device drivers, etc.

KVM is beginning to get the second class of optimizations.  Once they
are in place and mature, my expectation is that it will outperform
things like Xen.  Hardware virtualization is probably a lot faster than
something that relies on only the first class of paravirtualizations. 

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

Well, it's not really that simple.  There are some things Xen is very
slow at (especially with 64-bit guests).

The best thing to do when trying to decide which virtualization solution
to use is to evaluate all options for the workloads you're interested
in.

Regards,

Anthony Liguori

> 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel


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