Slashdot Mirror
Citrix XenServer Virtualization Platform Now Free
Pedro writes "Citrix announced today that they are giving away their Xen OSS based virtualization platform XenServer with all the goodies included for free. The big highlights are XenMotion, which lets you move VMs from box to box without downtime, and multi server management. The same stuff in VMware land is $5k. They plan to sell new products for XenServer and also the same stuff on Microsoft's virtualization technology called Hyper-V. It will be interesting to see what VMware does. The announcement comes the day before VMware's big user event VMworld."
I like the marketing for this The enterprise-class features you need at none of the cost. I'm thinking this is a pretty big deal.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
I've been waiting several months (through multiple missed release milestones) for Sun to get a xVM Server general release out. I'm still running a bunch of VPS nodes under VMware Server in the meantime, and I'll probably be in the ground before Sun's product is released.
It's really a shame, considering how much I like xVM VirtualBox.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
Here's the link: Get it while it's hot.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
As I've pointed out before, the reason many organizations use VMWare is because it just works. Their stuff is solid, and it works in mixed environments real well. Unless they've made some major improvements, Xen has the problem of being only good at Linux on Linux. If you run Linux servers, and want Linux guests, it's great. However it is not good at Windows as a guest, and of course can't run on it at all. While I've never used Hyper-V, I'm sure it is the same for Windows.
However VMWare isn't a problem like that. You can run VMWare on Windows or on Linux (or Mac for that matter). On either platform, it'll run pretty much anything as a guest OS and run it well. Linux, Windows, Solaris, etc all work great and they've got native tools for most platforms.
That's really valuable to us. We aren't interested in playing around with what OSes we can and can't run on our virtual servers. We aren't interested in fiddling and tweaking to make shit work. We want to install it and go.
There's also a whole bunch of other tools/features VMWare has that are really slick, but the OS support is a big one. Unless Xen gets good at supporting Windows as a guest, and by good I mean no problems, high speed, native tools, etc, it just doesn't compare. Same deal with Hyper-V. It may be the best thing ever for Windows on Windows, but if it's Linux support isn't equally good, then I don't see it as threatening VMWare.
You're describing the practice of using virtualization to host multiple dedicated-purpose "appliances." I use this approach myself; I've got a Debian VPS doing proxy work, another couple of nodes for static HTML serving, another for dynamic apps, one that just serves as an XHTML validation server, etc.
Hardware is cheap these days, and virtualization makes the clean separation of appliances on a single managed box very easy to accomplish. The benefits I get include improved security (difference services run on partitioned hosts) and ease of management (upgrading one application doesn't break others).
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
It runs EVERYTHING! Bwahahahaha!!!
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
It seems the only way to administer XenServer is from Windows - is this correct?
Based on the vmware/xen comparison chart, there is no limitation...
http://www.citrix.com/English/ps2/products/feature.asp?contentID=1686939 (this link was posted above by someone else as well, I do not claim credit)
I came, I conquered, I coredumped
A major issue with virtualization in the enterprise is certification by various enterprise software vendors. If your entire platform stack (hardware, Virtualization, OS, etc.) (can you believe we actually have platform stacks now? Geez...) isn't certified, you just give them an excuse to not support you. VMWare has made some solid inroads here, but the last time I saw Xen on the list of certified platforms for something I was integrating was, oh, I'd say never. Not to say such apps don't exist, but they certainly aren't anywhere near what one would call ubiquitous. For many companies, paying the ridiculous price of VMWare is worth it for this reason alone.
Help save the critically endangered Blue Iguana
In another move to counter VMware's lead, Citrix will offer its XenServer software free starting in April. One or two high-end features from that product, including the high-availability features, will be moved to Citrix Essentials for XenServer, but many of the existing capabilities will be available for no charge, said Citrix CTO Simon Crosby. Citrix Essentials for Hyper-V and Citrix Essentials for XenServer each will be priced at US$1,500 to $5,000 per server, depending on the features selected, Crosby said.
Enlightenment? It's just a flush in the pan.
How long before we see multiple dedicated-purpose appliances packaged in a single box with the only thing different between multiple models is a license key that 'turns on' the proxy, static web server, router, firewall, e-mail server, etc.
My blog
PBX's have been doing that for a long time now with systems that support Voice Mail, VOIP clients, multi site grouping and routing.
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
1) Requires new hardware. VT is only available on newer Intel processors. So if you have an older server, and many people do, it isn't suitable for that purpose. That will become a non-issue eventually but at this time there are still lots of servers that aren't.
2) In my experience with toying with it, it still has problems with Windows like occasional random crashes and such. VMWare seems as solid as if you are running on real hardware, Xen seems to have additional problems.
Again, it comes down to the "It just works," thing. If you have the hardware that can support it and are willing to tool around and maybe deal with problems, ok then. However if you don't want to do that, then VMWare is what you want.
Comment removed based on user account deletion
They want you to use it and depend on it so you buy support and additional product. In my opinion, if you're running an enterprise virtualization platform for critical tasks, you'd be an idiot to do it without a support contract.
So if you need support anyway, how much of a difference is this vs. buying VMware with support?
I'm not buying that they "tend to win" in a head-to-head with VMware. Sorry. The market numbers (and the fact that they're now giving it away) doesn't really support that. To compete, I suspect they were discounting to the point where they were giving it away when they really wanted to make a sale to a particular account.
Once you buy VMware, support isn't expensive, so the ongoing cost isn't that bad. The installed base isn't going to evaporate, any more than OpenOffice has managed to get rid of Microsoft Office.
This does make the Oracle and Novell versions of Xen look a little pointless, though.
You're describing the practice of using virtualization to host multiple dedicated-purpose "appliances." I use this approach myself; I've got a Debian VPS doing proxy work, another couple of nodes for static HTML serving, another for dynamic apps, one that just serves as an XHTML validation server, etc.
Hardware is cheap these days, and virtualization makes the clean separation of appliances on a single managed box very easy to accomplish.
At one installation I managed, it was decide that the single (Linux) "server-that-did-everything" approach would be scrapped in favor of multiple virtualized appliances.
Without boring everyone with the details, the "experts" brought in to do this left with tail between legs when it was found that the harware previously used, and which never exceeded 2% CPU Utilization, was woefully inadequate to handle the four virtual machines into which it was virtualized.
New hardware was going to be needed. The manager sent the experts packing, and paid his in-house staff overtime to restore the system to its prior state.
Virtualizing an entire operating system to run a single system for the sake of simplicity is still absurdly wasteful of CPU cycles, memory, and disk space.
NO, New hardware is not cheap.
Anyone who believes it is cheap is looking only at the sticker price and not the staff, power, cooling, backup, rack-space, setup-time needed.
To use the cheapness of new hardware as a justification for virtualization is to turn the whole Virtual Machine concept on its head.
At the end of the day you have to ask: Why vitrualize if doing so means you are going to have to buy new hardware? Just buy the new iron and split out your functions across different platforms and take advantage of the redundancy, and reliability of not having all services disappear do to a single component failure.
Sig Battery depleted. Reverting to safe mode.
This was never true; I'm not sure where you heard it.
very well, actually. I use to host a slew of paravirtualized debian 'machines', alongside a couple of Windows 'machines'.
Xen Server is a nice product - it has good support for Linux and for Windows, and it's fast. I have had trouble setting up a DC under VMWare Server 1.x and 2 when using Linux as the host OS, but no such issues with Xen Server. No clock skew problems, fast networking, easy SAN support, etc.
I had managed to get the tightwads where I work to approve a budget for Xen Server this year (I'm using Xen Express), but now it looks like I'll get to use that money for something else.
Virtualization CAN save money on hardware, cooling, rack space, etc. You have a single multi purpose server. That means that virtualization may not meet your needs. However, take into account the areas where I work, which include a data center that is thousands of square feet (No, this is not a hosting site for web servers, though I have worked for a hosting facility).
Imagine taking into account environments where you need testing, development, pre production, staging and production. Rather than put them on a single machine (Highly unlikely) you can instead buy a small farm of machines, say 20 boxes for multiple applications/environments and then have them pooled into units and use virtual servers of varying priority and power levels. Your staging should have near production capabilities, your dev box, maybe not. Set the thresholds and hardware differences to your liking. However, if each unit was a physical box, even a 1U you would have a lot more rack space required, perhaps multiple node clusters for each, for availability. In a virtual environment, you are pooling physical machines, so at worst, you are overusing capacity beyond your original spec, but the machines should still be available as much as the OS allows.
Your scenario doesn't have any availability for downtime. In mine, if Physical box 11 needs a firwmware patch, I migrate VMs to the other machines and then take P11 offline. I patch it, and rotate in low priority machines to ensure it works as needed. What do you do when you have to go down to the physical machine to patch firmware/bios? You lose all your applications, right?
Virtualizing has overhead on it's own, plus the overhead of running 4 separate kernels, and 4 seperate copies of all the userland shared libs...
Running everything on a single OS image, when correctly configured, gives a pretty significant performance benefit.
Virtualization is more heavily used in the windows world, where it is common practice to have a complete install for a single purpose because a lot of apps don't play well together.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I can't speak to what happened in your particular scenario, but yes, staff, power cooling, etc. are big drivers for virtualization. I've seen multiple racks of servers condensed down into two servers and a SAN running in about 20U. You can get to everything remotely (out-of-band) without needing an IP-KVM and can restart hung servers without needing an IP/Serial PDU.
Setup time for new servers is orders of magnitude faster. fill out a couple screens in a click-and-drool GUI and you have a new server up and running.
Redundancy and reliability are also quite a bit better. While you're right a catastrophic failure of physical server hardware will bring down the VMs hosted on that server, they can immediately be powered on again on one of the other physical hosts. (Of course if you use local storage with virtual servers, you're playing with fire and will get burned eventually) Virtualization also makes it reasonable to cluster services for HA since you don't need 100% more hardware for failover. VMotion or XenMotion (which I haven't yet tried) will let you move running VMs off a physical box you suspect of failing or need to service which is damn handy, though I don't know that it's worth the price VMWare charges in most cases.
Virtualization means NOT needing to buy new hardware since the hardware becomes a commodity, run it till it fails and then replace it. You get out of proactive replacement cycles and expensive 7x24x4 support contracts. When you need more capacity, you just add another node and redistribute your VMs rather than having to deal with the headache of migrating an overutilized server to new hardware.
Fsck the millennium, we want it now.
Millennium Crisis Line: 0890 900 2000 [calls cost 50p/min]
not since Xen 5, actually.
Xen 4 was obnoxious, in that you could only use 1 or 2 cores, and were limited to 4GB of RAM with the free version.
While your story rings true, why not consider virtualization in the future when you'd like to add another server?
When you're ready to purchase a new server for another task, instead of virtualizing all existing services into individual servers, virtualize the entire server as-is into its own virtual host and let it keep running the way it always did. Then add another virtual server instance to run the new stuff.
That's how I'd approach cost savings with virtualization in your environment.
- Michael T. Babcock (Yes, I blog)
At last it looks like there will be a free, supported, commercial-grade virtualization solution for those of us who dont have the budget for VMware and have been disappointed with Hyper-V and its predecessors.
I can only imagine this is unhappy news for VMware who surely must now take a reality check on their pricing. I sincerely hope they do not go the same way as Netscape, having 3 strong vendors in the market stops a lot of the kind of bad behavior you see from ERP, CRM, and BI vendors (you know who you are guys!). There was a balanced 2 minute comparison of Hyper-v, XenServer, and VMware over at the 360 blog here.
For the VMware, Xen, and Hyper-V fanboys (are there any Hyper-V fanboys yet?), calm down and take a tip from that blog:
"Providers of the core hypervisor technology will continue to play a game of technical leapfrog with one another for at least a couple of years, while those with a management, enterprise framework, or suite will claim more strategic long-term positions around "liquid infrastructure" or something else suitably bendy. What is most important right now is that you have the right information processing architecture, not any one particular product within it."
For those of us who are out of date, what is XenServer USED for?
I understand VMs, I've tinkered with them a bit but I don't understand XenServers practical application.
Can someone give a usage scenario?
I had managed to get the tightwads where I work to approve a budget for Xen Server this year (I'm using Xen Express), but now it looks like I'll get to use that money for something else.
At any place I've ever worked, if funds for a certain thing were no longer needed (product became free, we found a free alternative, etc.), we did NOT get to spend the money on something else. At best, you get to brag about cost savings!
:q!
One of the selling points of Unix has always been the ability to have multiple user accounts with security policies that prevent them from interacting badly. The problem, of course, is that security holes are relatively frequent. In particular, local security holes, i.e. exploits in any code that ever runs setuid, are quite frequent. That they're so frequent that people don't trust OS security at all, to the point of running separate apps in separate virtual machines, seems like a pretty conclusive determination that OS security policies have failed.
I can't help but think that one alternate route that would've ended up more efficient would be to give in and write more core software using some variety of language not vulnerable to quite as many buffer overflows and stack-smashing attacks. Doesn't have to be some big paradigm switch like using Ocaml; a C-with-some-safety dialect like Cyclone would be fine. Besides inertia, one of the main arguments against was that it adds overhead compared to straight C. But the fact that people are willing to accept a much larger amount of overhead via virtual machines to get more solid guarantees of security that the OS is frankly failing to provide is some indication that the overhead-for-security tradeoff is something people really do want.
There are some advantages to using virtual machines regardless, such as ability to migrate apps separately. But we're using them here in some cases where multiple users on the same OS really would have been the best setup, except for the fact that we don't trust Linux to be free of local-root exploits.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
We recently did a re-evaluation of our virtualization tech, and VMware won out over Xen. The simple reason: VMware can run Windows on machines that don't have hardware VT. Sure, if we wanted to immediately replace every single server with a new one containing a new cpu, that'd be different, but in this economy you don't really want to throw away perfectly good hardware that still runs VMware at a very nice speed. Xen requires hardware VT, or you aren't running Windows guests, period. VMware doesn't care; it uses hardware VT if you have it, or it does software virtualization otherwise.
Tired of FB/Google censorship? Visit UNCENSORED!
Why not add the service to the existing box? Thats what we ended up doing.
The thing of it is, if you have enough processing power to add Virtualization, you have way more than you need to add the service to the existing box.
I fully understand the big installation guys with a rack full of servers consolidating many into one who have responded here. They are making up for excesses of the past (too much hardware) using the path of least resistance. Instead of learning how to add a service to an existing box they simply clone an existing box into a Virtual Machine, freeing up hardware, some of which is probably obsolete and due for replacement. Its a cost effective approach.
There are also security reasons to do such a thing.
But that's the opposite argument presented by the GP who was talking about the cheap price of hardware as justification to virtualize. That's just wrong on so many levels.
Sig Battery depleted. Reverting to safe mode.
hahaha, well, i'm hoping they don't find out ;) Maybe I can weasel in a new developer workstation or something...
As I've pointed out before, the reason many organizations use VMWare is because it just works.
Just don't try to uninstall it. I have a box that I had been using since 2002 completely melt down after I uninstalled a copy of VMWare. It required a full nuke and pave to rebuild the OS...
HA! I just wasted some of your bandwidth with a frivolous sig!
I'm not sure that I totally agree with that.
What is a properly designed cluster of virtual machines? There is no reason that the daemons in the cluster cannot communicate/interact at extremely (read local) speeds. There is no reason that the various levels of hardware abstraction cannot be varied to different levels of virtualization.
One could easily imagine using a "storage" management v-appliance through a "database" management v-appliance, connected to a series of "HTTP server" v-appliances.
The "overhead" you speak of, that of OS security; there's no particular reason that it would be more efficient to build that into your OS; instead, the coarseness of putting it in a virtualization hypervisor may make the code more elegant, perhaps even with less overhead.
However, there is a way in which I agree with you; we need smarter OS's to interact with the hypervisor better. Take *out* the security stuff that's currently in there. That security model is broken, as the past 20 years of taught us. Heck, the unix-y approach, which empirically appears to be the correct one, is based upon simplifying your applications into separate sections as much as possible; and that's an endorsement for the virtualization model.
The issue is stripping out the crap in Windows, Linux, BSD, OS X, or whatever operating system you are using. And by crap, I mean everything which is not relevant to the functions of that particular v-application.
I'm sort of playing devil's advocate here, however, in that I don't *really* know which model has overall better $$ of hardware efficiency. If I were going to bet on it, though, I'd bet on the virtualized model with well-written v-applications.
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
What about the poor bastards like me who paid for Xen? I wonder if they are planning a refund program, or just a life lesson "Tough Shit" program!
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
Virtualization vs Multi-purposing:
- Virtualization allows you to run different OSes on the same server
- Virtualization insulates the VMs, so crashing one does not bring a whole bunch of services down
- With luck, Virtualization allows you to transparently move VMs from one machine to another, according to load
- Virtualization has a high RAM cost (no shared libraries/code between VMs), and some performance cost, especially IO, and also CPU especially on older procs (new ones are better optimized for context-switching)
- Virtualization allows you to pre-configure simple server images, so deploying new servers is somewhat easier
So basically, Virtualization seems a good fit if you have a lot of under-utilized, unreliable or very spiky servers (as long as they don't spike all at the same time): legacy stuff, specific apps... and not a good fit if you need consistent high throughput, have very stable/optimized servers.
The Cloud - because you don't care if your apps and data are up in the air.
With Xen 2, you could not have SMP VMs, perhaps this is what the grandparent is thinking of? Xen 3 was released some years ago now though, and removed this limitation, allowing SMP guests on single processor and SMP machines (running SMP guests on single-core machines is useful for debugging concurrency problems, but not for real use).
I am TheRaven on Soylent News
I generally agree with what you say, one side note though, VMWare ESX can actually share memory between different VM's if the contents of it are the same. http://www.vmware.com/pdf/esx3_memory.pdf (see page 4)
Every time you post an article on Slashdot, I kill a server. Think of the servers!
ESXi is free (although most of the 'advanced' features aren't)
If I were more versed in Solaris I'd be more onboard with it. However, the fact that you can run different OSes is great, however I am not really big on the idea of running Linux in a zone. I do like the debugger on Solaris, though. HP-UX can't exactly do that, as far as my experience. Vpars and Npars seem rather last decade :).
Running everything on a single OS image, when correctly configured, gives a pretty significant performance benefit.
And pretty significant maintenance COST. Running everything on a single OS image means you have to:
a) settle on one OS. you cite windows VMs being common because apps often don't play well together. In my experience, Linux really isn't much better... lots of apps are only vender supported or fully compatible with a limited set of distros or distro versions with specific package version requirements, deviate outside that and your on your own...
With VMs you can trivially run product A in RHEL4 and service B in Debian, and simply not have to worry about it.
b) any time you make a change to any of the services on the image, you have to retest and validate the entire image to ensure nothing broke. If I'm running A and B, and an update to A requires me to update perl or python... and B also uses perl or python than you need to potentially extensively re-test B to make sure it still works.
c) when one of the services load grows its trivial to migrate that service to a new physical server without doing a ton of work building a new image, moving data, testing it, spinning the service down on the old server, etc. Granted, running VMs means overhead that will mean you will have to migrate the service earlier than you would otherwise... but the savings in effort when actually moving it more than makes up for it.
In my experience. of course. YMMV.
There is no reason that the daemons in the cluster cannot communicate/interact at extremely (read local) speeds.
On VMware ESX, if one VM sends via its network card to another VM running on the same host server, it ends up as a memcpy by the hypervisor. Although a context switch is involved, this is still much faster than any physical network interface, but gives you the security of separate machines.
At the end of the day you have to ask: Why vitrualize if doing so means you are going to have to buy new hardware? Just buy the new iron and split out your functions across different platforms and take advantage of the redundancy, and reliability of not having all services disappear do to a single component failure.
It's funny you mention services disappearing due to a single component failure, which your described setup guarantees, and is one of the nicer features of VMs.
You have 4 services to offer that need their own machines. Say you have 2 real machines.
You can do as you describe, maybe putting service A and B on machine 1 with service C and D on machine 2.
You just created two potentials for a single point of failure. Either machine can have a failure, and such a failure causes two services to disappear. Not to mention reboots.
With a VM layer in between, you give each service a virtual guest (also called A B C D), running on what is now a cluster of two real machines.
When i need to make a major change on a host, be it hardware, software, kernel, whatever... I instruct the cluster to move all 4 services to host 2, do my work on a now idle host 1, reboot it, then move all 4 services over to host 1 while i do the same work on host 2 and reboot it. Then let it migrate the two services back to cpu balance.
None of the guest OS's notice anything has happened. All services running the entire time. And your entire host cluster just got rebooted! With the fact this guest moving can be performed automatically, that sounds a lot more like the redundancy of which you speak.
Citrix XenServer is built on CentOS. CentOS is built on Redhat. Redhat are dropping Xen like a hot potato and moving to KVM. Guess who's upstream support just went byebye?
I recommend that you need to seriously consider why you are doing it. If you are doing it for hardware savings, you have totally missed the concept of virtualization, which is savings through abstraction. If your site is so small that it can all fit on one server, perhaps virtualization is not for you. However, it still may be for you if you want the hardware availability features (the fact you can take a physical host down and keep everything running on the other, with ZERO downtime). These are the values of virtualization, and they are HUGE especially when you get into larger sites.
Now, Xen vs VMware... VMware does just work, and it is damn stable. And it is damn fast. If you have ever benchmarked VMware Server against Xen, throw your results away, go download ESXi (free) and try it again.
In my testing, with SPECint/fp results (we are an associate member of SPEC), AMD is around 5% overhead and Intel is around 10% overhead. With I/O, you run 10-15% FASTER in a VM than on the exact same physical system, period.
VMWare does "content-based page sharing". Thus there are *not* 4 separate copies of all the userland shared libs. The VMM, in the background, scans pages across VMs with identical contents. It then maps them to the same physical page with copy-on-write semantics.
What do you do when you have to go down to the physical machine to patch firmware/bios? You lose all your applications, right?
Well, I patch the firmware probably once or at most two or three times in the server HW lifetime. OTOH, patching the OS kernel is way more frequent in my part of timespace. And the new kernel means server reboot, be it virtualized or not.
The point of virtualization is mostly to isolate the applications which require different operating systems or OS versions (with a minor added bonus of faster reboot time and live migration). But a separate virtual host per application is simply insane. After all, it is the operating system kernel which has been designed to provide a more-or-less "virtualized" view of the hardware for the applications. One OS image can more often than not run multiple applications without a problem.
-Yenya
--
While Linux is larger than Emacs, at least Linux has the excuse that it has to be. --Linus
With VMs you can trivially run product A in RHEL4 and service B in Debian, and simply not have to worry about it.
This be true. Some commercial Linux software is supported under RHEL for example, while you may prefer to run a nice stable Debian system for another task. Xen (or other hypervisor) makes this sort of thing trivial, and all of your apps get supported, updated, etc rather painlessly. You don't need hacks like alien any more, and your vendor won't bail out claiming an unsupported configuration when problems arise.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
Virtualization means NOT needing to buy new hardware since the hardware becomes a commodity, run it till it fails and then replace it. You get out of proactive replacement cycles
I don't think you get out of that. At some point, hardware has to be replaced because it's more economic to do so. Old hardware usually sucks up more juice and takes up more space because you need more of it.
8 of 13 people found this answer helpful. Did you?
which never exceeded 2% CPU Utilization, was woefully inadequate to handle the four virtual machines into which it was virtualized.
Sorry, but your "experts" were idiots. Virtualization adds at most a few percentage points overhead. What were your experts doing? Runnings Bochs?
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
Also, if you had to patch the kernel, change the initrd image, modify drivers, and it blew up in your face, how do you rectify this? In a VM world, you roll back the changes. You can even snapshot off an image of your machine, change the virtual network/hostname and test your new kernel, on your app server, in a "lab" environment without additional hardware or downtime.
How about hardware vendor issues? Say your contract with HP is terminating and you can't get as good a deal as Dell or Sun will give you on new hardware. Your management wants to ditch your DLXYZs for Poweredge ABCs. On virtual OSes, you don't have to worry, necessarily, about the underlying hardware. It makes forklift upgrades a snap.
Which entirely depends on the apps in question..
A lot of commercial apps will often have such requirements, but the open source apps typically supported by most linux distributions usually don't... You could build a single redhat server and use it to run dns (via bind), http (via apache), mail (via sendmail) and a bunch of other stuff, while still being under the support offered by redhat.
The distro supplied apps will also be tested together, so the risk of installing updates is minimal - their distro testing is likely to be better thn what you can do yourself.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
So, actually, they rejiggered the product line to mesh with Microsoft's offering, they're working to integrate with Microsoft's management platform, etc.
Isn't this the sort of thing that Novell got beaten up for around here? Basically, they're teaming up with Microsoft because neither one of them can touch VMware.
From where I stand the primary benefit of virtualization is that increased redundancy. Instead of running multiple virtual machines on one piece of hardware because I'm cheap I can run 10 virtual machines on 10 pieces of hardware using an iSCSI backbone to shared storage where the images reside and turn on High Availability. Now not only do several redundant components have to fail in each piece of hardware, but many pieces of hardware have to fail in order for there to be a performance issue. I can also upgrade machines, move them in and out, do maintenance, etc... without the users ever seeing any downtime. In addition we can power physical servers down when the load is low and bring them back up as needed to conserve power and reduce the load on the HVAC. The over all savings is pretty decent over the long term even though the upfront cost is a little high.
It's also trivial to add new virtual servers to the system and we don't have to add new hardware unless performance is adversely affected. Our 10 physical servers might be adequate for 15, 20, 25 virtual servers with dynamically managed resources. If not we can seamlessly drop a new piece of hardware into the mix or upgrade old ones, again with no down time to the clients. And if a virtual machine craps out it takes only seconds to reload a previous snapshot. Even if the entire datacenter gets hit by a meteor the daily offsite backups of the snapshots means we can have the whole place back up and running in an hour or two in a backup location. Virtualization isn't just a way to cheap out on your hardware, it's a way to ensure absolutely absurd levels of uptime and redundancy.
Check out JoshJitsu.info for Brazilian Ji
We might get lucky, VMWare might feel the squeeze by this move and make some more of their "tools" free. They already have the server version for free, as well now they have the ESX version for free.
I will be watching this one closely.
Just a minor nitpick: for rolling back a SW upgrade, you can use LVM/FS/storage snapshots, which are as good as the virtual machine snapshots.
And of course, many HW problems affect the whole system, the virtual machines have no means of magically escaping from this.
Don't get me wrong, I also use virtual machines for many purposes. I have just wanted to point out that a "one application = one virtual machine" approach is quite insane. We already have a means of isolating applications from each other - it is called "an operating system kernel". Virtualization just brings an unnecessary overhead in this case. OTOH, running a virtual machine with _many_ applications for the purpose of live migration and whatnot - this a right use of virtualization.
-Yenya
--
While Linux is larger than Emacs, at least Linux has the excuse that it has to be. --Linus
Use the same hardware to run a test environment for that case without any virtualization products like OpenVZ/Virtuozzo or Xen/VMware etc?
Because your anecdote can be trumped by another anecdote..
Wait, so what you're saying is that sometimes virtualisation makes sense and sometimes it doesn't ?
So it would be a bit like that whole XML mess we had a couple years ago ? (<div type="phb" mode="i've seen it in a magazine somewhere">"I know, let's do it with XML !" </div>)
May contain traces of nut.
Made from the freshest electrons.
A lot of commercial apps will often have such requirements
They all do. No company offering support will support their product "on anything, with anything".
but the open source apps typically supported by most linux distributions usually don't
True unless you pay for any sort of support at any level. Again, no company offering support even for FOSS will agree to support something 'on anything, with anything'.
You could build a single redhat server and use it to run dns (via bind), http (via apache), mail (via sendmail) and a bunch of other stuff, while still being under the support offered by redhat.
Yes, if you limit yourself to the packages officially supported by the distro and hosted in its own official repositories you will be ok. But that's not normally an assumption you can make.
The distro supplied apps will also be tested together, so the risk of installing updates is minimal - their distro testing is likely to be better thn what you can do yourself.
Again, yes, if you can limit yourself to distro supplied apps.
But again their are caveats:
1) In a 'validated environment' such as what you have to maintain for an ISO or FDA certification/approval, you have to perform your own validation. So the fewer services on an image, the less re-validation effort you have to do whenever you make a change.
2) Even on reasonably basic systems your own shell/perl/python scripts have to be re-validated if you make a change that could potentially impact their operation. (And in a validated environment, even if they can't potentially impact their operation you still have to document that you made that evaluation and concluded they couldn't be impacted, every time you apply a patch or update to anything...and god help you if there is a chance they are impacted...)
Yes, working in a validated environment can melt your soul, especially if someone like catbert wrote it. (And people like catbert are attracted to writing ISO quality management systems like flies to shit.)
And in an business environment, you will run into lots of commercial apps that need supporting. Plus, if you want high availability of those services, you will probably want a server for each one in case one needs to go down so you don't have all eggs in one basket. In a good virtualized environment with pooling, if one server goes down you bring the VMs up on another server so you can work on the one that went down while your business is still operational.
Said, "It's just like dice but it's got more sides And it tells me who lives and who dies"
Yes! Anybody whose answer is to use the same tool for any job is either selling something, or only knows how to use that tool (Else they are a zealot). I fall into the zealot category quite a bit, but I also recognize that sometimes, the right tool is not the one I want to use. I hate seeing it, but life is rough.
Then one day you need to upgrade the OS to a newer version - just because you need to add an app that isn't 3 years old.
To updrade the OS you have to revalidate all the installed apps you're using on it, probably changing their configs and updating all the app versions at once... And breaking a few things.
Or you have some way to easily move working apps between different machines, whether it's virtualisation or something else...
Right now I have a CentOS 4 server that I really need to upgrade, but it's too dangerous to do so because of the 30 or so apps on it which people depend on daily.
In my experience, at least half will break if a straightforward OS upgrade is done. "Break" includes subtle things like mail forwarding rules that don't work like they did before, and complex network config that cannot be simply transplanted to a new OS version.
This is why I'm likely to put the existing OS image into a VM running on its replacement updated OS image :-)
How good are LVM snapshots at rolling back a hosed OS?
About the same as VM snapshots. For example, Solaris uses ZFS snapshots for OS upgrades by default.
How easy is it to:
Use the same hardware to run a test environment for that case without any virtualization products like OpenVZ/Virtuozzo or Xen/VMware etc?
It depends whether your application has any hardcoded paths in it, whether it can use e.g. different TCP ports, whether it is easy to impose ulimits on it, etc. Some can do it, some cannot. But still, it is much faster to have (say) two VMs - one for testing and one for production use, but definitely not one per application.
-Yenya
--
While Linux is larger than Emacs, at least Linux has the excuse that it has to be. --Linus
I would only break things out by application if there was a real need. I would recommend against a high usage database being on the same machine as a fileserver, for example but not necessarily keep a fileserver seperated from a low use dns server.
"4 seperate copies of all the userland shared libs..."
http://blogs.vmware.com/virtualreality/2008/03/memory-overcomm.html
Well the first thing that comes to mind is security. The second is, take any enterprise app and install it on a host. Now add another. Now a 3rd. Now, it breaks, vendors all point at each other. Oh what's that, these apps need different patch levels or operating systems? Oh, well, buy another server. Oh, and you want to scale it up? Have fun requisitioning new hardware, waiting for it to ship, getting it, racking it, cabling it and standing in the datacenter in building it. Before you finished filling out the request for I'm already patching my new guest. Hardware is failing? Oh well, good luck with that. I'll just migrate my guest, repair the server, power it back up and migrate guests back. Or if you're using VMWare DRS it does it all automatically. Speaking of DRS -- load too high on physical host A? No problem, DRS sees the load and migrates the guest to an underutilized host.
... should I go on?
The advantages of virtualization are so great I can't even _begin_ to cover them all. But sooner or later you'll just "get it" like I did, and like Intel did when they baked it in the chip. Or microsoft when they released Hyper-V, or EMC when they bought VMWare, or Cisco when they bought ever share of VMWare stock they could get during IPO, or
"However, there is a way in which I agree with you; we need smarter OS's to interact with the hypervisor better."
What you're describing is paravirtualization, which is already supported using Xen (maybe other hypervisors as well). Quite a few operating systems can be made aware of the fact that their being virtualized and operate efficiently with the hypervisor. What we'll see now is more and more services appearing OUTSIDE the guest. For example, imagine a hypervisor that implemented firewalling or antivirus services for all the guests it's running.
Try running 4 different unrelated windows apps on the same physical host some time. Watch them all fight endlessly for resources and when it breaks, watch all the software vendors point at each other.
One of the beautiful parts about 1 app per VM (essentially, it's not a hard and fast rule, but it's close). Is that, if the load on any one layer of your "stack" (web, app, database) becomes overwhelmed, it and it alone can be seamlessly migrated to a new physical host where it has a little more room to stretch it's legs.
Yeah the numbers are obviously way off, he's clearly exaggerating, but also consider that he may be using old hardware without hardware virtualization support, so it may in fact perform poorly.
Given that Amazon's EC2 uses Xen to run it's entire environment linux and windows machines and the fact that it works so well.. that gives a lot of credibility to the Xen platform which will certainly make it easier for companies to 'jump in' to Xen IMO.
My current client has physical servers for everything. Three tiers, as well: dev, staging, and production. As you might guess, dev and prod get the most use--staging, not so much.
They could easily virtualize all of their staging servers, and run them on one physical host as-needed (they don't do staging builds that often, and it's not like every project needs to stage at once.
They also have some special purpose machines that rarely get used, but when the client needs 'em, they really need 'em. In the group I work with alone, they probably have about 30-40 unnecessary physical servers, and they are running out of datacenter space.
If I had my way, they would retire all of those non-24/7 servers and convert them to Amazon Machine Images. Then, when they want to stage a build, they spin up an AMI, stage the build on it, then terminate the instance. Total cost: $0.10. Hell, their staging servers cost that much every few hours, and all they do is idle their CPUs 98% of the time.
What a waste.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
I can do incredibly stupid things to my virtual boxen knowing that I can just roll back to a snapshot and smile.
body massage!
I wasn't going to spill the beans on an "unsupported" "feature" though. ;-)
Not spilling the beans, eh? My friend, you are in massive violation of the Slashdot TOS. Don't tell me, your cat clicked through?