Mastering Windows Server 2016 Hyper-V

(Romina) #1

Storage Fundamentals and VHDX


Chapter 2, “Virtual Machine Resource Fundamentals,” covered the basics of virtual
storage, and this section quickly reviews those basics and the various limits and
options provided. Nearly every virtual machine scenario requires some kind of “local”
storage, such as that used to host the boot and system partitions that contain the
operating system environment and locally installed applications and services.
Additional storage may also be assigned to the virtual machine for data storage,
although this could be accessed using other network-based methods.


Storage that is assigned to the virtual machine from the host server must first be
accessible to the Hyper-V host. (Exceptions exist, but these are covered later in the
book.) Examples include direct-attached storage to the host, or storage with which the
host can communicate—such as on a SAN via iSCSI or Fibre Channel connectivity or
even on a Windows file server or network-attached storage (NAS) device using SMB 3
with Windows Server 2012 and above, which introduced file-level access support.


It is important that any storage used by the host to store virtual machines is resilient
to failure. For direct-attached storage, use technologies to enable a disk to fail without
losing data (such as RAID or Storage Spaces Direct when direct-attached is leveraged
across cluster nodes). For remote storage, ensure that there are multiple paths to the
storage, to avoid losing storage access if a single card, cable, or switch fails. The
remote storage should also be fault-tolerant. When Hyper-V hosts are clustered
together, as they always should be to ensure availability of the virtual environment,
it’s important that storage used by virtual machines is available to all hosts in the
cluster.


With storage available at the host level, it needs to be assigned to virtual machines.
Although it is possible to pass a disk directly from the Hyper-V host into a virtual
machine known as a pass-through disk, this is not something that should ever be
done, for the following reasons:


The disk    is  usable  solely  by  the virtual machine assigned    the physical    disk    from    the
host, so that not even the host can still use the disk.
Virtual machine checkpoints that provide point-in-time captures of a virtual
machine don’t work.
Migration technologies such as Live Migration do not work without an outage to
availability.
Replication technologies such as Hyper-V Replica do not work.
Virtual machine backup at the host is not possible.
Storage quality of service is not available.

With all of these problems, you may wonder why pass-through storage was even made

Free download pdf