This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-users] who comes from kvm?

To: "Steve Sapovits" <steves06@xxxxxxxxxxx>, "Javier Guerra Giraldez" <javier@xxxxxxxxxxx>
Subject: RE: [Xen-users] who comes from kvm?
From: "Phil Winterfield (winterfi)" <winterfi@xxxxxxxxx>
Date: Mon, 14 Feb 2011 09:47:49 -0800
Authentication-results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none
Cc: xen-users@xxxxxxxxxxxxxxxxxxx, Bhasker C V <bhasker@xxxxxxxxxxxxx>
Delivery-date: Mon, 14 Feb 2011 09:49:07 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
Importance: low
In-reply-to: <4D587270.3090607@xxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Priority: Non-Urgent
References: <AANLkTingMyaA5sLcbTM3NWW3NwAtVc6=fcwzEiw=znMA@xxxxxxxxxxxxxx> <4D5570CE.4090608@xxxxxxxxxxx> <AANLkTi=c=EVPojcNR35N5GL_PD0stV397DWETJ9F_O6O@xxxxxxxxxxxxxx> <alpine.DEB.1.10.1102122242400.12308@xxxxxxxxxxxxxxxxxxxxxxx> <4D583DA0.9050507@xxxxxxxxxxx><AANLkTim1f8T+xNf1cQDgCDAfeFU9UmC54FFO1V_jA09_@xxxxxxxxxxxxxx> <4D587270.3090607@xxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcvL25RdTuA5cFj5RamfvFRSb4fzYQAkeNlA
Thread-topic: [Xen-users] who comes from kvm?
In the discussion of whether KVM is a type 1 or type 2 hypervisor, it is 
important to remember that KVM, by allowing driver code to be moved into the 
address space of the hypervisor, is violating one key tenets of having 
hypervisors in the first place.  Driver code is notoriously buggy and by 
allowing it to share the address space of the hypervisor you have greatly 
expanded the vulnerability and attack surface for the most important part of 
your system.  KVM has dramatically increased the chances of catastrophic system 
failure by violating one of the fundamental architectural principles that has 
guided the design of hypervisors since IBM originated the original concepts in 
the '60's.  If reliability, availability and security are important to you, 
then Xen is a much better choice from an architectural standpoint.

Phil Winterfield

> On 2/13/2011 6:45 PM, Javier Guerra Giraldez wrote:
> > Just to clarify, my comment was about the characterization of KVM as
> a
> > type 2 hypervisor.  it's not.
> Maybe it's a 1.5?  8-)  I've seen the debate over whether it's a
> type 1 or type 2.  It's not 100% clear, at least to me.  It used
> to be that any VM platform that ran as an extension to an existing
> OS was considered a type 2.  But, in the hardware access view of
> things, I can see how KVM would be considered a type 1.
> I think we can agree that KVM is not a traditional type 1 or type 2.
> We can probably also agree that the type 1/type 2 distinction in of
> itself doesn't matter if the platform does what you need it to do.
> In my mind, I always felt if I used the hosting Linux OS to only run
> VM's then KVM isn't much different than Xen.  But if I were to take
> the hosting OS and do a lot more with it -- desktop, etc. -- it starts
> to feel less like a type 1.
> Now you've got me thinking about playing with KVM again.  It's been
> a few years ...
Xen-users mailing list
<Prev in Thread] Current Thread [Next in Thread>