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.

Comments

Yawn

[dreamchaser]

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.

Re:Yawn

[WinterSolstice]

Yes - we have quite a bit that we just put in here at my shop.

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

[Anonymous Coward]

re your sig:

An operating system should be like a light switch... simple, effective, easy to use, and designed for everyone.

Did you know that in the US, light switches are traditionally installed with "up" being "on", while in England they are traditionally installed with "down" being "on"?

Perhaps instead operating systems should be like nipples, everyone is born knowing how to use them, and they don't operate differently in different countries ;)

Re:Yawn

[Anonymous Coward]

First time I've ever posted anon...

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.

Re:Yawn

[vanyel]

Virtualization good: Webservers, middle tier stuff, etc.
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

[dthable]

I could also see their use when upgrading or patching machines. Just take a copy of the virtual image and try to execute the upgrade (after testing, of course). If it all goes to hell, just flip the switch back. Then you can take hours trying to figure out what went wrong instead of being under the gun.

Re:Yawn

[WinterSolstice]

"Modern processors are way overkill for most things they're being used for."

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

[cbreaker]

Your bug comment is kinda moot - it's not a normal problem with virtualization.

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

[OldeTimeGeek]

Has to work better than what I've tried. Besides, if I say I read it on Slashdot, they gotta submit to my advanced research skillz...

Re:Yawn

[afidel]

Well, our Oracle servers are DL585's with four dual core cpu's, 32GB of ram, dual HBA's backed by an 112 disk SAN and they regularly max out both HBA's, trying to run that kind of load on a VM just doesn't make sense with the I/O latency and throughput degradation that I've seen with VMWare. I know I'm not the only one as I have seen this advice from a number of top professionals that I know and respect. If you have a lightly loaded SQL server or some AD controllers handling a small number of users then they might be good candidates, but any server that is I/O bound and/or spends a significant percentage of the day busy is probably the lowest priority to try to virtualize. You can probably get 99+% of the benefit of virtualization from the other 80-90% of your servers that are likely good candidates.

Re:Yawn

[WinterSolstice]

That's obviously just an example - uptime doesn't provide high-water marks, etc

Ahh, slashdot. People just *love* to split hairs :D

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 :D

Re:Yawn

[WinterSolstice]

That's really awesome, and obviously your systems are a great use for VMs :D

Our web stuff virtualized *beautifully*. We had few to no issues, but we ran into major problems when mgmt wanted to virtualize several of the other systems.

And since when is a warning about an unfixed bug moot? It's an *unfixed* bug in ESX Server Update 3. When it's patched in the standard distribution, then it will be moot.

VMs are still quite a new science (as opposed to LPARs) so there are lots of bugs still out there.

Re:Yawn

[ergo98]

I know I'm not the only one as I have seen this advice from a number of top professionals that I know and respect.

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

[rhaas]

If you're blind, then why do you care about the light switch in the first place?

Re:Yawn

[giminy]

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.

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

[herve_masson]

Virtualization good: Webservers, middle tier stuff, etc.

Virtualization *insanely* good: development !

It simply changed my programmer life entirely. How can I keep machines with any flavor and version of the linux boxes I'm working at which can be booted in seconds ? How can I have a (virtual) LAN with dozen machines communicating to each other when developping a failover/balanced service ? How can I multiply the number of machines by a cut'n'paste operation ? I do I rollback a damaging crash or a faulty operation (via snapshots) ? The whole thing even fit in my workstation and works beautifully.

VmWare is the most beautiful and useful piece of software I ever used I think, even with those stupid clock problems when running certain bsd/linux environements.

Jeez, I could not even think of working differently now. For me, this is more than a useful tool; this is a revolutionary tool that makes my job possible, which obvioulsy does not mean it's good and rosy for anything on the planet (who thought it was ?)

Re:Yawn

[T-Ranger]

Well, disks may not be a great example. VMWare is of course a product of EMC, which makes (drumroll) high end SAN hardware and software management tools. While Im not quite saying that there is a clear conflict of interest here, the EMC big picture is clear: "now that you have saved a metric shit load of cash on server hardware, spend some of that on a shiny new SAN system". The nicer way of that is that both EMC SANs and VMware do the same thing: consolidation of hardware onto better hardware, abstraction of services provided, finer grained allocation of services, shared overhead - and management.

If spikes on one VM are killing the whole physical host, then you are surely doing something wrong. Perhaps you do need that SAN with very fast disk access. Perhaps you need to schedule migration of VMs from one physical host to another when your report server pegs the hardware. Or, if its an unscheduled spike, you need to have rules that trigger migration if one VM is degrading service to others.

Re:Yawn

[cbreaker]

It's moot because it's a specific issue with a specific hypervisor, not a problem inherent with virtualization itself.

There's some things I won't virtualize right now, and that's two of our very busy database servers and the two main file servers. Part of it is for the performance of those systems, but part of it is also because I don't want those systems to chew up a high percentage of the overall virtual cluster.

I don't think x86 VM's are a new science anymore. They're just somewhat new to the Enterprise. VMware released their first product in 1998. In the computer world, nine years of development for a product/technology is a good deal of time.

Virtual machines have different performance characteristics then actual physical servers, and different hypervisors can change things as well. You do need to take special precautions when going virtual, but the effort is worth it for the amazing amount of control and ease of use your infrastructure will have.

And the greatest part is when I need a new server, I just click a few buttons on the mouse and hit GO. The VM is ready in moments, joined to the domain and ready to go.

Re:Yawn

[suggsjc]

Wait, I thought this conversation was about nipples...

Re:Yawn

[ShieldW0lf]

I thought this was really funny.

Andi Mann, senior analyst with Enterprise Management Associates, an IT consultancy based in Boulder, Colo., says that virtualization's problems can include cost accounting (measurement, allocation, license compliance); human issues (politics, skills, training); vendor support (lack of license flexibility); management complexity; security (new threats and penetrations, lack of controls); and image and license proliferation.

How many times is the word "License" in here?

Re:Yawn

[Sandbags]

Here's what I've found virtualization has led to: manufacturers going cheap on on board devices. For example, a lot of low end servers that leverage Intel's VT are starting to ship with what I call "Win-NICs" i.e., devices that leverage the CPU for workload instead of a dedicated silicone chip. Like modems did years ago, now NICs are doing. Soon USB and other controllers will start requiring software application layer drivers where they user to operate entirely in hardware/firmware. This has 1 benefit only, cross platform compatibility. However, it sacrifices device and overall system performance, hardware diagnostics, and nice features like PXE boot.

People are jumping on this technology like flees to a dog. Why don't we simply standardize the device layers and have everyone comply with it? Sure, there's room for custom high performance devices, but the basic chips that every PC needs should be the same on everyone's boards, then we don't need VT...

While I'm on the rant... People, PLEASE; DO NOT put all your systems on 1 virtual host server!!!! I've seen a dozen companies consolidate whole farms onto 1 or 2 hosts in VMWare. Before, if you had 1 server down, you had 1 server down. Now you loose half the network! If you want to VM your machines, you need to be using clustered services and redundant NAS systems. I've even seen 4 different moron customers spec that out, but even then put all the cluster nodes ON THE SAME BOX!?!? C'mon, this isn't rocket science. Virtualizing is not to save money, or to limit the number of physical machines you need, it's for system portability across platforms and quick recovery of nodes and point systems through imaging. If you can't afford the licensing to cluster your systems, you can't afford VT.

Re:Yawn

[smittyoneeach]

Steven Wright:

I had a switch on the wall that didn't do anything. So every now and then, I'd flip it up and down.
Then I got a letter from a woman in Germany, telling me: "Cut it out".

Re:Yawn

[giminy]

This may be wrong, but I've always looked at load as the number of processes waiting for resources (usually disk, CPU, or network).

Yep, it's wrong. Load average is defined as the number of processes that are runnable. Processes waiting for resources (at least, resources made via system called, like trying to talk to disk, network, etc) are put on the WAIT queue and are not runnable. Thus, they do not contribute to load. Processes that have all the data they need and just need a cpu slice contribute to load.

I've also seen where load was reported as N/NCPUs and N regardless of the number of CPUs.

The first one is wrong. Out of curiosity, where did you see this?

Even if the real meaning is the average number of processes in the run queue, that does not tell you much.

Yay! You're getting it!

Thinking of it as the number of processes waiting for some piece of hardware seems more accurate.

Oh wait, you're not getting it :(. Thinking of load average in this way is very precisely incorrect.

To be precise, I would say "number of processes waiting for the CPU". Processes that are waiting for non-cpu hardware are placed in the WAIT queue (they aren't runnable) and do not contribute to the load. They will be placed back on the run queue once the data that they are waiting for is available (at that point, they will contribute to the load again). Going back to my other example, if a process is waiting for network data, or disk data, or [insert special whizbang hardware here] data, it will be in the WAIT state, and will not contribute to load. Instead, it will contribute to IOWAIT time. Hence the need for looking at more numbers than just load average.

Generally, processes that are just waiting for a cpu slice will do okay in a VM. CPUs are fast, and there isn't any competition for a virtual CPU slice (except from processes in the virtualized OS). The VM host will (probably) ensure that each guest OS gets a fair share of time. So CPU-intensive processes in a guest will run slower, but they will run predictably slower. Virtualizing processes that have a lot of I/O time are bad, because an I/O-bound process in a VM is really 'competing' for the resource with processes in *other* VMs. This competition is very difficult to quantify or predict, because we're not used to thinking of systems in this manner yet. Remember that these I/O-bound processes are not contributing to load average on their respective guest OS because they are on the guest OS wait queue while waiting for hardware. Hence my original argument that load averages are wholly inaccurate and it is a bad idea to rely on the measurement for deciding whether a system is virtualizable.

Reid

Is this for real?

[Marton]

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.

Waste of time...

[evilviper]

I want those 2 minutes of my life back...

This just in...

[Anonymous Coward]

Really Cool Thing can have drawbacks. Popular computer technology shown not to be silver bullet. Film at 11.

Testing PXE terminals

[Anonymous Coward]

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.

Virtualization

[DesertBlade]

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.

Re:Virtualization

[drinkypoo]

Bandwidth concerns. You can have more than one NIC installed on the server and have it dedicated to each virtual machine.

or, of course, you can use a faster network connection to the host, simplifying cabling. it might not be cost-effective to even go to GigE for many people at this point with one system per wire. For a lot of things it's hard to max that out, obviously fileserving and the like is not such an application, but those of you who have been there know what I mean. But if you're looking at multiple cables to each server and the attendant nightmares it may be just the reason you need to justify that new switch purchase.

Re:Virtualization

[jallen02]

I would say that every single one of those points in the article are being addressed in the enterprise VM arena. In the end due to the raw extra control you get over virtual machines it very much is the future. There is very little memory overhead. Once virtual infrastructure becomes fully developed and the scene plays out completely I think it will actually make the things in the article easier, not harder. You have to pace yourself in how and where you use virtualization in your organization, but the benefits are huge for the right environments.

As far as current day performance goes: disk access is essentially close to if not at native speeds and CPU speed is generally 70-80% of what the native processor can do. Most instructions aren't touched by a virtual machine monitor at all. Memory is more or less untouched and you actually get memory savings. Say you have 4 VMs of Windows 2003 running. All of the pages of memory that are the same (say, core kernel pages and the like) get mapped to the same physical page. The guest operating systems never know. You can effectively scoop up a lot of extra memory if you have a lot of systems running the same software. All of those common libraries and Windows/Linux processes are only paid for once in memory. The technology is simply awesome. In a few years with more and more powerful multicore systems virtualization will make more and more sense, even on performance critical systems.

It has its problems, but I am a believer.

Disk contention is the big shortcoming

[pyite69]

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.

why are we reading this garbage?

[philo_enyce]

to sum up tfa: poor planning and execution are the cause of problems.

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

Re:why are we reading this garbage?

[ndansmith]

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? Have it on my desk Monday morning.

it is all roses for Disaster Recovery

[QuantumRiff]

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.

It's Marketing vs Technologists.

[khasim]

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.

Re:It's Marketing vs Technologists.

[LinuxDon]

While I completely agree with you on this at many other areas, I don't in this case.
The reason for this is that virtualization -simplifies- tech support in every way (except for real-time applications).

Load problems, especially in a virtualized environment are extremely easy to manage technically.
You can just add additional servers and move the virtual machine to the new machine while it's running.

It's the management who will be having a budget problem when this happens, while tech support is not having a technical problem.

excess power

[fermion]

I see virtualization as a means to use the excess cycles in the modern microsprocessors. Like over aggressive GUI and DRM, it creates a need for the ever more expensive and complex processors. I am continuously amazed that while I can run most everything I have on a sub GHZ machine, everyone is clamoring about the need for 3 and 4 GHZ machines. And though my main machine runs at over a GHZ, it still falters at decoding DRM compressed Video, even though a DVD plays fine on my 500 MHZ machine.

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.

Re:excess power

[Gr33nNight]

Here you go: http://www.wyse.com/products/winterm/ We're buying those next year instead of desktops.

We're about 95% virtualized and never going back!

[Anonymous Coward]

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.

Like all technologies, you need a good plan

[caseih]

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.

Re:He must be talking about freeware

[Semireg]

I'm certified for both VMware ESX 2.5 and VMware VI3. VMware's best practices are to never use a single path, whether it be for NIC or FC HBA (storage). VMware also has Virtual Switches, which not only allows you to team NICs for load balancing and failover, but also use port groups (VLANs). You can then view pretty throughput graphs for either physical NICs or virtual adapters. It's crazy amazing(TM).

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 .5 seconds compared to an IBM xSeries 3850 which takes 6 minutes). Oh, and there is the whole snapshotting feature, memory and disk, which allows for point in time recovery on any host. Yea... downsides indeed.

Virtualization is Sysadmin Utopia. -- cvl, a Virtualization Consultant

Home Use

[7bit]

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!

Re:Question: Do cards have to support it?

[db32]

From what I have seen and experienced the VM video card is the issue. The virtual machine uses the virtual hardware drivers so the actual hardware is largely irrelevant so long as the host OS can handle it. In a desparate attempt to get FFXI installed on my linux machine I resorted to attempting to use VMware only to find out that VMware does not support any kind of 3d accel stuff (again, virtual hardware vs real hardware).

Same old "doing it half-assed"

[Jagged]

From the article:

Increased uptime requirements arise when enterprises stack multiple workloads onto a single server, making it even more essential to keep the server running. You don't just move twenty critical servers to one slightly bigger machine. You need to follow the same redundancy rules you should follow with the multiple physical servers.

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.

Worst. Article. Ever.

[countSudoku()]

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.

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 /. and less computerworld. WTF, bring something new to the table. That was just weak.

Hype Common Sense

[micromuncher]

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...

Virtualization != x86

[HockeyPuck]

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...

Re:the sad thing is how much we need virtualizatio

[dthable]

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.

Virtualization Is Not All Roses?

[wiredog]

Is some of it crocuses? Or at least daffodils?

Please tell me it's not daisies.

Re:He must be talking about freeware

[Professor_UNIX]

Not only can you migrate a running VM without downtime

I'm pretty hard to please sometimes, but Vmotion is probably the single coolest feature of VMware ESX. The first time I sat there on a running VM while it was being migrated to another ESX server and didn't notice a single second of downtime while browsing the web (I had RDP'd to the box) I was in love. I was also pinging the machine from another window and it didn't drop a single packet. I really hope they eventually allow this feature to sneak into the free VMware Server and let you use it on NAS data stores for small businesses or home environments, but I doubt it.

Author is completely uninformed

[LodCrappo]

Increased uptime requirements arise when enterprises stack multiple workloads onto a single server, making it even more essential to keep the server running. "The entire environment becomes as critical as the most critical application running on it," Mann explains. "It is also more difficult to schedule downtime for maintenance, because you need to find a window that's acceptable for all workloads, so uptime requirements become much higher."

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.

He must. ESX set up properly avoids most pitfalls

[cbreaker]

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.

Re:Question: Do cards have to support it?

[kcbanner]

Actually vmware *does* support 3D accel now...google it and you can add an option to the .vmx file to enable it.

Also, I suggest trying VirtualBox, it runs really smooth...fast too (xp home intall in 5 minutes), and it supports 3D accell I believe.

Re:He must be talking about freeware

[kv9]

Xen can do live migration

Re:He must be talking about freeware

[div_2n]

I'm managing VI3 and we use it for almost everything. Ran into some trouble with one antiquated EDI application that just HAD to have a serial port. That is a long discussion, but for reasons I'm quite sure you could guess, I offloaded it to an independent box. We run our ERP software on it and the vendor has tried (unsuccessfully) several times to blame VMWare for issues.

You don't mention it, but consolidated backup just rocks. I have some external Linux based NAS machines that use rsync to keep local copies of both our nightly backups and occasional image backups at both sites.

Thanks to VMWare, it's like I've told management--"Our main facility could burn to the ground and I could have our infrastructure back up and running at our remote site before the remains stop smoldering much less get a check from the insurance company."

Re:Question: Do cards have to support it?

[99BottlesOfBeerInMyF]

Nope. The problem is the virtualization itself. Other than KVM and Xen, you can't dedicate the hardware, which means that the virtualization is unable give direct access to the video hardware

Actually VMWare supposedly has direct video card access working on one of their workstation betas and Parallels has announced that they will be including that feature in their next public beta as well. I don't expect video card acceleration to be a major stumbling block at the end of 2007.

A nice buffer zone!

[Gazzonyx]

I've found that virtualization is a nice buffer zone from management decisions! Case in point, yesterday my boss (he's got a degree in comp. sci - 20 years ago...), who's just getting somewhat used to the linux server that I set up, decided that we should 'put /var in the /data directory tree'; I had folded once when he wanted to put /home in /data, for backup reasons, and made it a symlink from /.

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

[terrahertz]

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.

This is FUD

[fyngyrz]

...virtualization's problems can include cost accounting (measurement, allocation, license compliance); human issues (politics, skills, training); vendor support (lack of license flexibility); management complexity; security (new threats and penetrations, lack of controls); and image and license proliferation.

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.

its an egg head solution

[PermanentMarker]

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.