update, the Oracle products worked just fine on Hyper-V, and Oracle support would
even try to assist if there was a problem with it running on a non-Oracle hypervisor on
a best-effort basis. However, organizations have to be prepared, because if a problem
cannot be fixed, the application vendor may ask for the problem to be reproduced on a
supported configuration, such as on a bare-metal system without virtualization or on a
supported hypervisor. Technology can help here. There are third-party solutions that
normally help with physical-to-virtual conversions when organizations want to move
to a virtual environment and can also take a virtual machine and deploy to bare metal.
This could be an emergency backup option for organizations that want to standardize
on one hypervisor and run all applications on virtual operating systems, even when
not officially supported.
The decision comes down to an organization’s appetite for some risk, however small,
and how critical the application is should it run into a problem. If you have a
noncritical application, then virtualizing in a nonsupported configuration that has
been well tested by the organization is probably OK. If it’s a critical system that would
need instant support by the vendor if there was a problem, then running in an
officially unsupported configuration is probably not the best option.
In the past, there were concerns about virtualizing domain controllers. That is not the
case with Windows Server 2012 and Windows Server 2012 Hyper-V, which have
special capabilities directly related to Active Directory, VM-GenerationID, as covered
in Chapter 6 , “Maintaining a Hyper-V Environment.” Most companies I work with
today virtualize domain controllers, and in Windows Server 2012 Failover Clustering,
there is even protection from the cluster not being able to start if a domain controller
was not available, which was a previous concern. Essentially, prior to Windows Server
2012 , if all the domain controllers were running on a cluster, there was a problem if
you shut down the cluster. Normally, virtual machines cannot start until the cluster
service starts. The cluster service could not start without contacting a domain
controller. Therefore, if the domain controller was a virtual machine, nothing could
start. Windows Server 2012 Failover Clustering removed this dependency.
I’ve focused on Windows workloads and how Windows can be virtualized, but many
organizations have some non-Windows servers as well. Hyper-V has great support for
Linux distributions. Even Linux distributions that are not officially supported will
likely still work and can use the Hyper-V integration services to give you a great
experience. This applies equally to Microsoft Azure, which has a wide range of Linux
support. Just because a workload is not a Windows Server workload does not mean it
cannot be virtualized. Some Linux/Unix workloads cannot be virtualized on any x 86
hypervisor, because they are using a non-x 86 architecture. A good example is Solaris
running on SPARC. This cannot be virtualized on an x 86 hypervisor because SPARC is
a different hardware architecture. If you are using the x 86 version of Solaris, it would
probably run on Hyper-V. However, at the time of this writing, it’s not a supported
Linux distribution for Hyper-V, and if you are running this Solaris workload, it’s
probably pretty important, so running in a nonsupported manner may not make sense
for you.