Who ever said moving VMs from one physical server to another was a way to improve stability or manage server capacity wisely?
Apply today for a FREE subscription to CIO Magazine!
Who ever said moving VMs from one physical server to another was a way to improve stability or manage server capacity wisely?
What do you think a Microsoft kool-aid drinker who has never even seen or used vMotion is going to say. Why don't you try asking a VMware admin that uses vMotion everyday in a production environment about the value of vMotion. I guarantee they will not say it's a cool gimmick but a valuable feature and will rate it much higher then a 3 out of 10.
The article makes a good point in that you should be able to justify using certain technologies or features rather than implementing these items because of their "coolness" factor. Likewise you should plan your server loads (virtual or physical) to ensure that you aren't over loading servers. But here are a few to consider in favor of being able to migrate a VM while it is running.
1) Let's say my host server starts sending alarms of a pending failure. Should I keep running on that host until the weekend or should I migrate the VM. Duh - I should take the option with the least risk. Now unfortunately, the article doesn't give an indication of the risk of migrating a VM on VMware, but based on the experience of many users, it would be far less risky to migrate the VM rather than leave it on a host that will potentially fail. Of course, if you want to migrate with Vmotion, you'll experience no downtime (well it'll drop a ping - but applications won't be impacted). If you go with Quick Migration, well as a Microsoft document describes it, you'll be able to migrate with minimal downtime. So you'll loose applications connections and the like. Perhaps, if you're committed to a Microsoft Hypervisor, you'll want to leave it on the failing host until Hyper-V can do something a little closer to Vmotion. Is Vmotion perfect - no, but to dismiss it as a risky without adequately testing it is unfortunately passing on a really good feature (and perhaps negatively impacting your SLA).
2) The article suggests that there is a risk in migration due to patch level, access data, network location or other issues. Perhaps it would be good to have a software package that checks that migration will be possible and safe. But there's good news - the software is called VirtualCenter. It's unfortunate that Kroll chose an data-center strategy is which something like that would seem to be easy to do (i.e. their "unforgiving environment").
3) It's great to be able to adequately size and plan servers such that they only run at 80 % CPU and never higher. But the reality is you can't unless you provision your hosts with a lot of spare (or perhaps wasted) capacity. Being able to migrate either manually or automatically is a great way to take care of problems like that.
4) The article suggests that it's good to keep 10 % of your capacity in reserve and to even keep it running? I'm a bit of a tree hugger and that doesn't sound too green. Wouldn’t it be great to shift VMs (safely of course) and power down some of the infrastructure when it's not needed? That would not only be green for the environment, but it would put some more green into your pocket. Great news again, the feature is here today (experimentally) with VMware's DPM. And don't worry, Microsoft will be doing it in a few years.
Kroll is right to evaluate the risk of migrating VMs. Anyone looking at the technology today should be and should evaluate the technology adequately. Dismissing a feature without some real study (which this article doesn’t present) is unfortunate. And I wouldn't recommend it with Quick Migrate if you can't afford downtime. But down the road we'll all be doing it and conversations like this will be in the same category as the myth of "a PC will only ever need 640K".
I can understand the writer's position. I don't agree with it, but I do understand it. I have encountered this mentality over and over and over again at many, many of the customer accounts I've worked at (lots of Fortune 100 companies - lots of production environments). In some respects, I do agree with the author - VMotion (or any live migration technology) is not a mandatory feature. A virtual environment provides significant value without having the ability to move workloads (i.e. VMs) around without shutting them down. It's not mandatory, just like a heater is not mandatory in your car - but it is certainly nice to have!
Just as OS technologies have advanced over the years (remember DOS and CPM???), so too has the infrastructure that supports them. I'm old enough to remember people arguing that a single computer should not host more than one application - there were too many opportunities for "adverse interactions" or "performance bottlenecks" -- sound familiar? What's the difference between those attitudes and the resistence to change evidenced by the author of this article? Not much.
Remember things like manual transmissions, manual steering, and manual brakes in cars? You don’t run into those very much any more (sure, enthusiasts still like manual transmissions – but unless they’re a professional, chances are good that the average automatic will wring better performance from the car!) – and there’s a good reason for that. The technology that shifts the transmission, modulates the brakes, and regulates the steering is better than the average operator! Some things were meant to be automated – capacity management is one of those things (do you stoke your wood-burning stove, or do you let your thermostat regulate your natural gas furnace??)
The beauty of technology is that it takes over the mundane, repeatable tasks and frees the "mere mortals" among us to spend our time contemplating the finer things in life – like how to derive more business value from the assets that are available to us. VMotion, Dynamic Resource Scheduler (DRS), VMware HA, Distributed Power Management (DPM), Site Recovery Manager (SRM) [all VMware technologies, but I’d be just as happy to see them from another vendor!] do just that. They take the low-level task of micro-managing the capacity in your virtual infrastructure out of the hands of your administrators. This frees them up to do more important things like develop improved processes and procedures that enable them to more effectively meet the demands of the business unit (without whom the IT department would not exist) – and maybe, just maybe, save the company some money.
So…yes, I do understand the author’s perspective. And yes, I disagree with it. And I suspect that in a few years, the author will discover that his current position rather resembles that of an ostrich with his head in the sand (hindsight is, after all, 20/20)
I agree with the points the others have made. vMotion can be an invaluable feature in a data center. Is it a necessity, no, but it is a requirement for certain features to work like DRS, DPM and HA. You may think you don't need it until you've actually used it and experienced it, then you'll wonder how you ever did without it. I can tell you from doing hundreds of vMotions that I have never experienced an issue with it and it has never caused a problem with a VM.
The author could not be more incorrect in this article. Microsoft themselves realize the value of hot migration but unfortunately their hot migration technology did not make it in the first build of Hyper-V. Make no mistake, it's coming, and with as much patching as Microsoft platforms are prone to, they need it. VMotion has saved me a lot of downtime in all of my environments: Lab, DEV, QA, and Production. Without VMotion I'd be buried in additional change management paperwork to shut down VMs in order to perform host maintenance. Add DRS to the equation and now I have well balanced hosts in terms of resource utilization.
Agreed. The author of this article is a rube. I supposed if you aren't a fan of zero downtime, improved reliability, satisfied customers, etc. then you wouldn't be interested in VMotion and the other features that it enables (i.e. High Availability, DRS, etc.)
The headline is fit for a tabloid,
"Is One of VMware's Best Features a Really Bad Idea?"
With a headline like that I would expect some serious content, some groundbreaking revelation instead it reflects the unsubstantiated opinion of one guy/company. And then there is the long introduction, working towards the climax of revealing some deep insight..but it never materializes.
Mr. Steffen keeps talking about "risks" but the article doesn't really mention any details. I would like to have a glimpse at the risk assessments that lead to those "risks".
What seems risky to me is betting in 2003 on Microsoft Virtualization products!
There is no substance to this article. There are claims of risks but no details.
This whole article is one big "Dum Moment". Everyone has a different risk tolerance so maybe Mr. Steffen made the right decisions for his particular case but that certainly can't be generalized. Similarly he could just have based his decisions on a flawed risk assessment and came to the wrong conclusion.
Osama S.
To treat this article seriously I would also love to read about someone's opinion who used VMotion in production and found any real risks to mention and refused to use it because of those.
IMHO VMotion itself is a very cool thing to avoid planned downtimes. But the real diffirention for VMware are DRS and Storage VMotion made atop of VMotion and clustered file system VMFS. DRS saves you a lot of administration time balancing all your VMs performance while different apps may have unscheduled and distributed picks during a week or month. SVMotion automates moving VMs from one storage to another e.g. if you've discovered I/O problems. Manual downtime would be an hours and days. Without clustered FS you have manually setup LUNs for each VM and that's not any admin in the good mind want to manage. Microsoft comes not even close here as NTFS has to be competely replaced to make it working.
At my personal experience I sow no any single person who tried VMotion(s), DRS, HA in production environment and even had a secund of thinking to revert it back to the simple server partitioning!
It also has a very simple economic result of tripling administrator's performance: ability to manage a 3 times more number of servers (VMs) during normal working hours
It should be noted that Kroll Factual Data is Microsoft's poster boy of a reference case - the only one that's every referenced publicly. Yes, they used Virtual Server and now Hyper-V. Their parent uses VMware. Congratulations, Kevin on caching in your Microsoft paycheck and repeating Microsoft FUD about the lack of usefulness of VMotion since Microsoft doesn't have it. You can already read from the rest of the comments that people that are actually in IT and use these features on a daily basis to do their jobs do find uses for it. Perhaps it's time to visit a datacenter and get out of the writing business for a little while.
vMotion and DRS is an incredibly useful tool when it comes to alleviating downtime. I use it daily to balance loads across nodes. This way my users do not experience performance issues. DRS does automate this for me as well. vMotion also allows me to manage patches/hardware upgrades/etc to the base ESX servers as well. My VMs do not suffer any downtimes. It is not a 'cool feature' It is a NECESSARY feature in any virtual environment. It is possible to live without it, but that generally means buying more hosts to run less VMs on them, penalties for not meeting SLAs, or doing updates after hours where overtime costs often come into play. You can map a direct monetary value to the lack of vMotion.
There's a lot of buzz about Windows 7 out there. Each month in our webcast series, listen to analysts and customers discuss how Windows 7 and the Windows Optimized Desktop is impacting large companies around the world. Learn how they evaluated Windows 7, including the cost of deployment, deployment strategies, and tangible benefits.
Sponsored by Microsoft
Listen to on-demand Recordings »
Service Level Management Best Practices Life Cycle Overview - Improve Service Levels
Best practices for Service Level Management (SLM) is a process for consistently meeting customer requirements and delivering on IT's promises. See the steps required to ensure high-quality SLM.
Sponsored by Compuware
Read this White Paper »
Keeping Your Members Safe from Online Scams and Predators
In order to keep fraudsters out, romance sites must deploy effective solutions that look at information independent of what is supplied by users. A device fingerprinting solution such as iovation ReputationManager™ provides unique insight into the computers being used to create multiple accounts and exposes hidden device-account relationships that identity-based fraud solutions often miss.
Sponsored by iovation
Read this White Paper »
| CIO MARKETPLACE | buy a link![]() |
Use your Intranet to manage Software Licenses, plan for Windows XP/2000 upgrades, do Security Audits and more. Click to try and ask for our white paper - PC Management for the Internet Age.
UNIX and Linux Performance Tuning SimplifiedSarCheck is a performance analysis and tuning tool for most UNIX & Linux operating systems. It produces recommendations with full explanations, and both supporting graphs and tables. Get the most from your hardware by keeping your systems tuned.
.NET Developer Wanted - Boston - Local CandidatesAIR provides sophisticated analytical tools and software systems to help companies manage that risk. We are seeking a Sr .NET Developer with 8-10 yrs exp in .Net & OO development. ASP.NET, VB.NET skills required. Annual bonus - Apply Now
Get More from Your Oracle DatabaseDBAs are constantly challenged to increase performance and keep costs down. This paper discusses the industry best-practice Wait-Event analysis and how Confio has combined this with their Resource Mapping Methodology to optimize DB performance.