Keith Ward over at Virtualization Review pens a piece comparing the downtimes that occur when Hyper-V attempts a Quick Migration and ESX completes a VMotion. Keith has some excellent points associated with the problems of extended migration times, but there's one area where I think he needs to add extra emphasis. Keith mentions:

With that caveat in mind, it's a fascinating demo. It shows a Quick Migration of a Windows Server 2003 VM from one physical machine to another. At the same time, a Microsoft Dynamics client is trying to access a database residing on the VM. Through a constant ping of the VM, we can see how a) the connection to the VM is dropped for a time, and b) how the Dynamics client fails in its attempt to get the database information (an error box pops up, showing a TCP failure). Shortly thereafter, another popup informs us that the VM has actually been deleted! It's re-started a few moments later. In addition, a network file copy that was initiated on the VM also failed during the Quick Migration.

The video is, naturally, a worst-case scenario, but from what I saw, it could (and will) happen sometimes. The question for those considering Hyper-V is whether these types of interruptions would happen often enough to impact your business. After all, the Dynamics client will retrieve the information after the migration is done, so it's not like you'll never be able to access it (after the user re-initiates, though. That's an aggravation). Same with the file copy; just re-start the copy after the VM restarts. You won't have to wait a day, an hour, or even five minutes to do the task; but you will have to start it all over again.

VMotion is a mature feature that's been successfully doing hot migrations for years now. With ESX and VMotion, the hot migration very obviously completes quickly. Quick enough that clients never even notice the downtime -- we're talking about on the order of a single lost ping packet.

Microsoft's Quick Migration takes a bit longer. In some cases up to 60 seconds or more depending on the size of the virtual machine. This is an exceptionally long time, and one that I suspect will get better upon the release of the product and with subsequent updates.

But, what is important about either Quick Migration or VMotion is that these sorts of hot migrations are typically reserved for one of two functions: Planned downtime and load balancing. With planned downtime, an extended outage like the one Keith discusses is likely to only occur during standard outage windows when users and their clients are less likely to be using the servers. Thus, Quick Migration's added delay shouldn't necessarily impact operations in this case.

The other case, load balancing, is harder. ESX when in fully automated mode can rearrange its load constantly throughout the day. In a Quick Migration world with extended outages like we currently see, this simply isn't going to work from an operations standpoint.

But, there's a cost impact too. ESX at this point is still substantially more expensive than Microsoft is positioning Hyper-V. For environments that don't plan on the need for high-end, automated load balancing, Hyper-V's Quick Migration has the potential to solve the virtualization problem at a much lower entry cost. You need to make the decision for yourself whether the delay reduction is worth the cost.

I get accused a lot because of this line of thinking of being anti-VMotion. That's not the case at all. In my mind, VMotion is an excellent high-end solution that gets far too much attention for its coolness-factor. In many environments, VMotion can be an expensive red herring. IT organizations need to really understand their needs before they get swayed by the VMotion wizz-bang.

What do you think? Do you consider VMotion wizz-bang or an absolutely critical component of any virtualization environment?

Read and comment on Keith's piece at: http://virtualizationreview.com/blogs/weblog.aspx?blog=2124#post