Slashdot Mirror
OS Virtualization Interview
VirtualizationBuff writes "KernelTrap has a fascinating interview with Andrey Savochkin, the lead developer of the OpenVZ server virtualization project. In the interview Savochkin goes into great detail about how virtualization works, and why OpenVZ outshines the competition, comparing it to VServer, Xen and User Mode Linux. Regarding virtualization, Savochkin describes it as the next big step, 'comparable with the step between single-user and multi-user systems.' Savochkin is now focused on getting OpenVZ merged into the mainline Linux kernel."
...that virtualisation is going to be that much of a Big Thing(tm). Those that will get the most use out of it will be the would-be dual/tri/mega-booters, and, let's face it, compared to the number of computer users in the world - heck, to the number of people that know roughly what virtualisation is - that number is going to be quite small.
I disagree, I think this is going to be big and is already starting.. In the corporate world, we have been moving many legacy systems onto VM's. Win2k3 also runs on VM's very nicely, great way to utilize that server you use for print/virus/iis, each having a seperate OS on same hardware. I think the VM buzz is really hitting much more mass right now. We are looking at mass roll-outs for desktops to get away from dual booting win/linux and would prefer to see this virtualised, as would clients.
In what ways is OpenVZ different? I also wonder what their "commercial offering" adds... but i'm too lazy to look.
I run FreeBSD jails on my box for testing purposes. It's extremely easy to setup and administer, especially with many helper scripts available these days.
I am loving the simplicity of ezjail. The coolest thing about it (besides the utter simplicity), is that it creates a "base jail" containing an entire FreeBSD install. From there it uses tricks with nullfs to mount parts of that base iinto jail 'instances'... this means each new jail takes only 2 megs of additional space, and about 1 second to create. It also adds security in that the base system remains absolutely read-only, while still permitting customisation and additional software to be installed in the jail.
I need a new virtual server to test my software:
Then run the ezjail startup script. And SSH in to my new virtual server. (Note: i set up the default server template to enable SSH and a few default logins... very easy to do. One does not need to use SSH; one can get into the jail environment a few different ways.)
It sounds like the *nix VM world is moving along the track established by Multics and IBM's CP/67 (later VM/370) projects.
It seems to me that the differences in the *nix approaches are mainly whether the abstract machine seen by user written code resembles a hardware machine or some nicer abstract machine.
In all VM approaches the idea that one can freeze an entire system and look at it, or isolate it, or migrate it, is a very valuable one. It's done well for IBM on their mainframes.
As for adding resources on the fly - way, way back (mid 1980's) Robin O'Neil and I did a System V based kernel for the Cray's out at Livermore. We had to run on top of the real OS, so we gave each user his/her own copy of Unix and create a file system that could grow or contract, adding, or removing inodes on the fly. And some of those inodes could reference files held by the underlying OS, thus making strange things, like "df" showing less space on the file system than was shown by a "du" summation of the file sizes in the file system. We published a paper on this at one of various Unix gatherings of the time.
So if we could expand file systems on the fly 20 years ago I don't see why it should be so hard to do today.
Now if we'd just get serious about capability architectures... (Much of the secure OS work of the '70's was done with capability architectures with hardware support such as the old Plessy machines.)
Very short answer -- Solaris Containers is the same technology as OpenVZ or VServer. Their isolation is OK as well, their resource management is worse than that in OpenVZ. There are some system-wide resources that you can not limit for a containter -- which can create problem if an application inside a containter goes crazy (or a container is owned by a c00l ha>
Remember, Solaris Containers are a recent feature, while Virtuozzo was available as a product since year 2001. So, Solaris is doing the right things and great things, but it still has a way to go.
-- Kir Kolyshkin, OpenVZ project leader.
Speaking of complexity, it is indeed complex. Any OS is complex. VMWare itself is very complex. Any stuff that is not trivial is complex.
The questions are: whether it works, and is it maintainable?
Whether it works? OpenVZ and Virtuozzo works just fine -- ask anybody who's using it, get a cheap Virtuozzo VPS from one of the HSP, or just install it on your Linux box and see for yourself.
Is it maintainable? OpenVZ stable kernel is based on Linux kernel 2.6.8 (with tons of backported fixes and driver updates). We have recently ported it to 2.6.15 and 2.6.16, and also to the kernels from Fedora Core 5 (here) and SUSE 10 (here). So I think it is maintaintable.
[VMWare] has some performance issues, and Xen's paravirtualization gets a fine balance, that is to have a minimal set of modification of the guest OS.
Hmm, isn't that Xen which requires a modified Linux kernel? Is that "a minimal set of modifications"? Are you kidding? In contrast, in OpenVZ's VE you run an unmodified Linux distribution, the only missing piece is the kernel which is provided by the host OS. There are modifications (like removing getty from /etc/inittab), but they are not strictly required.
What's the point then? OpenVZ also runs a modified Linux kernel. Well, the point is you can not have hundreds of VMs with Xen (or VMWare), but you can -- with OpenVZ. OpenVZ is also more stable -- but Xen will cure this, I believe, so this is not the point in the long term.
Basically, VMWare is at the one end of the scale -- can run anything, bad performance, scalability and density, OpenVZ is on the other end -- can run Linux 2.6 only, native performance, best possible scalability and density, easier management. Xen is somewhere in the middle of all this.
-- Kir Kolyshkin, OpenVZ project leader.
"Well, the question is, why virtualization?"
"virtualization is very usefull in a corporate context, eg you want to separate environnements, ease up backups, increase security, have 10 different OSes installed on one server for testing purposes"
You really answered your own question, which is something to respect in the slashdot halls, where an empty question is more common...
To add my own thoughts, though, I'd say that's exactly why I want virtualization, and why I'd rather have it at the hardware level than anywhere else. If I could test out what the latest patch from my software vendor will do (whose patches have a tendency to crap out their system) in an entirely simulated environment, I would love it.
While I'm preparing for implementing a new and improved way of doing things, such as authenticating against LDAP instead of locally on each of my ten servers, it's reassuring to my higher ups to see the process actually implemented in a test environment, with ten servers, and working. Something tangeable for them to try out always sells better than "I think we can do this, I read about it, but I haven't tried it out yet."
Running in a production environment may be something of a different beast. I'll probably wait a year for others to test the waters before I jump on board, but I AM anxious to do so.
It was great to see the latest (I think) AMD hardware running Suse 10 with its Xen installation (So, Linux base) with an unmodified Windows XP OS on top. Sweet stuff. I'll never use it. But it indicates I'll be able to install any version of Linux, without kernel modification, and use it for my daily test needs. As soon as I can remember what the underlying hardware was, that's going on my list of 'toys to buy'.
Sorry to jump on your bandwagon, but I had to say it somehow...
There's a 68.71% chance you're right.
I fully concur with the parent - I'm helping with an ESX environment at the moment that's running on 8 Proliant blades. Each of these will end up with on average 8 Virtual machines on each one and that leaves us with a lot of overhead 'just in case'. As well as redundancy it's physically taking up a lot less space and power. Regarding redundancy, we're running with storage on a SAN - if the error detection system uncovers an imminent failure in the hardware (or if we decide to), the time taken to transfer a virtual machine onto another server doesn't take long at all - after all, you're only looking at shifting the memory, not the drive contents. It *is* weird seing a fully function copy of W2k3 running SQL Server only taking up less than 100 MB RAM, though :)