Virtualization : Clarification needed on Xen Hypervisor
bzaman
I am a newbie into the world of virtualization . Reading and trying
to understand virtualization concept these
days, I am little bit confused with the way Xen Hypervisor works
What I understood , there are two types of hypervisor.
Type 1 runs directly on a bare hardware. Examples of such hypervisor
are Xen and VMware ESX Server .
Type 2 runs on top of an OS . Example of such hypervisors is
Microsoft Virtual Server.
I tried Xen as it is open source and was able to successfully install
a guest operating system using the xen
native paravirtualisation method.
The following are my doubts/questions.
While installing xen, I had to install the following packages . 1)
kernel-xen and 2) xen . After that, I rebooted the Linux host and
booted linux using kernel-xen and installed the guest operating system
on top of it using xen paravirtualizationmethod. My confusion is
since Xen is a type 1 hypervisor which runs on a bare hardware , but I
have to run it on top of a Linux kernel customised for Xen . This
looks to me more of type 2 hypervisor . But after some time , it
struck my mind that although we are running xen on top of a customised
Linux kernel ,but that kernel is customised for xen and is probably a
part of xen (not sure of that ). If that is the case , we may be
correct to say that it is a Type 1 hypervisor .
Please give your views .
Thanks in Advance
-Bz
Hans-Peter Diettrich
> While installing xen, I had to install the following packages . 1)
> kernel-xen and 2) xen . After that, I rebooted the Linux host and
> booted linux using kernel-xen and installed the guest operating system
> on top of it using xen paravirtualizationmethod. My confusion is
> since Xen is a type 1 hypervisor which runs on a bare hardware , but I
> have to run it on top of a Linux kernel customised for Xen .
IMO xen is kind of an OS, based on kernel-xen, with the (only) purpose
of allowing to install other OSs on the virtual xen hardware.
> This
> looks to me more of type 2 hypervisor . But after some time , it
> struck my mind that although we are running xen on top of a customised
> Linux kernel ,but that kernel is customised for xen and is probably a
> part of xen (not sure of that ).
IMO the customized kernel already runs on top of the xen kernel. The xen
developers found it stupid to put virtual machines on top of a
traditional host system, with all the problems of integrating the
virtualization into existing kernels. Instead all installed systems run
on top of the same virtual xen hard- and firmware. Switching between xen
guest systems is more like switching between users, each of which can
have an different desktop etc.
BTW, please don't plenk.
DoDi
Aragorn
identifying as bzaman wrote...
> Hi All,
>
> I am a newbie into the world of virtualization . Reading and trying
> to understand virtualization concept these days, I am little bit
> confused with the way Xen Hypervisor works
>
> What I understood , there are two types of hypervisor.
> Type 1 runs directly on a bare hardware. Examples of such hypervisor
> are Xen and VMware ESX Server .
> Type 2 runs on top of an OS . Example of such hypervisors is
> Microsoft Virtual Server.
That's how Wikipedia describes it. :p However, I prefer using different
nomenclature myself. I call the above-mentioned "type 1"
a "hypervisor", and the "type 2" a "virtual machine monitor".
> I tried Xen as it is open source and was able to successfully install
> a guest operating system using the xen native paravirtualisation
> method.
Okay. ;-)
> The following are my doubts/questions.
>
> While installing xen, I had to install the following packages . 1)
> kernel-xen [...
This is no longer required. As of Linux 2.6.30, the kernel supports use
on the bare metal, as a privileged Xen guest (dom0) or as an
unprivileged Xen guest (domU), all in the same kernel image. The
kernel will detect in which circumstances it is being booted.
The "kernel-xen" packages are probably 2.6.18 kernels which have been
patched with Xen compatibility by Xen.org themselves, because back at
the time of that kernel generation, Linux did not support
paravirtualization yet.
> ...] and 2) xen
That's the actual hypervisor itself.
> After that, I rebooted the Linux host [...
Not "host", but "privileged guest". The dom0 kernel runs on top of Xen
and is bootstrapped as a module to Xen when the machine boots, but it
too is virtualized. The bootloader actually loads Xen instead of
loading a Linux kernel, and Xen then loads and boots the dom0 kernel
via the "module" statement in "/boot/grub/menu.lst".
> ...] and booted linux using kernel-xen and installed the guest
> operating system on top of it using xen paravirtualizationmethod.
The unprivileged guest does not run on top of the dom0 kernel, but
*alongside* of it, on top of the Xen hypervisor itself. If it is a
paravirtualized guest, then its hardware access is relayed onto
back-end drivers in dom0, but under control of the hypervisor, as even
dom0 is a virtual machine and its operations are scheduled by Xen.
If the machine has hardware virtualization extensions, then the
unprivileged guest can be an unmodified operating system, and in that
case, Xen emulates certain hardware and traps the unmodified operating
system's hardware accesses with assistance from the virtualization
hardware.
> My confusion is since Xen is a type 1 hypervisor which runs on a bare
> hardware , but I have to run it on top of a Linux kernel customised
> for Xen .
No, that is incorrect. That which you are running in the dom0 GNU/Linux
virtual machine is "xend", a daemon which hooks into the hypervisor and
allows you to boot domU virtual machines and resize their memory in
realtime, among other things. It also helps in live-migrating a
running virtual machine to another physical computer which also runs
Xen - provided that you're not trying to move a 64-bit virtual machine
to a 32-bit physical machine, of course.
> This looks to me more of type 2 hypervisor . But after some time ,
> it struck my mind that although we are running xen on top of a
> customised Linux kernel ,but that kernel is customised for xen and is
> probably a part of xen (not sure of that ). If that is the case , we
> may be correct to say that it is a Type 1 hypervisor .
Xen runs on the bare metal, and that which is quite often mistakingly
called "the host" is in fact a virtual machine in itself, but it is a
privileged virtual machine. It is privileged because it has access -
via the xentools package, not via its own operating system tools - to
the memory of the unprivileged virtual machines, i.e. it can start and
stop unprivileged virtual machines via the xentools, and it
can "inflate" the memory of the unprivileged virtual machine via the
so-called "balloon driver".
The privileged virtual machine is also the primary "driver domain". It
contains back-end drivers for all the hardware, and the unprivileged
paravirtual guests contain front-end drivers, which are an abstraction
layer and which relay the hardware access onto the back-end drivers in
dom0, via the hypervisor. It is however possible to hide certain
physical hardware from dom0 so that it can be directly accessed via a
real driver from within an unprivileged guest, making this unprivileged
guest into an additional "driver domain". Yet all virtual machines run
directly on top of Xen, including dom0 itself.
--
*Aragorn*
(registered GNU/Linux user #223157)