[lug] virtualization first boot question

[karl horlen]

wow.  your insightful post brought up more questions and revealed my fundamental lack of understanding of the basic paravirtual / HVM thing ;).  i probably need to do some more investigating on my own but i'll take a few stabs at some inline questions below too.

> I have used Citrix Xenserver extensively (which is like
> Open Source Xen
> only worse).  

love those ringing endorsements ;)  i personally appreciate info on the stuff that doesn't work as much as the stuff that does.  it saves future headaches

> I would take KVM over Xenserver any day,
> because it's MUCH
> easier to set up and run.  Opensource Xen is a little
> easier than
> Xenserver, but I find that it is still a little more
> complex than KVM. 

ease of use is a big factor. but robustness and performance are important too.  if something was a little harder to setup but brought consistent results, i'd be willing to learn it.  sounds like you clarify below though.

> With Red Hat's libvirt and virt-manager apps, both aren't
> to bad.  

the way i understand it, is these are generic tools (command line and or gui interfaces) that allow you to use a single set of commands to manage the same set of tasks for *different* virtual implementations (xen, kvm, virtual box, etc).  an abstraction layer so to speak.  correct?

are they that useful versus the stock commands provided by each implementation?  my thought is that you're going to want to know the underlying implementation commands and procedures anyway, so you can understand what's going on under the hood to configure networking and troubleshoot when doodoo hits the fan.  put another way, it sounds to me like these tools are really *additional* tools that come in handy but not exclusive as replacements for the underlying implementation knowledge.  correct?  (examples i'm thinking of might be like copying / creating new VMs based on a base img or something).

> If
> you want to use Xen, you will have to use a Xen aware
> kernel.  If you
> don't, Xen will run your VM in HVM, or fully emulated mode,
> which is
> quite slow.

do you mean in dom0 (the master host) or in all domu VMS (guests).  i assumed the booted host kernel had to be xen aware but that you could install what ever you watned in a guest.  sounds like you're saying no?

so i think what you're saying is HVM equals fully emulated mode. whereas paravirtulization allows the guest OS to somehow reach through to the underlying HW virtualization features of the cpu. in which case, paravirtualization should be more efficient / faster.  correct?

i think this means that paravirtualization requires that each *guest* VM kernel be "smarter" and compiled for the underlying virtualization implementation (or is it just the cpu architecture in question) than a HVM guest kernel.. since the underlying hw is completely abstracted correct?

> KVM is a set of Kernel drivers that allow a user space
> program to access
> the AMD-V and Intel VT hardware on your processor. 
> KVM works in
> conjunction with a KVM aware version of Qemu.  Qemu
> does all of the
> heavy lifting.  If your processor does not support
> Intel VT or AMD-V,
> KVM will not work for you.
> 
> Both Xen and KVM both support Paravirtualization.  Xen
> supports
> paravirtualizing the entire Linux kernel, which is why you
> don't need
> the Intel VT or AMD-V processor extensions when you use
> Xen.  Qemu
> supports paravirtualized IO.  Both have about the same
> performance,
> because the Intel VT / AMD-V will make up the speed for
> things that
> aren't paravirtualized in KVM.

well based on what i said above, i totally got the paravirtualized thing wrong.  i think HVM is generically known as paravirtualization? or perhaps i mixed the two up - got them backwards the way i described them.

> None of the services will know or care that they are in a
> VM.  If you
> are running paravirtualized VMs, then only the kernel of
> the VM will
> know that it's virtualized.  That goes for both Xen
> and KVM.

good enough.  

> You will be monkeying with the network on the host
> OS.  Once you get the
> VM bridged onto a real ethernet interface where it can talk
> to the
> world, then you won't have to mess with the network on the
> VM asides
> from setting its IP address.

straightforward enough i guess (assuming the nw isn't too complex which i can't really see)

> As I said, dom0 is Xen's way of referring to the host OS.

let me rephrase.  it's the xen aware host kernel that presides over the system when you boot it (replacing the non virtual kernel that used to boot) providing the capabilites / abstraction required to implement x number of VM guests.

in other virtual implementations, there is no such thing as dom0, but the paradigm is the same.  your newly installed virtualized *host* OS is going to be the one that boots your base physical server and allows you to create and run guest VMs on the system.  right?

> With my current employer, we run KVM extensively and it
> works great.  No
> problems with it at all.  At my previous employer, we
> used Citrix
> Xenserver extensively and it also works great so long as
> you run an OS
> that is actually supported.  If you run an OS that
> isn't supported, it
> sucks horribly.  I also find that fully virtualized
> KVM is faster that
> Xen running in HVM mode.

it sounds like you favor KVM vs xen.  any thoughts on virtualbox or vmware?

thanks for the great input.