An Avanade Blogging Community

Today's data center environments are increasingly a mixed installation base as cost savings and product installations dictate information technology teams to accept various operating systems into many hosting situations.  At the same time, many of these same enterprise organizations are looking to enterprise virtualization efforts to make organizational hosting more efficient and obtain the power savings, fault tolerance, and disaster recovery benefits which a fully integrated and monitored virtualization environment can bring to the table.

Microsoft's official stance on supported operating systems is fairly straightforward: http://support.microsoft.com/kb/954958/en-us 

Modern Windows?  Yup. 
Linux?  Only if you are running SuSE Enterprise 10 SP1 or later! 
BSD/UNIX?  Nope.

Unfortunately, that leaves integrators and IT shops in the unenviable position of potentially working Hyper-V into an environment where there are compatibility concerns because of Hyper-V's integration with the windows server stack and its relatively low cost.  Hyper-V's combination of an affordable price point combined with its status as a fully supported server product from Microsoft mean that some organizations may choose Hyper-V despite the presence of other non-Microsoft platforms in the IT shop.  In order to plan for a successful deployment, there are some key issues that should be examined before moving forward with the Hyper-V deployment.

What Operating Systems are being Virtualized?

Certainly the most important issue in considering Hyper-V for the computing environment is assessing which operating systems in the environment will need to be supported as a guest.  Build a list of which operating systems and builds are in the environment.  Ideally this should already be available in some form based on existing inventory, server lists, build lists, etc.  Having searched the net, I was not able to find a good compatibility list for Hyper-V so I have spent the last few days building an abbreviated one myself with everything that I have access to right now.  I have included it below.  I do not have AIX or similar paid versions of UNIX to test with so those operating systems were omitted.

Falconic Note: All of these listings assume no integration services are used (except where otherwise noted) and that the network adapter is replaced with the legacy network adapter and a static MAC address is assigned.  No warranty that any of these results will be achieved on your hardware, situation, etc.  This is based on testing on Windows Server 2008 RTM fully patched as of 7.14.2008, running Hyper-V RTM with latest Linux integration components (RC2) from Microsoft Connect.  All testing conducted between 7.11.08 and 7.14.08.

Note which operating systems the environment has which are not supported and/or will not work in the environment.  How many of each type of operating system are there?  What systems are they a part of?  Is this a system which could be migrated onto a constructed guest VM which uses either a distribution of that platform which will work or is supported?  In an ideal world, any solution being implemented would use only supported software configurations however whether or not this approach is enforced really depends on the risk tolerance of the environment.  If, for example, the organization's support staff are likely to rely on Microsoft support incidents during a downtime event or are not likely to have the skills to return the guest OS to service without external assistance, it would be STRONGLY preferable to remain with a purely supported configuration.

In situations where some servers are not going to be compatible with Hyper-V, there may still be value in a hybrid approach.  There are two primary approaches that you can look at in this scenario: principal virtualization with some standalone, or virtualization with multiple products.  One of the primary reasons the organization is going with Hyper-V, assumably, is the value that it provides relative to VMWare in terms of the cost/feature ratio.  You can still take advantage of Hyper-V, virtualizing compatible instances, and then using another virtualization product to support the instances which cannot run on Hyper-V.  This makes sense if the other servers to be hosted are relatively low traffic, you may already have a competing product in the environment now, and/or the customer would still like to take advantage of V2V and virtual clustering features on the servers which are not compatible with Hyper-V. 

The other option there, of course is to simply do selective virtualization and leave the non-compatible servers as a consolidated set of standalone servers.  Depending on the number of incompatible servers, you may reach a point with this approach where you are diluting the effect of the virtualization project in the first place.

What Applications are being virtualized?

In most environments, there are going to be at least a few server instances that for some reason or other cannot be virtualized.  They may be incompatible with Hyper-V, they may have precise timing needs, they run under high load and hence require dedicated hardware, etc.  If the sole reason that the server cannot be virtualized is an incompatibility with Hyper-V, you may be able to examine ways to move the application to a supported operating system.  There are two primary approaches for this for a UNIX/LINUX server:  either move the application to a similar *nix distribution which is supported (or at least is known to run reliably) on Hyper-V or move/replace the application to a windows VM.

Porting an application to a windows VM really depends on the services being provided by the application.  If it is a native console application, for example, this is much more difficult to do as there often are dependencies on the underlying operating system.  Common services like file sharing, LDAP, Mysql, Bind DNS, can all be replaced rather than ported with some export of configurations which you can then import on the replacement VM.  In the case of a web application, the compatibility with windows depends mostly on the language that the application is written in.  You can always move over a LAMP stack application to either apache running on windows or to IIS however any file or system calls will be at moderate to high risk of needing to be updated and you may also need to update the local installation of the PHP or PERL language to ensure that the necessary extensions present on the old server are available on the new server.  Note that applications which make use of passing commands to the shell for execution and return (use of grep, awk, etc) will not be compatible with running on windows.

The other option there is to migrate the application to a similar distribution of Linux.  The ideal in any given situation is that the end-state provided in the environment should be "supported" by Microsoft but for technical reasons, there are some differences in the SuSE Linux distribution as opposed to a distribution like Red Hat.  Being able to make use of the integration components and hence implement the synthetic disk and network drivers will yield significant boosts in the network and disk I/O performance of your VM.  On the other hand, your environment needs to be supported, at the very least, by the skills the technical staff have to apply to the end-state environment.  Making the determination of the correct path to make the migration should be part of a larger discussion with the environments's management.  Where are the skills in this environment?  Does the organization have a preference for specific distributions of *NIX which will run on Hyper-V?  Are development and engineering hours available for the migration? 

In any situation where you are considering migrating the application, ensure you also consider the cost versus rewards.  If you will need to invest a significant number of hours per-VM in making the given migration to another distribution of Linux or in migrating to windows, at a certain point, those costs are going to outweigh the benefit of that particular instance being virtualized. 

Some servers simply should not be virtualized.

Migrating the environment, there will be some instances which should not be virtualized, regardless of the originating operating system or platform that the server is running on.  Particular production applications which should not be virtualized include:

• Moderate to High load Database Servers
  Database servers under these kinds of loads do not virtualize well as they are always in the process of requesting resources.  The database instance should have dedicated hardware and media access in order to continue to perform at acceptable levels.
• NTP Time Sources
  NTP time sources should have dedicated time to the underlying CPU in order to maintain a highly accurate local time between upstream synchronization.
• Domain Controllers (without end-state aggressive time synchronization)
  Any time issues could result in nasty kerberos ticket validation issues if the time drift on either the end VM or the DC is too far ahead or behind of the other.
• Any server requiring use of USB hardware
  Access to USB hardware is unsupported on Hyper-V.  IF the USB hardware is a hard drive, you can connect it to the host machine and then provide it to the VM as a drive pass-through rather than a USB device.
• Any application configuration with inordinately high HA requirements
  In any given environment, when you virtualize the servers, you are placing your eggs in one basket.  If the host goes down, many of the VMs will be offline or in a state of transition until your VirtualCenter or SCVMM 2008 instance performs a V2V transition or fails over to another host in the virtual cluster.  As of this writing, Live V2V is NOT supported in SCVMM 2008 beta so high availability is still best achieved on dedicated hardware with multiple NICs and HBAs, with multiple switches and paths to the SAN and external networks.