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.
Bosses don't care if it's open source. They care
1. How much does it cost to license
2. How much does it cost to setup
3. What does it solve any better than what we already have.
Tom
Someday, I'll have a real sig.
For one. VMWare ESX is quite expensive, I understand.
ESX is a lot thicker than openVZ meaning it's emulating a lot more so more overhead. ESX is also more flexable as it run run windows next to lnux next to solaris next to insurt x86 thing here assuming they can deal with it's limited scsi emulated hardware. OpenVZ on the other hand uses one kernel and one filesystem it's one step up from a chrooted jail with a lot of process type limitors similar to ESX. The single filesystem realy keeps drive usage down with a copy on write scheme for the virtuals and you can update all the virtuals at once by altering the base filesystem. OpenVZ was designed for there virtuoso product line thats tageted at hosting companies who have been the big adopters of virtulization as it's a lot safer to sell 1/10th of a 3k server than 10 300 buck "servers" where the 3k box has raid redundant psu's and only takes up one RU vs 10 minitowers taking up nearly a rack and consuming a lot more power with no redundancy.
No sir I dont like it.
"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.
Unlike Xen or VMware this OpenVZ doesn't run a separate kernel for each virtual machine. This seems like a security risk to me. A kernel bug will affect all the running virtual machines. In other words, you only need to break one kernel and you have them all.
Plus you can't run different operating systems on each virtual machine.
It does have some positive benefits, it all really depends on what you are doing. I like the security of Xen and VMware better though.
The ratio of people to cake is too big
In this case it's an OSS version of a closed-source product called Virtuozzo, commonly abbreviated VZ. I think it's a perfectly descriptive name.
Just curious, who do you usually sue when Windows breaks?
Opus: the Swiss army knife of audio codec
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.
You know that Virtualisation has been around longer than I've been alive .. it came from the mainframe world and "discovered" by the x86 crowd :-)
Virtualization is HUGE. It helps solve a major problem. With few exceptions, most data centers are running out of power, not space. Servers consume 70-90% of their power draw when the CPU(s) is(are) at idle - and most servers in corporate America run below 15% utilization. If I can combine 4-8 servers into 1, I can save a tremendous amount of power. Here's some simple math.
A server consumes 400 W at idle and 500 W when all 4 processors are pegged at 100% utilization. If I take 4 servers that normally run at 10% utilization and combine them onto 1 server that runs and 40-50% utilization, I've saved 1100 W (4 x 400W - 500W). This is a huge value proposition for anyone who manages a data center.
I can rant forever, but trust me - this is no fad. There is a serious value proposition here.
... a beowulf cluster of virtualization servers running beowulf clusters of VPSes!
Its amazing how low utilization of servers is. Developers love lots of servers, but don't use them nearly as much as they say... see article "Virtualization is the COOLEST thing" at http://blog.tallsails.com/
Just to clarify: "Using Xen, you need to specify in advance the amount of memory for each virtual machine and create disk device and filesystem for it, and your abilities to change settings later on the fly are very limited." Xen supports a balloon driver that can allows for one to add or take away from the memory allocated to guest operating systems (DomU's). It is highly advised to us LVM2 to allocate disk space for DomUs, since it allows for easy changes to the partition. This makes file system management easier. "But most importantly, OpenVZ has the ability to access files and start from the host system programs inside VPS. It means that a damaged VPS (having lost network access or unbootable) can be easily repaired from the host system, and that a lot of operations related to management, configuring or software upgrade inside VPSs can be easily scripted and executed from the host system. In short, managing Xen virtual machines is like managing separate servers, but managing a group of VPSs on one computer is more like managing a single multi-user server." Using LVM2 as the disk manager as mentioned above, the host operating system (Dom0) can access the DomU's filesystem for troubleshooting and run programs (though it would not be run in the scope of the DomU, I'm not sure that he's actually implying that is the case with OpenVZ). --josh
... and then there's the outstanding IBM p-Series machines with their Hypervisor in :}
hardware that benefits from the aforementioned age-old mainframe technology
Ask for support != sue. You can ask your Linux distro vendor for support too. I have yet to see any successful lawsuit over a Windows fault.
Opus: the Swiss army knife of audio codec
These are not virtual machines. The idea seems to be the same idea behind Solaris 10 Containers, and I wish that had been discussed (pros and cons) in the interview.
Easier management for vertical stacking of applications on a machine.
And, yes, it is VERY useful.
Not for typical home use though. At home, I use VMWare for virtualization, QEMU to run foreign code, and BOCHS to test x86 assembly sequences, all of which I do frequently. Stacking? Not so much, because my main server is a dual PPRO with 128MB -- httpd, imapd, file services, time services, etc. Not a heavy load (104 processes, easy enough to manage manually).
Ratboy.
Just another "Cubible(sic) Joe" 2 17 3061
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 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.)
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/
And it's coming. But I think VMWare and Xen got it right. OpenVZ tries to do it inside the OS, which makes OS too much more complicated. It's not going to scale.
Another big advantage is that the virtualization provides a common "hardware" layer. For example, every VMWare "machine" sees standard VMWare "hardware", no matter what kind of metal it's actually runnning on. Want to move your "server" from your Celeron desktop to a big RISC server? You don't even have to reboot it. (It'll be inaccessible while you transfer it, but there are ways around that too.)
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.)
Basically, I would never jump into separating everything around just to make things safe, unless I look for a fancy way to mess up.
But for sure, this tool can be very useful for some cases.
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.
get a KVM switch =p
which is totally what she said
Have you actually read the interview?
OpenVZ provides a kind of virtualization called OS-level virt, or partitioning, or slicing. Basically you divide your Linux box into multiple small linux boxes, called virtual environments (VEs).
In each VE you can have different Linux distro installed. Consider FC4, FC5, CentOS and Debian running on the same box, so you can compile and test you app in all these distros, without a need to reboot or have a dedicated boxes for each of those.
To further understand between three different kinds of virtualization, read this small article
-- 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 :)