[Discuss] Using raw host hard disk in virtual client

[richard.pieri at gmail.com (Rich Pieri)]

On Sun, 05 Aug 2012 09:39:19 -0700
Kent Borg <kentborg at borg.org> wrote:
> Xen is an odd beast.  I played with it once and I didn't like the
> tight coupling between the guest and host (upgrade host kernel and

There is no host in a Xen environment (even though I've used the term
that way in the past).  Xen is a bare metal hypervisor.  The dom0 is a
virtual machine that sits on top of Xen.  Only the dom0 is permitted to
control the hypervisor and through it the user domains.  It's the same
general architecture as VMware ESX.

What makes it look like there's such a coupling is the Xen-aware kernel
running in user domains.  Xen provides some paravirtualized
device drivers.  These drivers allow the hypervisor to skip the trap and
emulate steps and instead pass I/O instructions to the hardware.  This
reduces virtualization overhead to just the security context switching
in the CPU.

There is a close coupling between Xen and the dom0.  If the dom0 dies
then Xen will die with it and this will kill your user domains.

> guest doesn't boot I think happened to me), but there is a reason for

This is not Xen per se.  xm will use whichever kernel and initrd that
you specify in the config file for the domain.  By default, xentools
uses the host's kernel and initrd but you can specify anything that you
want. This is how I mixed 32-bit and 64-bit Debian 5 and Debian 6 and SL
5 user domains on a 64-bit Debian dom0.

pyGrub takes this a step further and allows user domains to boot their
own kernels from within their containers.  Much more convenient than
keeping multiple kernels and initrds on the dom0.


> In general I think you want to stay away from setting up a Xen 
> environment unless you have good reason to go there.  The pure VM of 
> KVM or Virtualbox is more likely what one wants.

No one ever really wants to use pure VM on x86.  Every single
instruction performed in a guest needs to be trapped by the hypervisor,
interpreted by the hypervisor, processed appropriately by the
hypervisor's emulation system, and results returned to the guest by the
hypervisor.  This is very slow on x86.  I leave it to the reader to
review emulation vs. virtualization.

That said, neither KVM nor VirtualBox are pure.  They both use
paravirtualized drivers the same way Xen does.  They can do full
virtualization using QEMU but it is, as noted, quite slow.

And that said, Xen can do full virtualization using QEMU, the  same
QEMU that KVM and VirtualBox use for their full virtualization
options.  This is how Xen is able to run unmodified Windows user
domains.

-- 
Rich P.