Slashdot Log In
Virtualization Is Not All Roses
Posted by
CmdrTaco
on Fri Mar 09, 2007 12:39 PM
from the watch-out-for-those-thorns dept.
from the watch-out-for-those-thorns dept.
An anonymous reader writes "Vendors and magazines are all over virtualization like a rash, like it is the Saviour for IT-kind. Not always, writes analyst Andi Mann in Computerworld." I've found that when it works, it's really cool, but it does add a layer of complexity that wasn't there before. Then again, having a disk image be a 'machine' is amazingly useful sometimes.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Yawn (Score:5, Insightful)
(http://127.0.0.1/ | Last Journal: Saturday August 04, @07:40AM)
Re:Yawn (Score:5, Informative)
Virtualization good: Webservers, middle tier stuff, etc.
Virtualization bad: DBs, memory intensive, CPU intensive.
Biggest issue? "Surprise" systems. You might see a system and notice a "reasonable" load average, then find out once it's on a VM that it was a really horrible candidate because it has huge memory, disk, CPU, or network spikes. VMWare especially seems to hate disk spikes.
What we learned is it's the not the average as much as the high-water-marks that really matter. A system that's quiet 99.99% of the time, but spikes to 100% for 60 seconds here or there can be nasty.
Re:Yawn (Score:5, Funny)
Re:Yawn (Score:5, Insightful)
(Last Journal: Thursday August 28 2003, @02:54PM)
Virtualization bad: DBs, memory intensive, CPU intensive.
We're starting to do the same. It looks the articles basically says "managing them is more complex, and you can overload the host". Well duh! They're no harder to manage (or not much) than that many physical machines, but it does make it a lot easier (cheaper!) to create new ones. And you don't virtualize a machine that's already using 50% of a real system. Or even 25%. Most of ours sit at 1% though. Modern processors are way overkill for most things they're being used for.
Re:Yawn (Score:5, Informative)
Right - except like I said - watch those spikes. We took a system that according to our monitoring sat at essentially 0-1% used (load average: 0.01, 0.02, 0.01) and put it on a virtual. Great idea, right?
Except for the fact that once a day it runs a report that seems fairly harmless but caused the filesystem to go Read Only due to a VMWare bug. The report lasts only about 2 minutes, but it hammers the disk in apparently just the right way.
It's the spikes you have to be careful of. Just look for your high-water-marks. If the box spikes to 90% or 100% (though the load average doesn't reflect it) it will have some issues.
Re:Yawn (Score:5, Informative)
(Last Journal: Tuesday December 12 2006, @07:54PM)
We have over 120 VM's running on seven hosts with VI3. Most of them, as you can imagine, are not high work-load (although we do have four Terminal Servers handling about 300 terminals total) but sometimes they are, and we've really not had any issues.
It depends on what you're doing, really. Saying you WILL have problems is any situation isn't really valid.
Re:Yawn (Score:4, Informative)
Ahh, slashdot. People just *love* to split hairs
Ok, last time I'm saying this:
BE CAREFUL. Not every system is an ideal candidate for virtualization, and even the ones that seem perfect at first glance can fail. Don't rely on only "overview" metrics. Do thorough inspection, and make sure you load test.
VMs rule, but there are gotchas and bugs that can be showstoppers. Just cause someone else has 300 servers running via virtualization doesn't mean you can
Re:Yawn (Score:5, Informative)
(http://www.readingfordummies.com/blog/ | Last Journal: Thursday November 21 2002, @05:10PM)
Load average is a bad way of looking at machine utilization. Load average is the average number of processes on the run queue over the last 1,5,15 minutes. Programs running exclusively I/O will be on the sleep queue while the kernel does i/o stuff, giving you a load average of near-zero even though your machine is busy scrambling for files on disk or waiting for network data. Likewise, a program that consists entirely of NOOPs will give you a load average of one (+1 per each additional instance) even if its nice value is all the way up and it is quite interruptable/is really putting zero strain on your system.
Before deciding that a machine is virtualizable, don't just look at load average. Run a real monitoring utility and look at iowait times, etc.
Reid
Re:Yawn (Score:4, Funny)
Re:Yawn (Score:4, Interesting)
Re:Yawn (Score:4, Insightful)
(http://www.yafla.com/dforbes/ | Last Journal: Tuesday September 27 2005, @10:43AM)
Indeed, it has become a bit of a unqualified, blanket meme: "Don't put database servers on virtual machines!" we hear. I heard it just yesterday from an outsourced hardware rep for crying out loud (they were trying to display that they "get" virtualization).
Ultimately, however, it's one of those easy bits of "wisdom" that people parrot because it's cheap advice, and it buys some easy credibility.
Unqualified, however, the statement is complete and utter nonsense. It is absolutely meaningless (just because something can superficially get called a "database" says absolutely nothing about what usage it sees, its disk access patterns, CPU and network needs, what it is bound by, etc).
An accurate rule would be "a machine that saturates one of the resources of a given piece of hardware is not a good candidate to be virtualized on that same piece of hardware" (e.g. your aforementioned database server). That really isn't rocket science, and I think it's obvious to everyone. It also doesn't rely upon some meaningless simplification of application roles.
Note that all of the above is speaking more towards the industry generalization, and not towards you. Indeed, you clarified it more specifically later on.
Re:Yawn (Score:4, Informative)
A vendor just convinced management to move all of our webhosting stuff over to a Xen virtualized environment (we're a development firm that hosts out clients) a few weeks before I hired in. No one here understands how its configured or how it works and this is the first implementation that this vendor has performed, but management believes that they walk on water. No other tech shops in the area have even the slightest bit of expertise with it. So guess what now? Come hell or high water, we can't afford to drop these guys no matter how bad they might screw up.
Who ever claims that open-source is the panacea to vendor lock-in is smoking crack. Open source gives companies enough "free" rope to hang themselves with if it isn't implemented smartly. Virtualiztion is no different.
Is this for real? (Score:5, Insightful)
"Oh, so now more apps will be competing for that single HW NIC?" Wow. Computerworld, insightful as ever.
Waste of time... (Score:3, Insightful)
(Last Journal: Monday October 15, @11:53PM)
He must be talking about freeware (Score:1)
Re:He must be talking about freeware (Score:5, Informative)
As for "putting many workloads on a box and uptime," this writer should really take a look at VMware VI3 and Vmotion. Not only can you migrate a running VM without downtime, you can "enter maintenance mode" on a physical host, and using DRS (distributed resource scheduler) it will automatically migrate the VMs to hosts and achieve a load balance between CPU/Memory. It's crazy amazing(TM).
Lastly, just to toot a bit of the virtualization horn... VMware's HA will automatically restart your VMs on other physical hosts in your HA cluster. It's not unusual for a Win2k3 VM to boot in under 20 seconds (VMware's BIOS posts in about
Virtualization is Sysadmin Utopia. -- cvl, a Virtualization Consultant
He must. ESX set up properly avoids most pitfalls (Score:5, Insightful)
(Last Journal: Tuesday December 12 2006, @07:54PM)
Teaming, hot-migrations, resource management, and lots of other great tools make modern x86 virtualization really enterprise caliber.
I think that the people that see it as a toy are people that have never used virtualization in the context of a large environment, being used properly with proper hardware. You can virtualize almost any server if you plan properly for it.
In the end, by going virtual you end up actually removing so much complexity from your systems that you'll never know how you did it before. No longer does each server have it's own drivers, quirks, OpenManage/hardware monitor, etc etc. You can create a new VM from a template in 5 minutes, ready to go. You can clone a server in minutes. You can snapshot the disks (and RAM, in ESX3) and you can migrate them to new hardware without bringing them down. You can create scheduled copies of production servers for your test environment. So much more simple then all-hardware.
I'll admit that you shouldn't use virtual servers for everything (yet) but you will eventually be able to run everything virtual, so it's best to get used to it now.
This just in... (Score:2, Insightful)
Testing PXE terminals (Score:3, Interesting)
Question: Do cards have to support it? (Score:1, Interesting)
sorry for the AC,
Dan
(interesting that the word in the image is forgive lol)
Re:Question: Do cards have to support it? (Score:4, Informative)
(Last Journal: Thursday February 09 2006, @01:35PM)
Virtualization (Score:5, Interesting)
Bandwidth concerns. You can have more than one NIC installed on the server and have it dedicated to each virtual machine.
Downtime: If you need to do maintance on the host that may be a slight issue, but I hardly ever have to anything to the host. Also if the host is dying, you can shut donw the Virtual machine and copy it to another server (or move the drive) and bring it up fairly quickly. You also have cluster capability with virtualization.
Disk contention is the big shortcoming (Score:4, Informative)
Also, make sure to try OpenVZ before you try Xen. If you are virtualizing all Linux machines, then VZ is IMO a better choice.
why are we reading this garbage? (Score:5, Insightful)
(Last Journal: Friday August 19 2005, @06:40PM)
how about an article that makes some recommendations on how to mitigate the problems they identify with virtualization, or point out some non obvious issues?
philo
it is all roses for Disaster Recovery (Score:3, Insightful)
excess power (Score:4, Insightful)
(Last Journal: Thursday May 03 2007, @11:34AM)
But it still is useful. Like terminals hooked up to big mainframes, it may make sense to run multiple virtual machines off a single server, or even have the same OS run for the same user in different spaces on a single machine. We have been heading to this point for a while, and now that we have the power, it makes little sense not to use it.
The next thing I am waiting for are very cheap machines, say $150, with no moving parts, only network drivers, that will link to a remote server.
well (Score:1)
(http://freedomsforums.com/)
We're about 95% virtualized and never going back! (Score:3, Interesting)
License controls are fine. All the major players support flexible VM licensing. The only people that bark about change control are those who simply don't understand virtual infrastructure and a good sit-down solved that issue. "Compliance" has not been an issue for us at all. As far as politics are concerned -- if they can't keep up with the future, then they should get out of IT.
FYI: We run VMware ESX on HP hardware (DL585 servers) connected to an EMC Clariion SAN.
Like all technologies, you need a good plan (Score:3, Interesting)
Home Use (Score:2, Insightful)
It's safer to browse the web through a VM that is set to not allow access to your main HD's or partitions. Great for any internet activity really, like P2P or running your own server; if it gets hacked they still can't affect the rest of your system or data outside of the VM's domain. It's also much safer to try out new and untested software from within a VM, in case of virus or spyware infection, or just registry corruption or what have you. I can also be useful for code developement within a protected environment.
Did I mention portability? Keep back-up's of your VM file and run it on any system you want after installing something like the Free VMWare Server:
http://www.vmware.com/products/server/ [vmware.com]
or VMWare Player:
http://www.vmware.com/products/player/ [vmware.com]
And if your VM gets infected or something, just delete it and make a copy of the backup, rinse & run!
Same old "doing it half-assed" (Score:2, Interesting)
Unless you are running a test bed or dealing with less critical servers, where you can use old equipment, you get a pair (at least) of nice, beefy enterprise servers with redundant everything and split the VMs among them. And with a nice SAN between them, you can move the VMs between the servers when needed.
Even better if you can, get the servers (or another pair) set up at two sites for disaster recovery.
Yes, this will cost money, but Virtuilzation is not designed to make the bean counters save money. You need a plan to do it right and the budget to pay for all of it.
Completely trash article... here's why... (Score:1, Informative)
Absolute rubbish. If you don't know how to buy and install redundant hardware and implement a virtualization platform that allows hot-migration, then you should learn. If you don't want to, then you need to go back to help desk duty.
Ohhh nooo! Sharing a single router! Sharing a single gigabit NIC!
First, regarding the NICs. When we first started working with VMware ESX, we bought four gigabit NICs thinking we'd need that much bandwidth. Guess what? We don't. We're so far from it. Even with iSCSI operations. Any basic tech article you will read about getting into VMs will explain why two gigabit NICs are probably enough. Before your NIC is flooding, your server will be. And that's not even taking into account 10-gigabit NICs.
As far as routers are concerned... My God man, what kind of dime store router are you running that this sort of thing becomes a concern?
This article is clearly written by rank amateurs and should be completely dismissed.
Also depends on the kind of virtualization (Score:1, Offtopic)
(http://slashdot.org/ | Last Journal: Friday July 29 2005, @12:12PM)
Are we talking server virtualization? Are we talking storage virtualization?
There are many kinds of virtualizations.
I admit, I didn't RTFA, but based on the comments I'm assuming server virtualization.
Storage virtualization, done right, can be done with minimal overhead inside your SAN fabric.
Worst. Article. Ever. (Score:2, Informative)
(http://uncyclopedia.org/wiki/Vatican_City)
Most admins have already figured out that; 1) don't put all your "eggs" into one virtual "basket", 2) spread the virts across multiple NICs and keep the global(or master) server's NIC separate, 3) use VIPs and clusters to load balance across similar virtual instances on separate physical h/w to keep unexpected downtime in check, 4) don't load up too many dissimilar virts into a single physical server, 5) learn the new environment in dev/qa and do your homework on the new commands and resource/user capping features, and 6) read more
Hype Common Sense (Score:3, Interesting)
For a year I fought against virtualizing our sandbox servers because of resource contention issues. One machine pretending to be many with one NIC and one router. We had a web app that pounded a database... pre virtualization it was zippy. Post virtualization it was unusuable. I explained that even though you can Tune virtualized servers, it happens after the fact, and it becomes a big active management problem to make sure your IT department doesn't load up tons of virtual servers to the point it affects everyone virtualized. They argued, well, you don't have a lot of use (a few users, and not a lot of resource utilization.)
My boss eventually gave in. The client went from zippy workability in an app being developed, to slow piece of crap because of resource contention, and its hard to explain that an IT change forced under the hood was the reason for SLOW, and in UAT, SLOW = BUSTED.
That was a huge nail in the coffin for the project. When the user can't use the app on demand, for whatever reason, and they don't want to hear jack about tuning or saving rack space.
So all you IT managers and people thinking you'll get big bonuses by virtualizing everything... consider this... ONE MACHINE, ONE NETWORK CARD, pretending to be many...
Virtualization != x86 (Score:5, Insightful)
It's not like these issues haven't existed on other platforms. Mainframes, mini's (as400), Unix (aix/solaris/hpux), heck we've had it on non-computer platforms (VLANs anyone...).
And yes using partitions/LPARs on those platforms required *GASP* planning, but in the age of "click once to install DB and build website" aka "Instant gratification" we refuse to do any actual work prior to installing, downloading, deploying...
How about a few articles comparing AIX/HPUX/Solaris partitions to x86 solutions...
Virtualization Is Not All Roses? (Score:3, Funny)
(Last Journal: Monday October 01 2001, @06:53PM)
Please tell me it's not daisies.
Author is completely uninformed (Score:5, Insightful)
(http://www.spogbiper.com/)
No, no, no. First of all, in a real enterprise type solution (something this author seems unfamiliar with) the entire environment is redundant. "the" server? You don't run anything on "the" server, you run it on a server and you just move the virtual machine(s) to another server as needed when there is a problem or maintenance is needed. It is actually very easy to deal with hardware failures.. you don't ever have to schedule downtime, you just move the VMs, fix the broken node, and move on. For software maintenance you just snapshot the image, do your updates, and if they don't work out, you're back online in no time.
In a physical server environment, each application runs on a separate box with a dedicated network interface card (NIC), Mann explains. But in a virtual environment, multiple workloads share a single NIC, and possibly one router or switch as well.
Uh... well maybe you would just install more nics? It seems the "expert" quoted in this article has played around with some workstation level product and has no idea how enterprise level solutions actually work.
The only valid point I find in this whole article is the mention of additional training and support costs. These can be significant, but the flexibility and reliability of the virtualized environment is very often well worth the cost.
VMware or Windows Virtual Server? (Score:2)
(Last Journal: Friday June 16 2006, @05:29PM)
Screwdrivers (Score:2)
I've found that when they work, it's really cool, but it does add layer of complexity that wasn't there before. Then again, having screws hold items together instead of nails is amazingly useful sometimes.
Can't we just be Professionals Anymore? (Score:1, Insightful)
Should I jump? (Score:1)
I lose graphics acceleration, except for which ever OS acts as host. Anything else lost?
Is networked i/o any better? (Score:1)
A nice buffer zone! (Score:2, Informative)
Now when he gets these ideas, before just going and doing it on the production server, I can say "How about I make a VM and we'll see how that goes over", thinking under my breath the words of Keith Moon, "That'll go over like a lead zeppelin". It give me a technology to leverage where I can show that an idea is a Bad Idea, without having to trash the production server to prove my point.
I've even set up a virtual network (1 samba PDC and 3 windows machines), to simulate our network on a small scale to set up proof of concepts. If they don't believe that something will work, I can show them without having their blessing to mess with our network. If it doesn't work, I roll back to my snapshots, and I have a virgin virtual network again.
Does anyone do this? Has it worked out where you can do a proof of concept that otherwise, without virtualization, you would be confined to whiteboard concepts that no one would listen to?
I call sockpuppet (Score:2, Interesting)
(http://fakeaccount.com/~terrahertz/)
Something's fishy.
Actually, you can get more out of a server (Score:1)
How is this different than overloading a system without virtualization? Too many databases on one physical machine will kill performance whether or not virtualization is used. Sure, products like VMWare cause some overhead, but it isn't that much on newer systems. As for the bandwidth, I agree with everyone else that says throw another NIC in. It doesn't get much easier than that. Again, bandwidth can be an issue with or without the use of virtual machines.
Virtualization is great for a lot of things... especially Windows systems. I manage some Windows servers at clients that don't have that many users (and have a very low load as a result), but can't put much else on them because things start stomping on each other and breaking. Virtualization solves this problem. Once load increases to the point where a new server is needed, it is almost trivial to move the virtual machine over.
Oh, I almost forgot about licensing proprietary apps in this environment. It is a pain, just like it is without virtual machines.
Response From Andi Mann (Score:1, Informative)
However, despite a lot of very valid points and great knowledge of the issues, many of you are missing the point of this particular article.
The interview I gave to Computerworld was not "Please give a balanced appraisal of virtualization", or even "What can't virtualization do"? It was "What can go wrong that IT people and their managers need to think about or prepare for"?
These are problems that can and do happen in real world virtualized environments. I have surveyed and interviewed hundreds of real enterprises to come up with empirical data that proves these are *potential* problems. You all point out lots of very valid solutions, many of which I would recommend (given the chance), but I do not agree that the issues I raised are not *potential* problems.
That they have solutions does not mean that the problems no longer exist. A huge number of enterprises are deploying virtualization without the skills and knowledge that you and other well-informed, well-trained, and experienced IT people have. In fact, in published studies I have found that over 50% of IT organizations that have already implemented virtualization in production say they don't have the appropriate skills to manage it. So they don't know about the solutions; many of them don't even know about the problems.
Yes, for you and I they are pretty obvious. However, just because we are smart IT people who know what we are talking about, we cannot assume all other people (and their managers) know what they are talking about too. I am sure most of you know this from experience - is everyone in your IT department (managers included) as smart and well-informed as you? Unlikely. And if they are not aware of the potential problems, through education like Computerworld is providing in this article, then they will not even look for solutions. And your job gets even harder.
So I agree with almost all of these posts to the extent that there are indeed many very good solutions to these problems. Maybe Computerworld needs a longer article to address them too. But I disagree with anyone who says that because we have available solutions, that means there aren't any problems to be solved in the first place.
Anyway, I have many forums to express my opinions, so I don't want to clutter your
Thanks!
Andi Mann
Senior Analyst
Enterprise Management Associates
amann@enterprisemanagement.com
http://www.enterprisemanagement.com/ [enterprisemanagement.com]
Surely VMWare and the ilk (Score:2)
(http://www.bobpitch.com/)
If it causes problems, then shift it to it's own box, but if it works fine virtually - then just leave it be.
its an egg head solution (Score:2, Insightful)
(http://www.peterboos.tk/ | Last Journal: Friday November 24 2006, @03:28PM)
Most people forget there was also a term called "outscalling) that is, having multiple cheap machines running your applications.. You might not even use clusters hey try it real cheap and distributed.
Try 8 desktops with no SAN runnig your mail, instead of 1 virtualized cluster (for about the same price) okay one may crash but that only affects 1/8 of your users. Compare risk to money efficiency, and valeu, try to determine your costs. As no crashes with an extreme cost isnt a real solution to my opinion. it is Costs what should decide this. And to be true most companies (altough they claim it can not) can have a server down for a hour. And 1 hour is a long time for restoring 1/8 of your users mail.
I'm focused on mail server but it could have SQL or whatever too.
In my opinion this are nightmare solutions altough they give me lot of work.
But thinking of how much money is spend for it makes me shame
As there are better ways to put your money away.
Oh and i'm not thinking this alone there more specialists silencly talking about this, but afraid to say it out loud. I think it should be told more often.
Someone explain this to me. (Score:1)
But what I don't understand is, why not just run all of those applications on one computer? So your ten servers are an apache server, a samba server, a dns, a dhcp... and so on. Just have one box doing all of that at the same time. It seems like a really kludgy way to do things, to have one computer emulate 10, each doing one thing. I would think that would have more overhead and unreliability than just having a nice stable system doing everything. How wrong am I there?
A better question would be, how big an organization or set of servers does it usually take before virtualization starts to make sense and be used. Sorry for the naivete, but I'm just lacking in experience here, and I'm curious.
If your system is 90% idle and a good candidate (Score:1)
(http://tsmwiki.com/tsmwiki/MatthewWarren)