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."
"why OpenVZ outshines the competition, comparing it to VServer, Xen and User Mode Linux."
/. submitter, but Andrey slants it a little too.
Of course, Andrey works for the software company that wrote this thing, and their closed full-featured flavor, Virtuozzo. The VZ method is a good one, and has excellent performance, but it has its drawbacks, too. Personally, I don't like that my VPSes need to use my VPS provider's kernel, which lacks features I desperately want (like stateful iptables matching), and which forces me to reboot whenever they upgrade their kernel (my VPS can't be migrated to a host running a different kernel), and I can't upgrade until my provider does.
VServer, Xen, and UML all make different tradeoffs. VZ goes for performance. Saying one outshines the others is just trolling. That's mostly on the part of the
I don't want to crap on the OpenVZ project. They're working on very cool stuff, and I applaud SWSoft for opening the thing up. I just want people to keep the comparisons in context.
The interviewee keeps talking about Xen 3 like it's not out yet, but that's untrue.
Indeed, Xen 3 has been stable long enough that they're presently at 3.0.2. It's not prerelease anymore, and support for x86_64 and hardware-supported virtualization has been out and about for a while. I have semi-production (used by in-house staff only, but there are folks who can't work if it's down) systems running on Xen3 x86_64 DomUs, and the host they're on has been up (and running unattended) for 117 days now.
Sun has a OpenSolaris port to Xen (though I think it may be in-house-only still), and I have some good friends working on a microkernel OS targeted at embedded operation with a Xen DomU port pending (such that they -- and people working on it -- will be able to run it in parallel with the OS they use as their development platform). Being able to run more than one kernel -- indeed, more than one operating system -- is a big plus on the Xen side of things.
A virtual server can be restored in seconds, no rebuild required. A virtual server can be moved to another host server in seconds without ever shutting down. A virtual server has a common hardware configuration and can be moved to another host with completely different physical hardware in seconds without shutting down (you can mix Dell and HP servers for example and switch between them on the fly). Not every virtual server needs dual Xeon processors and 8GB of memory, but a bunch of virtual servers can run on that machine and share load as required and if one of those virtual machines needs a little extra umph for some biweekly processing, it has the ability to grab more resources or the other virtual servers can be moved off to another physical server hosting virtual servers with more power without ever shutting it off [1]. Redundancy in the virtualization world requires two physical host servers each able to carry the load of all the virtual servers and a shared disk area (SAN, iSCSI). To have that level of redundancy in the plain of non virtual world, each server would have to have a second physical server for backup and unless you were clustering, you would not have the ability to move over your processes to the backup physical without some type of interuption if one of them suddenly failed like in your example.
;)
Virtualization has many advantages in the enterprise and the ability to recover from a virus in your example is one small part of the whole package.
[1] Host servers can share memory between virtual servers, not just the total memory but the memory between machines as well. Very simple example but if you open sol.exe on one of the virtual servers, you will not take up any more total memory on the host machine by opening sol.exe on another virtual server on that same host. The memory is shared between the running virtuals as well. This works great when you have quite a few of the same OS being virtualized on a host. You could run 10 plain vanilia virtual copies of Windows server 2003 and the total memory taken up on the host will be less then 1.5 times more then a single running copy of that OS, not 10x of a single virtual. That example of 10 exact copies is not likely in real life but the common memory is shared which can make up for a significant amount of total memory savings.
Don't let your lack of insight or knowledge of the capabilities of virtualization get in the way of your opinions
In the mid 60's IBM created CP-67 which virtualized the IBM S/360. In the following years the system became VM/370, and has evolved to z/VM today http://www.vm.ibm.com/. VM (the general term for z/VM) is made up of two primary components, VM/CP (control program) and VM/CMS (a mini single user operating system). VM/CMS provided the ground work for being able to administer the system, and provided a nice programming environment in that each VM/CMS user had their own "system" that one could edit, compile and run their programs in an interactive environment (think of a MS-DOS type of model -- then remember that this was in the late 60's).
p / was written as a CMS application. As well as several native VM webservers.
CMS itself provided some limited simulation of IBM's two other mainframe operating systems OS/360 and DOS. Enough that one could write simple OS or DOS programs and do at least some unit testing. The simulation by CMS was by providing a limited set of the OS and DOS API.
Unlike MVS or DOS, (or even the CP/M, Windows, or *nix families) VM/CP itself does not provide many services directly. VM/CP does not provide any filesystems, any application APIs, etc. All VM/CP really did was to provide a barebone virtual machine and only provide those services one would find on the bare hardware. It was the responsibilty of the operating system running within the virtual machine to provide the application API, filesystems, application memory management, etc. Communication between vm's were originally only via the raw hardware model (channel-to-channel adapters, shared disk volumes, and a method of "punching" virtual cards and sending the virtual cards to another vm's virtual card reader.) As time progressed, VM/CP did provide some API's that allowed very simple messaging between two vm's (first VMCF - Virtual Machine Communication Facility, and then IUCV - Inter User Communication Vehicle).
Early on it was "discovered" that the virtual machine model made a lot of sense as a method to implement VM services. For example if one were to look at a modern VM system, you would see that the entire native VM TCP/IP stack is managed within a small collection of vm's. (Under VM/CP, a vm is called a "userid"). The native VM TCP/IP stack consists of a TCPIP userid that manages the network interface devices, and the TELNET server. The FTP userid implements the FTP protocol, etc. Each userid is totally seperate from the rest of the system and from each other (the tcp/ip socket facility "rides" on top of IUCV in a transparent fashion so that a tcp/ip server is coded the same as on *nix).
Because of the facilities provided by CMS, it is fairly easy to write little servers. For example the orginal LISTSERV server http://www.lsoft.com/products/listserv-history.as
If one wants to see what is and has been possible in a virtual machine environment, one should at least look at the history of IBM's VM.
For an excellent history of VM http://www.princeton.edu/~melinda/
and the VMSHARE archive, an early BBS used by VM system adminshttp://vm.marist.edu/~vmshare/