Hyper-V, not your mother's Windows server anymore..is it really appropriate to run Exchange in the Hyper-V parent partition?

MSFT has a very good reason for the recommendation of not installing other applications or roles into the Parent partition of a server on which you desire to run Hyper-V. Or taking another application server and converting it to a Hyper-V server.

Yes, it is technically possible to install any application into the Parent partition of your Hyper-V server, just as it is technically possible to turn any WS08 server with any applications installed into it into a Hyper-V server.

But the rub comes because adding the Hyper-V role is not the same as installing Virtual Server. It isn't just another Windows application that is installed onto a Windows server. The behavior of the operating system is modified and its overall behavior is changed.

Until Hyper-V is installed you have "just another Windows server" that you can do anything with and pile applications onto just as you have done for years. Once the Hyper-V role is added, the OS is fundamentally modified and the architecture is changed.

What was a normal install of WS08 is now transformed into more of a VM itself (we call it the Parent). And like Parents everywhere it has a role in life - to protect, care for, and sacrifice for its children (the VMs in this case).

This is best described through a graphic. In the picture below the left shows a 'standard' Windows server, the arrow represents the process of installing the Hyper-V role, and the right represents the new architecture that the server is converted into.

After this transformation your Windows Server 2008 server is now architected totally differently - it is fundamentally a VM itself. If you are familiar with other hypervisors (ESX server, XenSource, VirtualIron, Xen, etc) it is a similar model. In many of those cases you would not consider installing an email server or an LDAP service into that Parent partition - those servers are seen to have a definite and dedicated role in life.

This perception is further complicated by the interface that Hyper-V has. It is a nice, friendly Windows server GUI - just like we know and love. We can perform functions using the Hyper-V manager, but we can also work with the underlying OS, manually manipulating the network connections, disk management, etc.

Now, Hyper-V capitalizes on this by using other Windows services to its advantage.

Do you want to set up two Hyper-V servers for high availability? Set them up in a traditional Windows cluster configuration and make each VM that you want highly available the clustered "application" (it is here that I begin to talk about a VM as a workload - in this configuration the VM is no different than an application).

Do you want to set up role based permissions? Set up Authorization Manager.

These two things are not specific or unique to Hyper-V but they are used as a component of your environment / deployment.

I hope that I was at least successful in starting you thinking and asking questions regarding this new way of looking at a Windows server.

Snapshotting in Hyper-V does not equal VMware checkpointing.

The snapshotting concept under Hyper-V

For all of you familiar with ESX server and Virtual Center (or using a 3rd party product to do backups using checkpoints) you will have to think about things a little differently.

First of all.
Is using Hyper-V snapshots a good method to backup your VMs?

Answer: No. It isn't a backup method at all. It provides the ability to return to a defined point in time in the life of your VM. It is a very useful tool for testing application upgrades and service packs.

What are snapshots then (if they aren’t the same as a checkpoint)?

The best way that I have been able to describe snapshots is by using a timeline or traveling in time.
A snapshot is a moment in time that you can return to. And going right along with that - you can freely move forward in time, but moving backward in time will alter your future.

"Don't alter the timeline" - we have heard it hundreds of times (especially if you watch Star Trek Enterprise). Well, then you also hear the Vulcans state that time travel is impossible..

Snapshots in Hyper-V are all linked together, a single snapshot cannot stand alone (at least not without doing some tricks) as it is linked to its parent and so on.

The concept looks like this:

You begin with a base VHD. When a snapshot is taken an AVHD disk is created and the configuration of the VM is updated to use the AVHD as the current virtual hard disk.
(An AVHD is a snapshot specific differencing disk that is being used as the running point of a VM)

The AVHD disk is now the point where all system changes are written from this time forward - the base VHD is no longer being modified. And the AVHD is linked to (dependent upon) its parent disk. If you were to move one of these two files the VM is broken.

You can continue to spawn off additional snapshots. Each snapshot is linked to its parent in a linear (timeline) arrangement. They cannot link in a branched tree arrangement because that would create dead branches.

When you go back to a previous point in time (return to a snapshot) everything to the right of that point in time is destroyed (rendered unusable) because you altered the VM at a previous point.


Managing snapshots
Okay, what can I do with snapshots besides take them?

You can select a shapshot for a VM and “apply” it or “revert” to it.
This takes you to that moment in time and begins running the VM at that point in time. (You begin using the AVHD file that was created at that point in time).
“Revert” takes you back one step while “apply” can take you back many snapshots in one step.

Deleting a snapshot removes it from the tree.

You might wonder “if all of the snapshots are linked together how can I delete a snapshot out of the middle?”

This is because in the background Hyper-V is maintaining the integrity of your VM by combining the various states of your VM (or flattening the structure of your differencing disk timeline). If this didn’t happen your entire VM would be broken – that would be a serious bummer.

The merge process happens quietly in the background when a VM is powered off.
That is an important thing to remember – the VM must be powered off for all of the disks to be merged together.
This counts for anytime that snapshots are modified or merged into the Parent.

Delete a snapshot and its subtree.
This process deletes a snapshot and any other snapshots that are to the right of it in the timeline. The result is just that any snapshots taken to the right of the point in your timeline that you elected to perform this operation are all committed and merged into your current snapshot.

What if you want to “flatten” your tree and have everything written back to the base VHD?
Delete each of your snapshots one by one, even the current running one, and wait for the changes to be merged back into your base VHD. This can take a long time, and the VM needs to be powered down.

Deleting snapshots does not move you back in time, only applying a snapshot does that. Deleting snapshots merges your changes into another disk within the timeline.

Oh, and why don’t I have a bunch of screenshots of the GUI?
Because I figure that most Server Admins are smart enough to handle a GUI ;-)

Hyper-V terminology

For anyone that really wants to get a handle on the terminology behind Hyper-V you need to read this post by Ben Armstrong. It really goes through the MSFT terminology and how they refer to things in Hyper-V.

It also covers some basic concepts and is a good overall primer worth everyone's review, especially if you are thinking of going whole hog with Hyper-V.

The Xen of Server 2008

Server 2008 with Hyper-V... Hmm.. A hypervisor.. but it looks like Windows.

Actually, it is a totally different way to look at and think about what we already know of Windows Server and what a hypervisor is.

Until now a hypervisor was a Linux experience with a management console that brings it into the Windows realm. Ironically enough most administrators of virtual environments have turned out to be server administrators that have grown up in the Windows world.

After the Hyper-V role is added to Server 2008 the traditional way of thinking about a Windows server changes, as does what it is and how it behaves.

It is really easy to look at a server with Hyper-V and forget that it is now a hypervisor. That it has a job of running virtual machines. And for those of us that have been using VMware, that this is a totally different animal - not because it is Windows but because it is not VMware.

I am going to be expanding on these ideas as Hyper-V matures and we continue to explore it.

I have been spending a great deal of time exploring snapshots and plan on looking into backup and disaster issues.

Oh, and many have lamented that Hyper-V uses a Xen 'like' engine (this has been mentioned all over the place). The hard core open source community seems to be worried about what is happening to Xen since the Microsoft design inclusion and the acquisition of XenSource by Citrix. That discussion is strictly speculative and not one I intend on getting involved in.

What Hyper-V means to IT is that there is a new platform, one that seems strangely familiar, yet isn't. But that is well worth touching, kicking, trying, and exploring.

Is it foolproof? No, just like the other virtualization engines.

Does it require thought and planning? Yes, just like the other virtualization engines.

We can't be too comfortable with it just because it feels like Windows - "feels like" is the thing to remember.

If you think about it - the Microsoft developers have achieved something rather amazing. Marrying Windows and what we all know of as a Linux concept and presenting a truly Windows like management experience (with some unique behavior).

But, all administrators have to remember that it isn't just a Windows server anymore. It is more complex than that. And for those virtualization veterans from the VMware world and Virtual Server world..some of the things you know and have relied on - don't apply here.

That is the stuff I plan on exploring.

For now, ponder the future of a datacenter with virtualization Parents / Hosts and their Children / Guests much as a pool of resources - and we no longer care of the back-end engine - we care about the management interface, experience, and controls.