If you gave virtualbox or vmware (or even hyper-v) a go, you may have seen just how far you can push your virtual machine.
These days, even with the x86/x86_64 chipset as braindead as it is when it comes to virtualization (seriously, it’s not very good at it – machines twenty years ago were better since they were built with VM in mind), thanks to some extra magic to help speed up virtualization, you can get a VM running at a good, solid clip.
Far more than enough for day to day work, even on an average machine – some even use tricks like that to enable their running of programs that their computers don’t necessarily support, for example older hardware that you just can’t buy any more, or older operating systems that won’t run on anything new, or software for an operating system which just won’t run on your hardware/software.
But, if you’ve given it much of a go… you’ll know where it falls down.
For general-purpose virtualized computing, the standard type-1/1.5/2 hypervisors are where it’s at. They provide services like access to host-based hardware (GPGPU’s, CPU features, Disks and buses, and so on) and a good degree of separation between VM’s.
You can slice up a 192GB, 32-core monster into hundreds of 2GB, 1-2 CPU machines and just let it ride. Lovely.
But… you’ll notice there’s that overhead. Overhead is wasted space – time on your CPU, space in your RAM – where the hypervisor is dinking about with things to make it all work. That wasted time and space is resources that your VM’s can’t use.
There is, however, a way around this. Kind of.
A Zone (in Solaris parlance), or a jail or container in BSD/Linux-ese is not quite a VM, but more a copy of the operating system with some extra bells and whistles for security. It means no wasted time pretending to be things it isn’t, no wasted space copying yet another kernel into RAM or even yet another application into RAM, and therefore almost no overhead.
Containers lets you run hundreds of VM’s at essentially native speed because they take advantage of the operating system’s capabilities in reusing resources – for example, when user A starts a shell, it uses say 300kb of RAM. When user B starts another copy of the same shell, instead of 600kb of ram, it will use say 320kb. And if user C does the same thing, it may use 330kb – in total, not each.
This can be done with Type-1/1.5/2 hypervisors, but it takes a lot more trickery and harder work.
With containers, though, you can run hundreds instead of tens, or thousands instead of hundreds on the same hardware. The downside is it’s easier for a single, misbehaving program to cause trouble because resources are shared instead of portioned out.
Now, so far these two posts have been a lot of talk and not a lot of show, so in part three I’ll give anyone interested a brief overview of how to use lxc and jails, and then I’ll introduce my own vmcloner tool, written in perl, for handling VM’s in xen (and, in the future, kvm and lxc, and maybe even jails).