On Tue, Nov 10, 2009 at 03:49:59PM +0100, Dennis J. wrote: > On 11/10/2009 03:35 PM, Grant McWilliams wrote: > > > > Both Novell and Oracle having been deeply involved in Xen lately, both > > are developing and supporting their own products based on Xen. > > > > -- Pasi > > > > ___ > > > > > > > > I have no problem with a "better" solution than Xen because to be honest > > it's a pain sometimes but at this point virtually all enterprise VM > > deployments are either based on VMware ESX or Xen (Xenserver, > > VirtualIron, Amazon AWS, Oracle, Sun SVM, Redhat and Suse). This tide > > will change as KVM becomes more dominant in the VM space but I don't see > > that happening for a while. I'm also a bit skeptical as to how well a > > fully virtualized system (KVM) will run in comparison to a fully > > paravirtualized system (Xen PV). I have a system with 41 VMs on it and > > I'll be having 2 weeks of planned downtime in the near future. I'd like > > to see how these systems run under KVM. > > I've been wondering about the definition of PV in the context of KVM/Xen. > In the Linux on Linux case for Xen PV practically means that in the HVM > case I have to access block devices using /dev/hda while in the PV case I > can use the faster /dev/xvda. When using KVM which apparently only supports > HVM I can still install a guest using the virtio drivers which seem to do > the same as the paravirtualized devices on Xen. > > So what is the KVM+virtio case if not paravirtualization? > KVM+virtio means you're using paravirtualized disk/net drivers on a fully virtualized guest.. where Qemu emulates full PC hardware with BIOS and all. So only the disk/net virtio drivers bypass Qemu emulation. (Those are the most important and most used devices.) Xen paravirtualized guests run natively on Xen, there's no need for emulation since the guest kernels are aware that they're being virtualized.. There's no Qemu emulating PC hardware with BIOS for PV guests. -- Pasi