4 Reasons to Upgrade to Hyper-V Server 2012 R2 (or not to!)

Now that Hyper-V Server 2012 R2 is finally available to all, the very big question of “should we upgrade” is on a lot of people’s minds. Some will tell you it’s a “no-brainer” and that you should just do it unquestioningly. In the real world of business, the true “no-brainer” decision is a very rare beast. This upgrade is not one of them.

New Installs

If you’re just now getting into Hyper-V Server, you’re probably going to want to jump right into 2012 R2. As the current version, it’s going to have the greatest focus for improvements and fixes. That alone does not make it a “no-brainer”, though, so keep reading.

4 Reasons to Upgrade

Many compelling reasons to upgrade are found in the features list. What you’ll gain will depend largely on where you’re starting from. I still see a fairly large number of posters on TechNet that are using 2008 R2, and there is even a smattering still using 2008. Even those coming from 2012 have the opportunity for some impressive gains. The new feature list for Hyper-V Server 2012 R2 is available on TechNet, as is the new feature list for Hyper-V Server 2012. Hyper-V Server also works extremely well with Microsoft Failover Clustering. If you have the hardware to build a cluster, you’ll get access to several nice features as well. As with Hyper-V, the complete 2012 MSFC feature list is on TechNet as is the 2012 R2 MSFC feature list. My intention is not to rehash those lists.

To talk specifically about 2012 R2, here are four very good reasons to make the jump.

1. Enhanced Session Mode

The ability to use any screen resolution that your connecting machine supports is a very large draw for this new version. I wish it worked with older guest operating systems, but this is something that will sort itself out in time. My personal favorite part of this is the ability to move objects back and forth without mapping drives or using admin share points.

Enhanced Session Policy

2. Online Resize of Virtual Disks

I’m a very big proponent of taking a few minutes to properly size virtual machines before deployment. In my mind, that saves a lot of effort later. However, I’m also a big fan of thin provisioning, which many are greatly opposed to. Online resize can help split the difference. You can create a disk that starts off initially small and then grow it without downtime. Besides, even people who make an effort to provision properly and use thin provisioned disks can still make errors of underestimation. Online disk resizing also eliminates one of the last reasons people give for pass-through disks.

3. Live Migration Enhancements

If you’re moving VMs around in production on a regular basis, you either have a very large environment or something isn’t right. So, speedier Live Migrations wasn’t high on my wish list. But, I don’t think anyone gets upset when they go faster. The ability to use multichannel or compression to move your Live Migrations is definitely welcome.

Live Migration Configuration

4. Virtual Machine Drain on Cluster Node Shutdown

I really like this feature, even though I probably shouldn’t. Role drain should probably be overseen by an administrator. But, I recently discovered a very good reason to use this. We have Lync deployed in our environment, and most of the Lync roles are not supported with Live Migration (or Quick Migration, or vMotion, or anything of the kind). They live on shared storage though, so we have to mark them as highly available in order to be supported. So, we use the Possible Owners setting in Failover Cluster Manager to prevent those VMs from moving. In order to keep the VM balance the way we want, we set the Preferred Owners on a few of the other guests so that they don’t inadvertently crowd out hosts with more resource-hungry Lync roles. Also, if a host were to die completely, having those guests in HA mode means that bringing them up on a surviving host would be a matter of adjusting the Possible Owners setting. Sounds good, right? The problem is that System Center Virtual Machine Manager (tested in 2012 w/SP1 and 2012 R2) absolutely cannot deal with this configuration. If you instruct it to place one of these hosts into maintenance mode, it flings itself onto the floor and throws a temper tantrum that would embarrass a four-year-old. If you attempt to use maintenance mode with the migration option, you get this:

SC VMM 10434 Error

The error itself makes sense because you can’t Live Migrate the guests and the underpinning logic for Maintenance Mode is just too simplistic to have any idea what to do about it.

VMM’s option to save the guests is worse. All guests are saved and moved to other hosts. The ones that aren’t supposed to move go into a Missing status because, well, they weren’t supposed to move. You can use Failover Cluster Manager to move them back once you stop Maintenance Mode. With Hyper-V Server 2008 R2 and prior, the only solution is to manually shut down and shuffle the guests or design a script. With 2012, you can use FCM or PowerShell to pause the host and initiate a role drain. With Hyper-V Server 2012 R2, just shut down or reboot the host when it’s time; the clustering service will Live Migrate the guests that it can and shut down or save the guests that it can’t (according to their respective Automatic Stop Action setting). When the node comes back up, everything will be set to right.

4 Reasons Not to Upgrade

The decision you’re faced with isn’t whether the new features are impressive, but whether they’ll add enough value to justify going through an upgrade process or skipping an established version to go with the current offering. To make that decision requires an intimate knowledge of your organization. What I’m going to provide you with is a list of considerations that need to be taken into account. I leave the final judgment to you.

1. How Badly Do We Need Those Features?

Before you even begin considering reasons to or to not to upgrade, you need to figure out just what the new features can do for you. We are IT administrators responsible for the technical infrastructure of businesses that supports professionals and customers; we are not home users pondering a video card upgrade to make a video game run faster. We do not upgrade because something is “cool”. Make the business case for these features. If what you’ve got is doing the job and you can’t definitively point out some way that an upgrade will save the organization time, money, or effort, then there is no real reason to upgrade. Wait for a hardware refresh or some other logical breaking point. I bolded “the organization” in the previous paragraph for a reason. Yes, I know you want faster Live Migrations. I know you want Dynamic load-balancing on your teams. We all do. But, it’s not about what the admin wants. If you can’t actually say something like, “I spend eighteen hours per week waiting on Live Migrations to finish and 2012 R2 will reduce that to seven and I can then use those extra hours for functions/projects x, y, and z“, then your organization will not benefit from faster Live Migration and it is not a good reason for an upgrade. Sorry.

2. Vendor Support

One of the biggest reasons many organizations don’t adopt Hyper-V in the first place is vendor support. I’ve had more than one flat-out tell me that they absolutely will not support their software running in a Hyper-V environment. It doesn’t matter one bit if you can prove that it works fine. An unfortunate truth is that a great many software vendors just love to collect licensing fees for software they don’t have to provide support for, and they’ll cheerily find any excuse to not help you. If you’ve worked with business software for about a week, you are probably painfully aware of this. So, if your vendor’s support list doesn’t have Hyper-V Server 2012 R2 (or Windows Server 2012 R2) in plain, clear writing, then you had better pause before making the upgrade. It’s worth making a call to an account representative or support team, but still, this is something you want in writing. That goes double for organization-critical applications.

3. Upgrades Always Involve Risk

From what I can see, the upgrade from 2012 to 2012 R2 generally goes pretty smoothly. But, there are always exceptions. The competent IT administrator will always assume that his or her upgrade attempt will result in utter failure. The biggest risk is hardware. This is the sort of problem that cost me almost an entire weekend when I tried to bump a couple of computers from Windows 8 to Windows 8.1. I don’t know what the exact process is, but it clearly tried to bring the drivers up to new levels and it chose very badly in a couple of places. The server upgrade process works the same way. The RTM bits for Hyper-V Server 2012 wouldn’t install on the HP NL40 we showcase in our sub-$2000 cluster build if the onboard NIC is active. It doesn’t tell you that’s what the problem is; I found out by scouring Internet forums. Does it work with the new GA bits? I have no idea. How confident do you feel about your hardware? Can you get help (see #2)? Hardware drivers aren’t the only problem. What if there’s some unknown issue in one of your virtual machines that isn’t uncovered until you try to bring it up in the new hypervisor? I’ve seen a few issues like that on the forums.

Don’t let this part scare you off. I certainly don’t intend to be a FUD-spreader. It’s just that there are some people out there giving the impression that the upgrade to 2012 R2 is all magic watched over by benevolent fairies so there’s no question that your upgrade is only going to take as long as the installer needs to refresh the bits. I’m sure that will be the case for a lot of people. I’m equally certain that others are going to have a much more frustrating experience. You need to decide if that risk is worth the reward. Keep in mind that there’s a reason that the most-publicized migration path is buy new hardware and Live Migrate from old to new.

4. Never Buy Anything with a Serial Number Under 10,000

That’s an old bit of advice I got from a former employer, and it’s never failed me. Microsoft (and a lot of other companies) get a lot of criticism for not more fully testing their products prior to release. I don’t know anything about Microsoft’s internal structure or processes. Maybe they don’t have enough testers. Maybe their testers are idiots. Maybe their testers are geniuses but the development teams ignore their findings. Maybe the testers and the developers are all doing the best possible job but the powers-that-be force them to deliver before they’re ready. Some combination of all of those things, and more, could be true. But, I’m going to give them the benefit of the doubt. I’m going to say that very, very, very, very few people get involved with beta and release candidate testing in production-comparable fashion. Actually, I’m going to say that percentage-wise, very few people get involved in beta and RC testing at all. I think that expecting a software developer to deliver a runs-everywhere-flawlessly operating system is an unreasonable expectation. It is just an axiom that early adopters get burned. If you jump to the new version too soon, you accept the risk of using a relatively untested product. Fortunately, this particular consideration will get stale pretty quickly.

Summary

Hyper-V Server 2012 R2 is a great product. It has lots of amazing features and is certainly a giant step forward for Microsoft’s hypervisor. I don’t consider any of the reasons I presented to be hard stops against its adoption. I think they’re a good reason for you to have the new version take a good tour through your test lab prior to finding its way into production.