crazylazy.info

A rough overview

Vitalization and its flavours... man that stuff blew up. Because it's really mind-blowing if you're setting up virtualization for every-day use here's a rough overview on what flavours exist and how well they scale. Most times I use combined approaches depending on the needs of applications.

- I remember when I first ran Qemu to have two operating systems and once on a single box and it was a pain: slow, halting, unstable without proper fault isolation. Things have changed. Virtualization affects everything nowadays: without virtualization technically today there's no so called Cloud-Computing (Who sets up 1000 separate SAP boxes as a cloud service provider?), no sufficient software-testing, no synergy between systems. When it comes to management people it's always this "consolidation", let "them migrate it" and stuff. - Very funny! We'll not go into details on how this relates to efficiency.

Nevertheless each Virtual Machine has its own security requirements, and virtualization introduces new problems ... well... no one cares. If you ever wanted to see an abstractly mechanized slow-motion car-crash, join IT security and be part of it. My motto to survive that is to fasten the seat belts knowingly and with precaution. Being the only survivor is very motivating and leads to world-domination. Believe it!

In any case - back to topic - it's hard to oversee all the different solutions from Xen, KVM to Qemu, VMWware or VirtualBox. I pretty much guess sales-persons are doing their job well to obfuscate the central themes into advertisement infested motives consisting of product speciously specific innovations. So let's undo their work to brain-bend us:
Intel uses VT-x for x86 and I'll completely focus on x86 for the rest of this article. The AMD marketing term for the pendant is SVM - Secure Virtual Machine. For some reasons and keep calling this IOMMU or Pacifica. The implementation details of this HVM - Hardware Virtual Machines - are very interesting and I recommend to at least to give it a wiki lookup (Intel-VT or AMD IOMMU) before further reading.

Full Virtualization means no speed?

HVM options in VMWare

If you think of the VM's hardware as completely software-emulated - in terms of fictional - you're at full-virtualization. It's software-simulated, or in other terms "emulated". The boundaries between hardware and software aren't final. Therefore a hardware-approach can support specifically optimised software in full-virtualization. Also a patched Host-OS (with Kernel extensions e. g.) can improve virtualization performance. Because normally virtualization like this is slower and architecture dependent when it comes to acceleration strategies.

In general solutions like Qemu and KQemu fall into that category. VMWware is only a little different from KQemu: it runs as a userspace-software too, emulating for the Guest-OS. But it also does different dynamic runtime optimisations based on HVM extensions.
KQemu primarily is a Linux kernel module for the Host-OS that accelerates x86-Qemu by running Guest-Code on the Host-OS's real CPU instead of the VM's VCPU. Both - (K)Qemu and VMWare primarily aren't HVM dependant. However the KQemu is about to have support for this soon in order to improve performance, and - as you can see - VMWare already has.
There are interesting sub-branches of Qemu: wine - as a Windows emulation project - combines the Wine loader with Qemu.

Full-virtualization can be supported by adding kernel-extensions (like KVM or Lguest) to the Host-OS or with HVM components. That doesn't change the fact that it's full-virtualization: it can get performingly fast enough for various development tasks: debugging, software-testing, webapp-debugging or even compiling and for sure service-hosting.

There're many every-day tasks where this kind of virtualization is important. You can run Windows with any enterprise software within a VM and separate the installations completely, navigating around cumbersome archaic dependencies for crazy internal web-apps for example. Or setup your Blackberry Server like that with policies... endless options. This concludes into Multi-Level security and you can even restrict your virtualization-solution's processes with SELinux policies or, much deeper, with GrSec's kernel patches.

Full-virtualization

• runs as userpace-software
• emulation processes within a Host-OS
• can take advantage of HVM and Host-OS modifications
• speed is very much dependant on the Host-OS's efficiency

OS virtualization means containerization?

The classic Chroot jail is the baseline for FreeBSD's Jails, Linux's OpenVZ, or Solaris' Zones e. g.. You can upgrade/downgrade your user-libraries, userspace-binaries - anything you want to do within the environment. It's like a bootstrapped place just for you and your processes. But there are restrictions according to the allowed system-calls for example. You can provide virtual network interfaces too - in order to enhance the isolation level.

But all containers (Jails and Zones) (in general) share one kernel. You may be able to run User Mode Linux e. g. - but that doesn't change the fact that this UML runs on your Host-OS's kernel. These userland operating system environments can be quite flexible. - But they are OS native and directly staged into the Host-OS.

For various development tasks this is an essential speed-up because you can skip the necessary binary translations.
- If you're using old glibc dependant software like Valgrind-Flayer or Valgrind-Catchconf you may like to setup some OS container-environments and define the environment variables accordingly in order to avoid the performance problems using VMWare with Metafuzz (has old glibc) in this case can have.
Even the mentioned example with archaic web-app dependencies ("We need IIS 6 and PHP 4!") can scale within a Jail or OpenVZ container instead of a fully virtualized machine.

OS virtualization

• there're no Guest-OSes, just Guest-Processes
• just an isolated environment for separated issues
• native performance

Paravirtualization: between solutions

The only paravirtualization solution I use and know is Xen. It runs, as you could say, directly on hardware. You can call the Xen hypervisor a micro-kernel. Theoretically at least. I do if I'm not speaking with academics.

Xen's approach is to introduce the hypervisor as an additional lower layer, that gets controlled from the the dom0 OS - a trusted OS. This lower layer kernel its the only layer that runs fully privileged in order to manage the hardware components. It uses dom0 features but but doesn't remain within the dom0 process space. - It's lower located as "a lower kernel". That's often misunderstood about Xen.
You can grant privileges to additional domains like domU 1, domU 2... from dom0. The hypervisor is not a userland process here in opposite to full-virtualization. And it's not a set of container environments in opposite to OS virtualization. It's virtualization from within, which means you need to modify your operating systems to work with Xen.

Normally this would exclude proprietary OSes like Windows. But if your computer has HVM support there's some magic like "shadow page tables" in Xen that does even that. I'd consider this to be runtime-patching.

Paravirtualization

• only (runtime) patched Guest-OSes
• no Host-OS
• addional low-level manager in-between kernels and hardware

Mixing

I'm well aware that VMWare and KVM support paravirtualized guests and that many other products don't do the clean architectural cut, too.
There're many products and solutions I didn't mention. This is a rough overview and simply designed to refer to later next year when I unleash some funny things.

Have fun,
wishi