Hyper-V has many components that are responsible for providing an end-to-end management solution for VMs and the Management OS. The following diagram shows the most important components of Hyper-V that will be explained in the succeeding sections:
The small Hyper-V Hypervisor (almost 20 MB) is responsible for managing, separating, and controlling the partition access. Also, it is in charge of isolating all the partitions from each other with high security and reliability.
When Hyper-V is present, the host OS and the VMs run and share the same access and privilege with Hypervisor and both are known as partitions. However, the host OS runs a series of components to manage the VMs and for that reason, the host partition is called parent partition or management OS and VMs are called child partitions or guests OS.
The VM creation and management is made by a series of virtual devices and software components called virtualization stack, which is executed in the parent partition. These series of components work in conjunction with the Hypervisor.
Virtualization Service Provider (VSP) is a software component that controls I/O requests on behalf of the VMs in the parent partition. Virtual Machine Bus (VMBus) is responsible for data transfer, service, and device delivery between Parent and child partitions through a dedicated channel available between the VSPs and Virtualization Service Clients (VSCs). VSP uses VMBus to communicate with child partitions using VSCs to provide the synthetic drivers that run in the child partitions.
For every VM that is started, a worker process is created in the parent partition. Worker process and Virtual Machine Management Service (VMMS) are user-mode components that provide the ability for parent partition to create, start, stop, save, and delete VMs. All these tasks are coordinated by the Virtual Infrastructure Driver (VID), which manages the communication between parent and child partitions.
The access between partitions and the Hypervisor is done by a special interface called Hypercalls. They guarantee that the VMs can access the hardware using components, such as VID, VMBus, VSCs, and VSPs. These mechanisms are present during the Integration Components (ICs) installation. Some Windows and Linux operating systems have integration components packages already installed in their Kernel. VMs that have these components are called Enlightened VMs. For old or non-supported OS's, the parent partition intercepts the VM communication, emulating the Hypercalls. The result is poor performance and limitations to access the hardware, since the management OS needs to work as a bridge to allow the VM to access the hardware. That's why it is very important to ensure that all the VMs are running with the latest IC version.
In Windows Server 2016 Hyper-V, Microsoft made pretty significant changes to the backup architecture. They gave Hyper-V the support so that anyone, including backup partners, could query Hyper-V WMI and request for Volume Shadow Copy Service (VSS) snapshot of any VM and then it will go through and do the whole backup process independently.
In Windows Server 2016 Hyper-V, the backup architecture looks similar to the following diagram:
As you can see in the diagram, we have the Hyper-V host at the bottom; the backup application will first call Hyper-V WMI to get all VMs that they want in any backup Set ready for backup and then the backup application will call VSS and Virtual Disk Service (VDS) to orchestrate a single hardware snapshot on the storage backend. The goal here is to get to a model where no matter how many VMs you have, and no matter what scale point you are running, it won't impact your system.
If we compare the backup workflow in previous Hyper-V releases, there were two snapshots happening:
The first one is the VMs snapshot and the second one is the underlying hardware snapshot and those two operations are very tight together, so you cannot do one without doing the other. However, in Windows Server 2016 Hyper-V, the backup application takes the same amount of time that is required to get the Set of VMs with data consistency, and then do the hardware snapshot as a separate operation, which is the key architectural change in Windows Server 2016.
The second improvement that Microsoft worked on is a new technology called Resilient Change Tracking (RCT) and Modified Region Table (MRT).
There are two goal of RCT and MRT. The first one is backup improvement of all the previous Hyper-V architectures, the result was a full backup of the virtual hard drives of the VMs, what this means is that every time you do backup (daily, hourly or whatever), the data is sent over the network each and every time and that architecture wouldn't scale enough. So in order to avoid sending all the data over the network, every backup vendor, at that time, implemented a file-system filter to track the change blocks on the storage, but having a third-party file system filter in the kernel host OS is a potential system-crashing bug and the second issue will affect the storage performance profiling. In Windows Server 2016, Microsoft built a system where you don't have to put any file system filter anymore, this was the first improvement. The second improvement though was in the new architecture, the backup application request to snapshot the VMs independently and then take a hardware snapshot as a separate operation because in all the previous architectures, there is an extended period of time where the VMs will be running on .avhdx files or differencing disks and Microsoft wants to mitigate the performance impact of doing that.
In Windows Server 2016, Microsoft is providing native change block tracking as a part of the platform. With RCT and MRT, they can get the block-allocation table, which exists in every virtual hard disk (.VHDX) file and also keep a track of the blocks that have been changed; however, they don't write the data because the backup application has a copy of the original data somewhere else, thus it prevents copying the data twice. The great thing about RCT and MRT infrastructure is that they are tight to the VHDX file; so, wherever the file exists, they will stay with it, which is flexible when it comes to VM mobility scenarios and resilient to VHDX file corruption.
The MRT file is written in the write-through mode and uses a coarser tracking granularity; whereas the RCT file has a finer granularity and uses normal writes. The write-through mode ensures that even in the case of sudden power loss, the MRT file still has a good record of what has changed on the disk. The RCT file has the finer granularity (16 K) to better meet scenario needs during normal operation. These files were split to improve total storage performance. The RCT file will not grow beyond 6 MB and the MRT file will not grow beyond 76 KB.
The following screenshot shows the change block tracking in Windows Server 2016 Hyper-V during the backup operation:
There are two important points to be aware of, use VHDX if you are planning to run VMs with VHD on Windows Server 2016, instead of VHDX, because if your VM is version 5.0, then you will not get any benefit of RCT support. Using a VM with version 5.0 configuration might be taken to a host running Windows Server 2012 R2 and 2012 R2 does not support RCT; so if you are in either of those situations, you will hit a performance impact during the backup process because Microsoft will not use RCT in this case, and will use differencing disk instead (same as Windows Server 2012 R2). Microsoft also supports backup for guest clusters in Windows Server 2016 using the RCT infrastructure, guest clusters are groups of VMs with shared virtual hard disks. However, in order to do that Microsoft introduced a new file format called VHDS (VHD Set), the VHDS is a very small file that has a bunch of .avhdx files along with it.
With the introduction of VHD Set file, Microsoft can take advantage of the storage snapshot and then update the VM configurations in order to reference the right configuration. The VHDS file is a reference-pointer file and includes checkpoint metadata. No user data is stored in the VHDS file. You can think of the VHDS as an external shared configuration file between VMs (guest clusters), because in Windows Server 2012 R2, if you have two VMs using a shared VHDX file, then each VM has its own configuration file which make a real problem about metadata update and re-synchronize all the changes. However, in Windows Server 2016, if you have two guest-cluster VMs and each has its own configuration depending on shared VHDS file, which is essentially a configuration file that allows us to have one place to update when there is a change to the underlying storage. The VHD Set file enables solving the problems associated with coordinated updates to all the VM's configurations by centralizing the VHD file paths in the single VHD Set file. The VHD Set file also provides a friendly file name to be used in the GUI or in PowerShell. The VHD Set file can be used similar to any other VHD file; it can be queried, migrated, and mounted. The primary reason for VHD Set file (VHDS) is to have support for backup on guest clusters.