Slashdot Mirror
Virtualization Is Not All Roses
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 is the exact same pattern that almost every computing technology follows. First the lemmings all rush to sound smart by touting it's benefits. Soon it is the be all and end all in "everyone's" mind. Then the honeymoon fades and people realise it's a useful tool, and toss it into the chest with all the other useful tools to be used where it makes sense.
One of the most uninformative articles ever to hit Slashdot.
"Oh, so now more apps will be competing for that single HW NIC?" Wow. Computerworld, insightful as ever.
I want those 2 minutes of my life back...
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
His arguements don't apply to an ESX virtual infrastructure, though there is validity for the free virtualization products.
Really Cool Thing can have drawbacks. Popular computer technology shown not to be silver bullet. Film at 11.
I've found that VMware is incredibly useful for testing network booting (PXE) systems. I rolled my own custom Damn Small Linux for PXE booting on our thin client workstations. VMware was great for testing purposes. Everybody loves DSL too, they can listen to streaming audio and MP3s while they work too, since I included mplayer and Flash in Firefox. NX and FreeNX to connect to our terminal server.
Hey I just wanted to know from someone who has tried virtualization, do graphics cards have to support virtualization? I mean I think that the drivers do some initialization when they startup, so will going from one machine to another cause a problem with that? I can think of a situation where one machine has an opengl window open and you go to the other machine to play an FPS, what will happen?
sorry for the AC,
Dan
(interesting that the word in the image is forgive lol)
Good story, but I disagree in some areas.
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.
Half of writing history is hiding the truth.
It is great for replacing things like DNS servers that are mostly CPU. However, don't try running two busy database machines on the same disk - you can't divide it up nearly as well as CPU or bandwidth use.
Also, make sure to try OpenVZ before you try Xen. If you are virtualizing all Linux machines, then VZ is IMO a better choice.
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
If your servers become toast, due to whatever reason, you can get a simple workstation, put a ton of RAM in it, and load up your virtual systems. Of course they will be slower, but they will still be running. We don't need to carry expensive 4 hour service contracts, just next business day contracts, saving a ton of money. The nice thing for me with Virtual servers is it is device agnostic, so if I have to recover, worst case, I have only one server to worry about NIC drivers, RAID settings/drivers, etc. After that, its just loading up the virtual server files.
What are we going to do tonight Brain?
No one who understands the technology believes that virtualization can perform all the miracles that the marketing people claim it can.
Unfortunately, management usually falls for the marketing materials while ignoring the technologists' cautions.
Remember, if they've never tried it before, you can promise them anything to make the first sale. Once you've sold it, it becomes a tech support issue.
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.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
Doesn't the extra layer of complexity = slower when all things are equal?
Libertarian Leaning Political Discussion Forum.
VMs are perfect for low bandwidth task which would otherwise have to take up their own box (web-hosting small domains for example). If you're trying to use VMs as a high-performance file server, you've chosen a path of pain.
Also any memory intensive task will have severe performance impacts. ESX's virtualization of the MMU adds 35% overhead and in some cases causes tasks to take twice as long opposed to raw h/w. As with all vendors, don't believe the marketing hype but test and benchmark before deployment on ALL solutions.
The absolute only place it has not been appropriate are locations requiring high amounts of disk IO. It has been a godsend everywhere else. All of our web servers, application servers, support servers, management servers, blah blah blah. It's all virtual now. Approximately 175 servers are now virtual. The rest are huge SQL Server/Oracle systems.
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.
There's nothing wrong with the technology as such. All of the problems mentioned in the article are not inherent to virtualization, nor are they flaws in the technology. Virtualization just requires some basic planning. What is the average disk utilization (disk bandwidth) of a server you want to virtualize? What about CPU? How about network bandwidth? You need to know this before you start throwing stuff into a VM. VMWare and Xen both allow you to take advantage of multiple hardware NICs in the host, multiple processing units, and also multiple physical disks and buses. Of course running multiple VMs on one host will have to share bandwidth and server throughput. The article is stating the obvious but making it sound like virtualization has an inherent fatal flaw and thus will fall out of favor, which makes the article rather lame.
I find Virtualization to be great for home use.
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/
or VMWare Player:
http://www.vmware.com/products/player/
And if your VM gets infected or something, just delete it and make a copy of the backup, rinse & run!
I think it is sad that we need virtualization as much as we do. So many applications today require a few single purpose dedicated machines. Look at the new Microsoft Exchange 2007 architecture. Accounting systems want dedicated front-end and back-end servers. You end up with so many underutilized machines performing the same functions. Yes, there are some really neat things you can do with virtualization, but server proliferation is still a problem.
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.
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.
What kind of virtualization do you need?
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.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
God damn, that was so not worth the RTFA. I have adblock+ running and there were still more crap panes than individual characters in the article proper. I'll think twice before venturing to craputerworld next time. From the "no shit, Sherlock" dept. would be more appropriate. That article, besides being a waste of time, was so junior admin.
/. and less computerworld. WTF, bring something new to the table. That was just weak.
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
This is the NSA, we're gonna geet U h@x0r5! Also, what is a h@x0r5?
The article mentions a point of common sense that I fought tooth 'n nail about and lost in the Big Company I'm at now.
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...
/\/\icro/\/\uncher
Why is it all of a sudden whenever someone says "Virtualization" they imply that it must be Vmware/Xen/windows/x86 platform.
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...
And if the software doesn't require a dedicated machine, the IT department wants one. The company I used to work for would buy a new machine for every application component because they didn't want Notes and a homegrown ASP application to conflict with each other. Seemed like a waste of hardware in my opinion.
Please tell me it's not daisies.
Best Slashdot Co
A lot of our customers have been convinced to run vmware ESX for their servers, our (GIS) apps are very cpu/IO intensive and perform really lousy on vmware. At our own network we run el-cheapo "vmware server" This also perform very badly, and i cant see it really doing anything other than light loads. And why is vmware so paranoid about performance ratings? I mean they are REALLY ANAL about it see this for example: http://r.vresp.com/?XenSource/374d47d120/874970/eb 5243d7c7/076d584
look at all the "[REDACTED]" things.... WTF?!
Furthermore wee have had a lot of problems getting the virtual (windows) machines to keep correct time, seems to be related to smp on the host.
Even better, now IT workers can take (virtualized) servers with them when you fire them!
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.
-Lod
As long as we're on the subject, does anyone have any opinions about whether VMware or Windows Virtual Server is better and why? We're actually in the process of spec-ing out our first virtual server, as we speak, and we're having an argument over which one to use. Are there any other virtualization technologies we should be considering?
Sit, Ubuntu, sit. Good dog.
sounds like sour grapes and a piss poor implementation to me. why didn't you just install more NICs if that was the problem, or more ram, more CPUs etc if that was the problem?
-Lod
Indeed. If you have a proper ESX configuration: At least two hosts, SAN back-end, multiple NIC's, supported hardware - you'll find that almost none of the points are valid.
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.
- It's not the Macs I hate. It's Digg users. -
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.
Weaselmancer
rediculous.
Sandbox, Test, Development. Those are the environments that just scream FOR virtualization. Obviously, your organization needs a lesson in virtual architecture. Sounds like you purchased your services from Andi Mann. Trust me, based on what I read in the article, the guy has no idea what he is doing.
In a desparate attempt to get FFXI installed on my linux machine I resorted to attempting to use VMware
Ummm... Exactly how desperate does one have to be to attempt that???
"All great wisdom is contained in .signature files"
The most jaded geek has never dealt with mainframes. We've been doing some of this stuff for years. About time you all caught up.
It's a toolbox. Regardless of if you are in IT or a mechanics shop, you need the right tools for the right job. I'm so tired of hearing at work how better one language is to another, or how this technique is superior to that technique. It's all a matter of what your trying to accomplish. You should ask your self if this best accomplishes the mission or not. Everything has it's +'s and -'s, just be a Man(Woman)and accomplish the mission. Get the job done, and use the tools available to you that best accomplishes the tasks at hand in the most timely manner.
I'm considering building a vbox (linux,xp,vista) but I'm not sure what I would gain over my current setup of three shuttles linked via a kvm...other than the electric bill.
I lose graphics acceleration, except for which ever OS acts as host. Anything else lost?
Why is all the good stuff already modded 5, when I have mod points?
It is called the hype cycle, as popularized by Gartner. See: http://en.wikipedia.org/wiki/Hype_cycle
We just started setting up xen for our webservers this week. We have plans to move our legacy cobol applications to a vmserver in the future. Those applications have a lot of disk i/o. We've found that NFS works nicely in xen, so our plan was to put the files that need editing on a fast network share. Would doing this still cause an i/o bottleneck in the vm? My assumption was that only 'local' i/o would be an issue. Does anyone have experience in that area?
Xen can migrate with effective downtime of one ARP request (peers must reaquire the Ethernet address of the host when it's moved), effectively about 40ms or less. One of the Xenoserver project papers describes migration of a live Quake server with no perceptible downtime.
Note that this happens by copying dirty memory pages from source to target, and assumes some form of networked storage (NFS, SAN, NAS). The actual migration process may take a few minutes, but the service interruption is minimal.
Use caution assuming that your dying server will perform sufficiently reliably to pull this off in all circumstances. Yes, you can lose VMs.
Actually, the sad thing is the vendors who insist that their (cough Deltek, cough) application not be on a machine with any other applications.
We have at my work some old boxes that should be retired & would be great canidates for virutualization (two tier db app on old xeon500) where the vendor won't support the app in a virtual environment due to resource issues - but the will support it on old crap hardware.
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?
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Sorry, but we aren't buying an AIX mainframe. Just not happening. We lack the budget, the trained people, etc. Never mind the fact that the cost of one mainframe exceeds the cost of all our real, physical servers.
x86 virtualization is of interest to many people since they are running lots of x86 boxes already and it offers the ability to simplify that and save money. For example one small area that we use VMs for are scanner servers. We have these copier/scanner jobs with crappy software, each one needs its own server. Well, rather than buy 6 servers, we have one server with 6 virtual servers on it, works great.
It's not really useful to compare standard solutions to big iron. They are in different classes in every way, performance, price, etc. I don't care if IBM has a really awesome VM solution for their mainframes. We aren't going to be buying one. I do care what kind of VM solutions are available for x86 systems. We have thousands of those, and thus there's a consideration.
Except that mainframes never had a place in small to medium business. An assemblage of commodity hardware has a major advantage over the big iron: it's scalable from a single x86 server up. Also, you aren't tied to any hardware vendor for all of those commodity pieces. These are the reasons why hardly anybody uses mainframes anymore.
How things work, why things don't work, where is it slow, etc.
.NET framework. Since 2.0 was going to be released shortly, they gave us some code to put in the global.asax to go around the .NET call and use Win32 libraries instead. That worked great.
We use SQL Analysis Services on our project, obviously it cannot be virtualized.
Our website, on the old ASP.NET 1.1 version, for whatever reason when the server was virtualized authenication and authorization requests slowed down tremendously. Like it was taking 30 seconds to authorize a user, basically checking if they were a member of an NT group.
I initiated a call with Microsoft, we did network traces and such and came to the conclusion that there was something wrong with the
We've recently converted to 2.0 and the problem went away.
But the point is, without taking that time to troubleshoot exactly what had become slow, our initial impression of virtualized hardware was also pretty low.
But the fixed site, the new site running on virtuals is just as snappy as on physicals.
The article is so brief and so pathetically and obviously assailable on so many points (perhaps all of them), and some of the "comments" on the page really look scripted in advance.
Something's fishy.
Slashdot? Oh, I just read it for the articles.
Examine that quote from the article closely. See anything there that indicates virtualization "doesn't work"? No, nor do I. What they are talking about here has nothing to do with how well virtualization works, what they're complaining about is that a particular tool requires competence to use well in various work environments. Well, no one ever said that virtualization would gift brains to some middle level manager, or teach anyone how to use an office suite, or imbue morals and ethics into those who would steal; virtualization lets you run an operating system in a sandbox, sometimes under another operating system entirely. And it does that perfectly well, or in other words, it works very well indeed. I call FUD.
I've fallen off your lawn, and I can't get up.
'Nuff said.
I agree that people who view vendor lock-in as a proprietary-only problem are complete fucktards. The situation you've described can happen with any technology, open or closed source. Maybe "technology lock-in" might be a better term.
We were one of the first organizations to roll out Cisco's VOIP solution around 6-7 years ago. The company that came in to help us do it had never done one before in a live enviroment (test labs *DO NOT COUNT*), and there was nobody else (aside from Cisco themselves) who knew shit about the system. The result was a half-broken phone system for the first two years.
Things got better and overall the move to VOIP was beneficial for us, but for awhile it was a complete nightmare. Being an early adopter can certainly make you go grey early.
Hopefully your situation works out for you. It might turn out to be a great thing if you can weather the early storm.
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.
Sure you do- the virtual server is running on hardware, after all. You've just moved the complexity to where the virtual server doesn't see it, so it's somebody else's problem.
I am not a sig.
Our VM's running AIX on Pseries hardware run the big stuff just fine. A bit more complex on the front end setup but very solid performance and reliability. Its also very easy to clone servers as well as adding and subtracting resources.
Telecommuting! What about socialization?
How, exactly, is this news? Basically, the article says you can overload a server and slow it down, or have major issues if the whole system goes down and takes all associated virtual machines down with it.
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.
Interesting comments. A lot of very good opinions, and I am always happy to see these issues discussed. And I am happy to learn from all of you too.
/. space with more of my comments. I just wanted to address the perceptions raised in this thread. But my email address is below - feel free to email me if you want to continue this discussion with me directly. You can also check out EMA's website to find out more about me (including my bio - which several of you seem to think somehow affects the facts), and look at some of EMA's research into virtualization (some of which is free, btw).
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/
Vendors are my big pet peeve. I have one vendor that won't talk to any WMWare customer with a problem until they reproduce the problem on physical hardware. I'm certain that taking it off a VM has never fixed any problem, but they insist. This is the type of company that sells you a $100,000 software package, then charges $20,000 a year, then makes you hire a certified tech a call in a callback key for every upgrade or module activation (the customer is not allowed to call), also to use a hardware license HASP on all servers and config workstations. After jumping through all those hoops, they insist on the software being installed on physical hardware and the file and db server being seperate boxes.
The really funny part is that the minimum system requirements are a P3 with 256 megs of RAM. They really woud rather you put the software on two P3s than on one quad proccessor server with 32GB of RAM.
and among our advertisers unsurprisingly is Microsoft.
you gotta hate virtualisation, Microsoft !
is ideally suited to developing and introducing new stuff to the real world.
If it causes problems, then shift it to it's own box, but if it works fine virtually - then just leave it be.
>> 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. I think the analysis is a bit more complicated. Certainly, there are things I just wouldnt virtualize, like a database server. But other things, even if they do have spikes, should be fine to virtualize. A reporting server is a great example. Throughout the day, there are few hits as users occasionally pull up a pre-generated or dynamic report. This is great since usage is spread out. During the night, the server is on full capacity, as millions of reports are generated. High usage, but all during the night. I would feel comfortable virtualizing this with another server that, say, runs a lot of batch processes during the daytime. The spikes dont co-incide, so its OK.
Virtualization is a fad.
But it really shows is the limitation of present day OSes: the only capability a VM gives you an OS cannot is running several OSes on the same computer (duh), which is more of a user thing than a server one.
Everything else are capabilities OSes should have, but don't, especially on the process management side.
Wishlist:
- being able to move a running process (or sets of processes) to a different machine, or clone it.
- being able to allocate ressources to processes (or sets), or even subprocesses (think webservers).
- being able to update drivers, or even the OS, without rebooting the box, or at least with an instant restart as-it-was (app design is also to blame here).
- better isolation between processes, esp on Windows. Ideally they shouldn't even be able to know what else is also running or installed (unless I want to). chroot jails work great on Linux.
- better separation between kernel and APIs, so I can update one without the other as required (think java and such like).
- *anything* to do with apps should *never* require an OS reboot. Follow my sight.
- More persistence. What's with the mess with login/logout? I want to be able to interrupt a session and resume were I was. Even after a reboot. Yeah, screen is great. It's also very much tacked on. And it should work with X too. If I'm changing my environment in one session, I want to be able to push the change to the other sessions, not log out and back in so that profile/bashrc gets reexecuted. And no, I don't want to reexecute it myself: if I overrode something, it should stay the way it was. Oh, and I want to be able to undo, too. Notepad can do it for chrissake! Basically *ises are missing the concept of session.
Don't get me wrong, I think virtualization is great *now*. But I expect OSes will allow you to do pretty much everything they offer in a few years' time. Then virtualization will become niche.
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 dovetails hold items together instead of screws is amazingly useful sometimes.
Weaselmancer
rediculous.
In my organisation we recently moved an entire data centre to virtualisation (400+ servers). I'm a supporter of virtualisation, but there can be a lot of pain associated. Some of our pain includes :-
a) Poor planning - Unfortunately the virtualised environment we run support only a specific type of load balancing. Our IT people didn't realise this as there was a fair amount of pain for existing apps that had to move.
b) Poor estimation - Very easy given management pressure to severely underestimate the number of hosts required. Even if you do get the estimation correct management is always going to trim it back. With physical servers you don't have this problem. Everyone suffers, not just one team, or one application, when the number of hosts is trimmed back in cost cutting measures and IT have to spread the load.
c) Small outages become major outages - Not really mentioned in the article, but if you experience a disk outage you aren't loosing 1 guest, you are loosing 5 to 6 guests. Real pain in an enterprise environment.
d) IT stuck in virtualisation frameset - IT agree that some things aren't virtualised (DCs, SQL, E-mail, Monitoring etc), but they can get a little weird and insist that 1 host run only 1 guest that is a business application, '..because that is how we run all applications servers.'. It's fairly obviously that maybe there are some exceptions, but inflexibility starts to occur because they worry about the flood gates opening.
e) Averaging performance - Agree with other posts that averaging performance is a really terrible and excludes spikes, the statistics provided by our virtualisation environment do lots of averaging making the reports look really nice to management that we have plenty of capacity. However you ask interesting questions like '... why does the host never report 100% utilisation?'... ahh, because its averaged.
f) Complexity - When something didn't work previously the troubleshooting steps were fairly simple, under virtualisation issues with performance, weird OS behaviours become really challenging and people end up pointing fingers and wasting a lot of time.
g) QOS - Virtualisation that we are using isn't great at ensuring a quality of service. Sure the guest may normally be only utilising 5%, but when I need that 100% I really need it. Measuring what a server is able to deliver and ensuring that quality of service levels are met, not just on average, but when I need it is important.
I support virtualisation, but think its extremely important for organisations work on how it will be managed as it is more complex and requires more skilled technicians.
No, it doesn't. By running more than one server on one piece of hardware, you no longer need a hardware monitor for each server, just for each physical machine.
Not exactly. You're virtualizing the hardware. The virtual machine is hardware-independent.
The host is an easy configure. If you had to replace a host due to a hardware problem, it's a lot more simple then re-installing a Windows or Linux box, restoring the configuration and everything else, etc. (Especially Windows.) VMware's ESX server can set up in minutes. With ESX3, all the VM configuration and data is stored on the SAN. Basically, you do the install of ESX which is pretty darned simple, give it an IP address, and add it to the host cluster. Then it's done. Start up virtual machines. The best thing is, when you've got Vmotion enabled, you can hot-migrate your VM's to other hosts if you have to perform hardware maintenance or ESX software updates.
Every single virtual machine will share exactly the same virtual hardware. Sure, you might have one with more RAM, another with an extra virtual disk, or another with 2 or 4 CPU SMP. But those things are trivial - the drivers are all identical. You're also allowed an extra level of protection on things like memory errors - you can detect them on the host, and there's very little chance of memory errors corrupting memory in a VM.
You can move your critical server systems around without dealing with hardware compatibility or re-installation issues.
Really, you need to see a well-configured ESX cluster in action, in daily use. There's not much in the data center that's easier then managing virtual machines. Nothing is difficult. (When it comes to managing the servers themselves.. I can't speak for what software you're running ON those VM's!) Need a snapshot? No problem. Replacing hardware with something newer ans faster? Easy. Replacing a faulty system? Simple.
Not to mention the fact that you get more bang for your buck - you can run a lot of virtual machines quite well on any modern server with enough RAM.
- It's not the Macs I hate. It's Digg users. -
basicly you spend a lot i mean a damn lot of money on super fast hardware and expensive SAN's
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.
I know you're out there. I can feel you now. I know that you're afraid. You're afraid of us. You're afraid of change.
I must be a fucking lunatic. You're worried about running multiple systems on one box? I'm trying to find easier ways of running one system on multiple boxes.
Maybe it's a matter of scale.
My development teams however can go virtualised and like it - if there is something they're doing that's heavily IO constrained then they can ask nicely for dedicated hardware. The ease, speed and simplicity of providing new virtualised dev environments is not to be mocked.
There are tons of companies and ppl who can and will sell or give you help. You are not locked-in. xen is pretty straight forward. If you like, simply post who you are, and you will get loads of company who have a lot of experience with xen. The only thing is, I am still trying to figure out how you got modded up.
I prefer the "u" in honour as it seems to be missing these days.
As a guy who has only had one or two servers at any time, in his home, how does virtualization really help in the real world? I get the basic idea, you can run multiple "virtual" computers inside of one real one, some host. But when is this necessary? I see the basic argument being that, if you have 10 computers each only utilizing that machine 1% or so, just make them all virtual running on one machine. This cuts space and power requirements, and associated heat.
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.
"I dont know what i know, but one thing I do know and that is; 'that i know what i dont know'."
:)
Ahh grasshopper, on first impression one would think that such a good thing, because:
"It ain't what folks don't know thats gets them in the most trouble, it's the things they think they know that ain't so" Will Rodgers (or a close paraphrase of something he said anyway)
However one should be endeavor to be more agnostic on the certainty of ones agnosis of things one has yet to grok, a logically recursive blackhole this is.
Sorry to pick on your tagline, actually I like its recursive illogicality.
Wabi-Sabi
Matthew
for virtualization... then what the hell were you doing putting those tasks on that box in the first place? it seems that the systems people are saying are ideal for virtualization, really shouldn't have been homed on the hardware they are on in the first place..
Darwin Hawking Blackmore
Thank You for making the Point that needed to be made! Where are mod points when you need them?