Mastering Windows Server 2016 Hyper-V

(Romina) #1

while all others are virtualized. However, even this is not really required thanks to
clustering changes with Windows Server 2012, which enables VMs to start in a cluster
even if a DC cannot be contacted, a feature known as AD-less cluster bootstrapping.)
Most of these exceptions are based on limitations of the previous generation of
hypervisors.


The reality is that with Windows Server 2012—and the ability to run very large virtual
machines with 64 vCPUs, NUMA topology projected to VM, 1TB of memory, Direct
Access to network cards using SR-IOV if needed, 64TB VHDX virtual storage, shared
VHDX, and access to both iSCSI and Fibre Channel storage where necessary—very few
workloads cannot run in a virtual machine and run the same as on bare metal,
including high-resource workloads such as SQL Server. Windows Server 2016 takes
this even further with the Discrete Device Assignment (DDA) feature; hardware such
as GPUs can be mapped directly to a VM, enabling the native hardware drivers to be
used and the full capability lit up within the VM. This had been one scenario, even
with Hyper-V 2012 R2, in which physical servers were still leveraged that required
massive GPU compute availability.


Even if you had a physical server that had only one virtual machine running because it
needed all of the resources, virtualizing is a good idea because all of the other benefits
of virtualization would still apply:


Abstraction from    the underlying  hardware,   giving  complete    portability
Ability to move the VM between physical hosts for hardware maintenance
purposes (although DDA does break this ability, since the VM is not tied to specific
hardware in a specific host)
Leveraging the high availability and replica features of Hyper-V where needed
Consistent deployment and provisioning

There may still be some applications you cannot virtualize, either because they need
more than the resource limits of a virtual machine or, more likely, because of
supportability. Some application vendors will not support their applications running
in a virtualized manner. Some have not had time to test the application, and others
may have their own virtualization solution and so will support only its product on its
hypervisor. For example, Oracle supported only its products on its own Oracle VM
hypervisor, but this changed in 2013, and Oracle now supports its products on Hyper-
V and Microsoft Azure.


Prior to this shift in support, organizations had to make a decision at this point on
how to proceed. Remember, applications don’t really know they are running on a
virtual operating system. To the application, the operating system looks exactly the
same as if it were running on bare metal, except that certain types of devices, such as
network and storage devices, will be different because they are virtual devices, so
virtualizing an application should not introduce problems with today’s hypervisors.


Carrying on with the Oracle example, in my experience, even before the supportability

Free download pdf