Slashdot Mirror
An Overview of Virtualization Technologies
PCM2 writes "Virtualization is all the rage these days. All the major Linux players are getting into the game with support for Xen, while Sun has Solaris Containers, Microsoft has Virtual PC, and VMware arguably leads the whole market with its high end tools. Even AMD and Intel are jumping onto the bandwagon. InfoWorld is running a special report on virtualization that gives an overview of all these options and more. Is it just a trend, or will server virtualization be the way to go in the near future?"
Is it just a trend, or will server virtualization be the way to go in the near future?
What happened to the CowboyNeal option?
Virtualization is one of the best things since sliced bread and I believe it's here to stay. First of all, it spells an end to multi-booting. I have erased my secondary OSs and I run them in VMs under my main system. A performance hit does definitely occur by I am willing to pay such price for the greater ease of use. Secondly, just think of the possibility to move server images from a physical server to another one, literally freezing it here and awakening it over there - InstaScaleOut(tm) must be a server admin's wet dream.
Of course, as with all abstraction layers, it introduces complexity and takes a toll in the form of performance - but we all know absraction layers have been increasing all the time since the beginning of time.
Global warming is a cube.
We run 2x VM Ware ESX Servers on Sun x4200 servers (w. 8 gig o' ram :) - the web-gui for ESX is second to none, incredibly easy to configure virtual machines. It's got us seriously considering moving more than just our dev enviroments over to virtualised hardware.
With the growing evidence of the human brain's ability to rewire itself and route around failures on the fly, and the effective virtualisation of perception (why do I appear to see a three dimensional picture of the world when I have only 2 curved arrays of photosensors?) we are probably just following a well trodden evolutionary path.
Pining for the fjords
Virtual technology is great you know. I'm using a virtual PC running on a virtual PC which is simulated on the first virtual PC. This is realy a nice solution:
1)Upgrade: simply change a few values in the config and presto! 50Thz processor!
2)No power consuption what-so-ever! I even get a net gain as I run a virtual powerplant.
3)No clumsy hardware on my desk. Just type at the virtual keyboard in mid-air! The virtual monitor can project from anywhere. Heck, they even follow you to the bathroom.
4)No virus, malware or spyware thread! All thanks to the virtual virus scanner.
5)Store up to infinite TB data on the UberDVD drive.
6)Comes with free pron, MP3, warez and Movie server. Complete with anti-MPAA and anti-RIAA card.
Soon to be released: The virtual Car(tm). Just hold up your hands like your holding a steering wheel and make motor sound to get anywhere in the world in just minutes!
Virtual technology. It's everything you ever dreamed of, and more!
I remember the MS vision of making light operating systems which are basically terminal computers and visualizing the OS with remote powerful servers. This way the user will pay monthly/yearly fees to use his computer. Upsides: OS is automatically upgrades with security patches and new features; Data is backed up and can be accessed from any computer. Downsides: Well basically the monthly payment and the fact the MS got your base ;)
I think many companies are looking for a way to monetize software by monthly or yearly fees - this can be their way...
Omgili - Find out what people are saying.
They completely forget to mention User Mode Linux, which is a well established and stable linux only offering, and many of the VPS (virtual private server) hosts you see advertised are running on UML.
It seems that as Xen makes progress, UML is getting ignored.
What kind of article is that?
They talk about VMWare, Intel/AMD, the future Solaris on E10000, other things... but where is IBM?
They can do Virtualization for at least 3 years with their Regatta technology (P670, P690 (Power 4 technology), P530, P550, P560, P570, P575, P590, P595 (Power 5 technology)) and their OS AIX 5L.
they are able to give a few percentage of a cpu to virtual server, with their Virtual IO server, they also are able to virtualize network and disks. They can do workload management between virtual servers. Add/remove disks/cpu/memory in real time.
etc...
So for a complete discussion an overview of the virtualization in the industry, IBM is now a big player, and they are now surpassing SOLARIS & HP in the "closed" unix world.
So for me this overview is not complete and should not have passed the "draft" version until someone was looking at the actual and running alternatives.
L.G.
Comment removed based on user account deletion
Haven't got to use it firsthand, but if it's less of a reason to require someone to go into a server room (such as recovering after an OS crash) - it is here to stay.
Dependencies. Package A is tested and certified to run with Foo 1.5 and Bar 2.0. Package B is tested and certified to run with Foo 2.0 and Bar 2.1.
Mea navis aericumbens anguillis abundat
Virtualisation is a disruptive technology... in that it requires a lot of intellectual investment on the part of the sysadmin. The reason Unix and Windows Servers have gotten by without adding much features, yet retaining market share is simple... admin lethargy and apathy.
/client.
Microsoft does not seem to like virtualisation.. hell, they didn't like Terminal Services.. so they crippled it in NT4, made extra licensing restrictions with Win2K, and made the WinXP / Metaframe XP combn. a non-starter. In microsoft's world, users must only license MS's servers and everything needs a separate server
Now that the virtualisation market has grown IN SPITE OF the apathy of these s/w vendors... and the tremendous mindshare with Open Source technologies, these old chaps are trying to make money without doing anything themselves.. witness the recent MS licenmsing options in virtual segments, acquisition of IP, Intel's hypervisor efforts, AMDs efforts etc.
If virtualisation succeeds, it could spell the end for DRM and Treacherous Computing initiatives... since these need collective collusion by all parties involved. Looks like the firms mentioned will try their damnedest to sidetrack virtualisation.. just like terminal servics and thin clients never reached their full potential. Open Source firms and nerdy sysadmins might well have the last laugh...
If you keep throwing chairs, one day you'll break windows....
Don't forget Linux-vserver - it's very good, and very fast - as root in a vserver is root on the actual host - processes just can't "see" or kill any outside their own context. Props to Bertl.
Get your own free personal location tracker
Now guess who said that, and when. :-)
Robert P. Goldberg said that, in 1974.
The fun thing about this is, it's still a very accurate statement. Other than in 1974, though, it doesn't solely apply to mainframes, but, as someone wrote in an earlier post, to everyday computers: desktop systems. I think that's great, and the above quote is more true than ever. Working on Mac OS X and having a Parallels session up and running where some Java application (for example) is tested in a Windows or what environment... lovely.
Yes, I'm a virtualisation enthusiast, if you haven't guessed so already. ;-)
I read the article about Xen, because Xen is what interests me. I'll go back and read the others later. Looks like more of a slashvertisement than anything useful, esp on the Xen writeup.
.. but I am asking the author .. Please don't make something very amazing like Xen disappoint people because you're publishing information you really have not researched that is not accurate.
;)
From TFA:
>> Use the "dd" command to copy the boot drive from another server to a local file, point Xen at that file, and boot
>> the VM (virtual machine). Who needs consultants?
Apparently, the author does, and they have not been reading the Xen devel or user's mailing lists.
File backed virtual block devices can be very problematic for high volume services and applications such as MySQL, Apache and others. Most of us really using Xen on deployments that 'matter' have switched to SANS and using either LVM or real partitions.
Think about how long it takes to create a 3 GB loop device, then copy over the contents over a 10 or 100 meg switch (as you'd find on a hobbyist's desktop).
Migration only takes a few seconds once that's done
If you want to write information on hot topics to draw readers and slashvertise it, great - go for it. Just be sure its accurate.
They also barely touched on what is so magic about running 32 bit guest kernels inside of a 64 bit host, the new Xen credit scheduler, and other really cool things going on with Xen.
If you're going to present yourself as an authority, please present fact, and all of the facts. Please don't setup something like Xen (which many people are working very , very hard on, HP, IBM, Novell, Redhat to name a few) to just dissapoint new users. Nobody would say "Wow that article must have been wrong", they'll say "Wow, Xen is too hard to get working like that article said". Be careful what you capitalize on to sell a few ad clicks
If you stat average CPU consumption over the servers of any big size datacenter chances are you will be very surprised by the results.
...
I did this for a company with over 2000 unix servers and averages were : only 20% of the hosts would use more than 30% of the CPU
It's a known fact that for most of the projects the hardware is super sized over what's really needed, and this is one of the main advantage of virtualization : it is seen as a cost reduction process.
With that aggravating beauty, Lulu Walls.
Well, first of all, I'd like to point out that I've run on virtualized systems for the entire extent of my career. Not specifically in the sense which we run now, but in the sense that back in the old days, we ran IBM mainfraim operating systems on IBM systems that actually were virtual machines. They included features such as segmentation and all the good stuff which is just coming around now.
Thanks to other technologies I've run similar systems for ages. It is entirely common for me to develop a file system driver while keeping Mac OS X, Windows, Linux, and DOS running on the same system. I've done this for a long time as well. The difference is that the operating systems would be virtualized by running system emulators instead of using CPU technologies for system segmentation. I did this in the old days under DOS using Quartdeck Desqview and a CPU emulator.
First thing that people really need to understand at this point that virtualization as we're using it today is little more than finding a method to lauch operating systems as "processes" under another operating system. This is not magic, for the most part it's something that any operating system developer should be capable of. The issue is more of grinding. It takes the right kind of people to sit and grind through each of the problems that come up with running like this. It's the same idea as writing a Windows compatible API stack. You start off with simple programs you have the source for and work your way up through more complex applications that require direct hardware access. It's a matter of intercepting the calls and handling them as if you were the real thing.
So here's the deal. As a system level developer, I am more interested in what these guys are actually doing in order to make it happen. Let's face it, although Intel and AMD are adding virtualization technologies to their processors, the actual task of switching between CPU contexts is hardly an issue. The real issue is how are they handling hardware emulation.
See, to me, I focus on high performance workstation related tasks. Servers are cool and great, but in reality, it's how it performs on the desktop that is truly important to me. What I want to see is that a vendor grinds a little more on this issue.
VMWare has classically written device drivers to handle hardware interfacing with better performance than others. So instead of simply emulating the VESA BIOS extensions and providing access to an SDL style frame buffer, instead they have written drivers to allow graphics acceleration. So what I really want to see is that they take it a step further....
I want more than just accelerated BitBlt functions. Of course in the 2D desktop world, high performance frame buffer moves are not optional but required since the bus bandwidth required to copy large frame buffers all around is outrageous. But in the days where OS X uses OpenGL and Windows Vista uses DirectX, I want drivers that interpret 3D contexts as well.
So here's what I'm thinking... write a 3D driver for Windows, Mac OS X, X. The driver should of course offer frame buffer handling, but this shouldn't be the focus since it isn't used for much more than boot and text mode processing. When an OpenGL context is created, instead of creating the context native to the virtual machine, the context should occur on the host operating system and should be managed there. The only interprettation should occur when the graphics driver informs the guest operating system of the top level context.
For direct X, well, I've seen at least one virtual driver in the past which implemented Direct X on Open GL. For professional graphics, Direct X is typically seen as a toy although in reality in many ways it's more powerful than OpenGL (don't argue, it has to do with what's more important to hardware vendors so their drivers are optimized for game based testing). So, since most professional graphics packages are OpenGL based, then the virtualization software vendor should simply implement a translation layer ov
Mainframes have been using virtualisation for decades. It's not going away, it's simply too useful.
Deleted
Do I misunderstand, or is there are real advantage on running product X in one VM and product Y in another (or even second instance of product X). What is the advantage of that scenario over simply running X and Y (or two X) on the same box.
Well for one, it makes separating X and Y onto different boxes a year down the road pretty well effortless. (whether its for load balancing, hardware upgrades, or whatever)
For another it makes upgrading X possible without having to worry about an impact on Y. Doubly handly in "validated" environments (e.g. FDA regulated)
For another it gives another tool to manage security, as its trivial to partition users and applications.
Not to mention the ability to mix OSes at will (including different versions of the same OS). X has been certified on Debian but not RHEL? Y has been certified on RHEL but not debian? Run that X on debian, Y on RHEL, oh and run Z on Windows 2003, all on one physical box. Very convenient if you need to run 3 low load apps but on different OSes.
IBM is so far advanced it's not even funny.
Intel and Xen even based their virtualization stuff on old papers from IBM documentation and whitepapers.
You want to know how hardcore IBM is?
THEY INVENTED VIRTUAL MEMORY. And no I am not talking about a swap file on your harddrive, you windows wennie. I am talking about the ability every PC has to abstract memory.. It's IBM's gift to the PC that made modern computing possible.
You aren't convinced of IBM's monsterious power?
They have it setup so that when you buy a OpenPOWER machine for running Linux you can get a optional firmware hypervisor to manage multiple operating systems. And it's pretty cheap also.. For the same price as a low end Sun Opteron box you can get a low end IBM POWER5 box.
But it's not just that... Get this:
IF you buy a Xeon cpu on a add-on card you can set up the machine to RUN WINDOWS.
That's right. Run windows with a fucking x86 cpu on a PCI CARD.. Sharing the same memory and harddrives as Linux running on POWER5. On the same machine. At the same time. With NO slowdown.
Still not convinced?
How about this, for a show of IBM's utter superiority in this feild:
We are running a 2000 era IBM Mainframe with a late 1970's operating system on a 1990's operating system with 1980's era tape drives for legacy reasons.
IT'S A THIRTY-ONE BIT (no NOT 32 bits. 31bits.) OPERATING SYSTEM ON A #$%#$% 64 BIT MACHINE. It's not even like going from x86 to x86-64. They are entirely different computer archatectures. AND it runs at near bare hardware speeds. It's incredable. AND we can run Linux next to it. At the same time. And not just one Linux install, but very literally hundreds of them if we felt like it.
It's completely nuts. They got shit that makes Vmware look like Dosbox. Microsoft's 'Virtual Server' isn't even on the radar; it's completely laughable in comparision.
That and it has the worst possible user interface imaginable. Think about the worst thing you've ever seen. Some DOS 2.x nightmare. Now add a OS/2 GUI and make it WORSE. Now imagine it worse then that. Now your getting close. That and we pay out the ass for the pleasure of using it. Ok, now make it slightly worse. That's about right.
System architecture is changing in a profound way that will somewhat limit the commoditization on which virtualization depends. It's not just a matter any more of CPUs doing calculation and ordering up random disk accesses. RAM speeds, memory bus speeds, interprocessor pipeline speeds -- that stuff all matters a lot now. This is most evident in data warehousing/analytics, where data warehouse appliances (Netezza, DATallegro) and even memory-centric technologies (SAP, Applix) are becoming more important, but it could also be a broader trend.
I've written about some of the details at http://www.dbms2.com/
No way do I dispute the benefits of virtualization in OLTP, messaging, and so on. It's just not the be all and end all.
To err is human. To forgive is good system design.
One of my company's clients used VMWare to virtualize the server software we provide them. A few months back they had a massive power outage that caused them to lose large portions of their primary data center.
They weren't running one of our replicated setups, so we were expecting to spend the next week rebuilding the server and configuring our software.
Instead, they grabbed the most recent backup of the VMWare image and booted it up on a completely different server over 100 miles away.
End result?
About a day's lost data and an hour of down time. (The backup was already at the remote site)
I've been pushing for VMWare usage in our test environment to reduce our hardware needs and time spent restoring Ghost images, but a few managers are still dubious, and are afraid we might "miss some hardware issues" if we go that route.
"Live Free or Die." Don't like it? Then keep out of the USA
I see no mention of virtualisation techiques that virtualise a different architecture - such as Transitive's QuickTransit software, of Rosetta fame. They announced a version of their software the other day which virtualises a SPARC Solaris machine on x86-64 Linux, which sounds more interesting than simply pretending to be yourself :)
" To steal ideas from one person is plagiarism; to steal from many is research. "
Security. Modularization. Having one part falling down not take down everything else.
For example, in my setup there are two servers:
* the old one: mysql, postgres, apache
* the new one: Xen
* pound (reverse http proxy)
* postgres
* mysql, apache
* subversion+backups
+ viewvc running as a different user with read-only access to the repositories
* a VM hosted for someone else
When I break the dev apache, the production one stays up. When apache goes down, subversion stays up. When any of my VMs go down, the one hosted for someone else stays; and the other way around.
And when someone pwns anything other than the dom0 (which runs just Xen and ntpd), they took over just that single part.
Sure, I could run everything without virtualisation. But I don't think I have to say why I prefer the way I've chosen.
And you can't claim that Citrix is a good product. Slapping a GUI on a server and "network efficiency" don't belong in the same sentence.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Various people in this thread have claimed that virtualization is a workaround for not being able to write a decent operating system. I think that's wrong. Different operating systems are legitimately different in the way in which they present high level interfaces and abstractions of low-level hardware features.
What virtualization really is is a long overdue standardization of a set of APIs that exist in many operating systems but remain hidden. By finally exposing them, we gain functionality that didn't exist previously.
Virtualization looks like necessary evil, because we are incompetent to write better OSes and Application. Virtualization is the easier route.
It's not a question of "competence", there simply is no such thing as a uniformly "better" operating system or application. DOS, for example, is an excellent operating system for some narrow set of applications, and you can hack Mach or Singularity until the cows come home and you're not going to create something better.
I would have preferred a better, from the ground-up OS any day. Hurd, or ever better Singularity!
People like you are part of the reason why software sucks so badly: you simply don't understand real-world tradeoffs. People like you design systems like Mach or Windows, systems that try to be everything to everybody; people like you throw in MLOCs of useless features and generalizations and extensibility, and all you are doing is create bigger and bigger headaches.
Virtualization is doing the right thing: it lets people focus on creating operating systems and server configurations that focus on solving specific problems. Maybe with virtualization, we can finally kill the general purpose operating system.
Virtualisation is an inevitable step in the evolution of computers. It follows the trend that we've already seen - when computers got powerful enough to usefully run more than one process/program at a time, we introduced multitasking operating systems that "virtualised" memory, IO, and peripherals to multiple processes. Now computers are getting powerful enough to usefully run more than one OS at a time, we are seeing software which arbitrates this in much the same way, and extra hardware features to support it better.
Don't forget that this is just the first or second generation of this technology; in future we are likely to see multiple operating systems on one machine become much more commonplace, and as operating systems start to be built with this in mind, increased inter-OS communication in the same way that we have inter-process communication now.
Also worth noting is that we're moving away from the model of ramping up the clock speed on CPUs and moving towards a model of increasing the number of processing cores (dual-core CPUs and SMP), and smart high-speed switched buses (e.g. PCI express, 1/10/100GBps switched ethernet) - I believe that the computers of 10 to 20 years from now will be highly parallel, modular, hot-pluggable sets of processors and buses that will be able to intelligently allocate and partition resources between OSes and apps, and we will see a break away from the strict two-tier OS/program model and move more towards a much more flexible model with multiple levels of abstraction.
Hard to believe that they wrote an article that even mentioned virtualization on mainframes, and didn't think to mention IBM's pSeries solution with runs both AIX & Linux. I ended up going that route over blade servers because it was simply cheaper to implement without sacrificing hardware robustness and redundancy. Not to mention the flexibility of a SAN-backed server....
I remember this kind of argument from Mac devotees in the pre-OS X days when the Mac didn't have real protected memory, and still used cooperative multitasking. People would say that pre-emptive multitasking was just a crutch, that cooperative multitasking was cleaner and potentially more efficient, and that "good" programs would consistently yield processor time in tight loops to let other programs run.
It turns out that putting yield statements in every inner loop of every program you run is a big huge hassle, and that pre-emptive multitasking solves the problem elegantly; so elegantly that everyone does it. Not yielding CPU time is not "bad code"; it's just leaning on an abstraction that you know exists.
This same pattern of argument has been used to downplay high level languages ("optimizing compilers are just a crutch--quality software has hand-scheduled instructions"). Now we'd legitimately have to call the x86 ISA a crutch, since modern processors effectively process x86 instructions in emulation.
Don't fear abstraction! It's good for you.
I recently switched my mail/Web server from a G4 running in my basement to a virtual machine at OpenHosting. Previously, I was paying $70/month for DSL with a static IP address; now I pay $20/month for OpenHosting and $15/month for DSL without static IP. And I have someplace off-site to back things up to, and I don't have to worry about the UPS battery running out or the disk drive going kablooey.
:-)
The only downside is that my basement server runs Debian and OpenHosting runs Fedora. But nobody's perfect.
send all spam to theotherwhitemeat@ropine.com
Let's say you have a farm of VMWare servers. You have application A in one VM, and application B in another VM on the same physical server. For whatever reason, the load on application A takes a sharp spike upwards. In your scenario of A and B installed on the same physical hardware, you are pretty limited in your options. Call some poor engineer in the middle of the night, pray you have a spare server, get that app B installed on the new server, and hope everything works. In the VM world, you just grab the VM for either app A or B and move it to a lower utilization server, with no significant downtime. I believe with VMWare 3.0, this process can even be automated to a large degree.
Virtualization has been great for dealing with pesky license servers. Some very expensive software packages require a license server that talks to a hardware dongle. In a university setting, we sometimes run dozens of these license servers. Even worse, most license managers expect the dongle to always be on parallel port one. So with vmware server, we can set up a bunch of dongles on an expansion card, then map each port into the vmware image. Furthermore, each vmware image can have a particular mac address set for it, so even if we have to change hardware or move the license server image around, everything stays set. Dongles are evil. But virtualization makes it liveable. And prevents us from having to have dozens of separate machines that do nothing by run the license software.
Most of the time I see people using virtualization, it is to get around software conflicts, or to be able to install things side-by-side that aren't designed to be run in that environment. In such cases, virtualization is overkill. They didn't mean to virtualize the entire processor and memory - they only needed to virtualize the system configuration and limited parts of the file system hierarchy.
For these purposes, chroot is a better fit.
I've often wanted an equivalent for Windows, where I could run an application with a virtual registry, so that it didn't muck things up. Or so that it thought it had full access to the C:\WINDOWS folder. Instead, I have to use Virtualization s which requires 2 gigs of space, causes a 2:1 speed reduction, and cuts my available memory in half.
Even better yet, would be decent installers and applications that follow the rules.
And of course it's not a fad. There are already a lot of server farms out there that are highly dependent on virtualization. It allows them to provide specific OSs, and even OS versions (notice that Sun is mainly interested in letting folks run multiple versions of Solaris), without dedicating a machine to each installation. Less expensive, more flexible. No big mystery there.
And it's not even a new idea, though this particular implementation of it is. For years, supercomputer companies have sold software that divided their multiprocessor systems into "cells", each running its own OS. Virtualization is pretty much the same thing, only it doesn't require a dedicated CPU — or the purchase of an expensive supercomputer.