Toward the end of the year, I recorded a short podcast with Microsoft MVP Greg Shields on Hyper-V, that mysteriously never saw the light of day. Unacceptable, right? As anyone who’s spoken with Greg knows, he’s one of the most articulate and enthusiastic people in the IT community. Below is the transcript of our conversation.
There is some basics stuff included here, but a lot of it is really insightful — especially the sections on ensuring a successful migration and specific “gotchas” to be aware of.
First things first. Why are people so excited about Hyper-V?
Greg Shields: Hyper-V has got a lot of really compelling features, and there’s been a lot of hype surrounding it over the last few months or so since Windows Server 2008 came out. It took another four to six months for Hyper-V to come out, so there’s been a lot of people waiting for it. What’s interesting about Hyper-V is that when it arrived on the scene, even as a 1.0 release, it pretty much came out in force. It’s a very, very strong first release coming out of Microsoft.
One thing I’ll tell you is that one of the reasons why Hyper-V took so long [to come out] after the release of Windows Server 2008 is that I think Microsoft recognized that in order for them to have a really good virtualization solution, it needed to be absolutely “bomb proof”. So they spent an extra four to six months testing under the release code to make sure Hyper-V was going to be at those levels. So what we’ve got now is an extremely fast virtualization platform, and some would argue it’s even faster than other technologies from places like VMware. It’s very easy to use, and even if you’re an IT generalist you’re going to be able to pick it up very quickly and easily.
It also comes at basically no cost. It’s effectively free so organizations that wouldn’t normally do virtualization are going to be able to because it doesn’t cost them anything.
How does Hyper-V compare with VMware ESX?
Shields: Well I’ll tell you this, and this is not the standard Microsoft party line because if you ask Microsoft they’ll tell you its parity with them right now. I’m not going to say it’s parity at this point, and that’s because the partner ecosystem for Hyper-V just isn’t there yet. You know ESX has a substantial partner ecosystem for backup, replication and management technology, and all that stuff that wraps around the virtualization platform to make it useful for a lot of organizations, and that’s just not there yet [with Hyper-V]. It’s coming; but it’s just not there yet.
Hyper-V also has one sort of key limitation at this point that’s going to shy some people away, and that’s live migration. It takes a little bit more time to complete a live migration [with Hyper-V]. It’s not instantaneous like ESX is. And some people are just genuinely afraid to deploy Microsoft technology when it first comes out; you know, the old “Wait until it hits service pack 1” concept.
But for organizations that have actually deployed it — and I’ve done two production deployments here in consulting engagements on Hyper-V, one actually three weeks after Hyper-V was released — they have just been patently surprised at how it works. Like with one particular engagement, this group was trying to use a different virtualization platform, I showed up at the door and within six hours we had a clustered Hyper-V instance up and running with Terminal Services virtual machines. So it’s just painless to install and painless to use.
Can you go into a little more detail about Hyper-V’s live migration capabilities?
Shields: Sure, so live migration is the idea that I have a virtual workload, a virtual machine, and it is running off of Server A. I recognize that there is something wrong with Server A or I want to move it around for load balancing purposes. In doing that, ESX has this technology called VMotion, and VMotion has been around for a long, long time. What it allows — without delay and without any loss of service – is for the processing of that virtual machine to move from Server A to Server B, and nobody will notice the difference.
Now Microsoft has a similar capability — which they call quick migration — that can do that. The only difference is that with this version of Hyper-V, the motioning part of it takes somewhere between six and 60 seconds to complete. Now you’re not going to see a reboot of the server when this happens. You’re going to see the sever go into a pause state like you’re used to seeing with virtual machines in other ways. But it goes into a pause state, moves to the other node, and un-pauses.
Now for some environments, this is not something they can have. They can’t handle having that six to 60 seconds of downtime. For a lot of environments though, especially smaller businesses and mid-market organizations, [they might ask themselves] “What is that [six to 60 seconds] compared to having things virtualized?” That’s not too bad.
So this version of Hyper-V available today has that little bit of delay that we don’t see with ESX. Now what’s interesting is the technical reasons are relatively trivial to fixing the problem with Hyper-V. In fact, Microsoft has already fixed the problem and with the version of Hyper-V that will be released with — and I think I can say this — Windows Server 2008 R2. They have actually fixed the problem, and now Hyper-V’s live migration will be effectively the same as VMotion when that releases.
So what do people absolutely need to know to ensure a successful migration?
Shields: Well a familiarity with Microsoft technology first of all! Actually, if you are considering deploying Hyper-V today, the one thing you have to recognize is that the Hyper-V role that may be available on your Windows Server 2008 instance is really not the correct version of Hyper-V. You actually need to download a number of updates to update Hyper-V to the RTM code. [Microsoft KB article] 950050 is that specific one that updates you to the RTM code, but there are a number of other patches that you need to apply to your Hyper-V instance to really get it ready to go. And that’s probably the biggest “gotcha” right now, making sure you have that right cocktail of patches in order to get that server up and running.
Here are a couple more numbers, and you might want to take some notes on this. KB 950050 is a big one. You’ll also need the Hyper-V management console on your desktop, which is KB 952627. If you’re going to use Hyper-V in a clustered environment, your going to need KB 951308.And then there’s two more that you want to install to update Hyper-V to work with System Center Virtual Machine Manager, which are KB 956589 and 956774.
So there’s a whole cocktail of patches that you’re going to need to get it ready to go. Just knowing what those are is the big limiting factor at this point.
What are some other “gotchas” to be aware of for people looking to use Hyper-V?
Shields: Probably the one these days is going to involve the backups of your virtual machines, and even ESX saw this in the early days because traditional backups are pretty easy. These days you throw a client onto your computer and it goes and sucks up all the files and the 10,000 files that make up your computer and puts it on tape somewhere. Well, the image level backup, entire server backup or single file backup that comes to mind when we think of virtualization is … well it is a relatively new technology. VMware has been doing it for a while now, but Hyper-V again is still a 1.0 release, so there are some gotchas associated with Hyper-V and backups.
Now let me frame that. I’m going to tell you what the gotchas are, but I’m also going to tell you what the benefits are, and the major benefit here is that Hyper-V integrates with VSS [volume shadow copy service]. So whereas some other virtualization platforms may not do the proper coesing of your virtual machine file so that they restore properly, Hyper-V is going to do that with no problem whatsoever. This is really really good for your domain controllers and your Exchange and SQL Server databases — those sorts of transactional databases that would otherwise have problems at restore.
So that’s the good point. With that though there are a couple of gotchas, and I’ll just sort of list some of the ones you need to be aware of. If you’re going to use Windows Server Backup, be aware that there’s a special registry key that you need to set to enable the VSS support. That’s just if you’re using Windows Server Backup. If you’re using another type of backup tool, make sure that it is VSS-aware. A lot of them are these days, but they need to be VSS-aware so they can back up the virtual machines and coess them the way they are supposed to.
Never use dynamic disks, but we just know that these days that you should just never use dynamic disks anyway. And also be careful with your snapshots so that when Hyper-V does a backup using VSS it leverages the use of snapshots, and if you have more than one snapshot or two or more snapshots in place, it will actually fail that backup.
Also be careful with the use of network attached storage. If you are directly connecting in storage via pass though or a direct connect line using iSCSI, that will not get backed up if you do an image level backup, so you may need to do that separately. And also be aware of any network attached storage at all, making sure that storage is up and running before starting the backup. [Otherwise it’s] not going to get the backup.