Saturday, March 8, 2008

Hyper-V, not your mother's Windows server 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.


David said...

Great article!

If someone was to go ahead and install additional roles onto a Hyper-V node would MSFT support it if required? Or since it goes against best practice would it be at there discretion?



BrianEh said...

I am not positive of the current wording (as it changes).
I know this is considered "Best Practice" - only the Hyper-V role in production.
The key phrase is: "in production".

My take on this is described like this: If you are having problems and you call CSS, you will be highly encouraged to break the additional roles onto physical machines or into VMs before they will continue.

I see this as the same stance as Teaming of NICs. In that case you are recommened to break the team if you have network issues. If the problems go away then it was a configuration problem and not a 'bug' (eventhough it is technically a nic driver problem). It is all about who is responsible for fixing what.

However, I am not MSFT and I don't make official statements, and things change over time. (standard disclaimer)