With Microsoft Hyper-V gaining more market share and coming of age, VMware administrators must administer Hyper-V alongside vSphere in their environments. There are certainly similarities in administering the various hypervisors, including VMware and Hyper-V, but there are also subtle differences as well. Often, out of habit, we apply what we know to things that we do not know or that are new to us.
While certain methodologies or best practices extend past the boundaries of VMware vSphere and apply to Hyper-V as well, there are differences in the administration and management of Hyper-V that VMware administrators will want to note and understand. These differences also can affect backup processes in the administration.
Let’s take a look at some of the key differences between Hyper-V and VMware and how these can affect your backup methodologies.
VMware vCenter Server vs. System Center Virtual Machine Manager (SCVMM)
VMware administrators are familiar with the well-known VMware vCenter Server – a centralized management and administration tool for creating, configuring, and interacting with all aspects of the vSphere environment. From vCenter, administrators can configure and control ESXi hosts, datacenters, clusters, traditional storage, software-defined storage, traditional networking, software-defined networking, and all other aspects of the vSphere architecture. In fact, vCenter Server is a necessary component to unlock most of the enterprise-level features and functionality of VMware vSphere.
As a VMware administrator, you will typically connect your data protection solution to VMware vCenter Server as the central management pane to back up virtual machines residing on managed ESXi hosts. This provides a central login for managing and controlling the resources backed up by vSphere data protection solutions. Moreover, you can use the HTML 5-based vSphere Web Client to manage vSphere functions from any browser.
In Microsoft Hyper-V, the equivalent solution for managing hosts and clusters is the System Center Virtual Machine Manager, or SCVMM.
However, with Hyper-V, you can perform many of the “enterprise” level tasks, such as managing a Hyper-V cluster, setting up high availability, and performing live migration without using SCVMM. You can use the Failover Cluster Management console to manage your cluster resources, including setting up and configuring Clustered Shared Volumes (or CSVs). Also, without SCVMM licensing, you can use the Manager console to manage each host, etc. More info about Hyper-V Managment tools.
Understanding the management interface and the differences between VMware vSphere and Microsoft Hyper-V is key to understanding the point of administration that is used to interface with data protection solutions, like . Typically, in either the VMware vSphere or Microsoft Hyper-V environment, you want to back up resources at the “host” level, which means you are backing up virtual machines centrally rather than from within the guest operating system. Knowing the respective management interfaces ensures effective and efficient VMware vSphere and Hyper-V backup.
vSphere Cluster vs. Hyper-V Cluster
With vCenter Server in place, creating a VMware vSphere ESXi cluster is a very quick and simple process: you simply add the hosts into the cluster. VMware “clustering” is purely for virtualization purposes.
Clustering is built on top of the Windows Failover Cluster technology. Windows Failover Clustering is applied in a number of different use cases, including file servers and SQL clusters, as well as Hyper-V. Due to the more general nature of the underlying clustering technology for Hyper-V, it brings more complexity to configuring a Hyper-V virtualization cluster. However, the task can be accomplished relatively quickly if you use either PowerShell or the cluster creation wizard – Failover Cluster Manager.
There are many data protection solutions available today that are able to easily interact with vSphere vCenter and the clusters managed therein. However, there are fewer data protection solutions that are able to integrate just as seamlessly with a cluster configuration.
Understanding VMware VMFS and Hyper-V cluster shared volumes
VMware vSphere utilizes the Virtual Machine File System (VMFS) – VMware’s clustered file system that was purpose-built from the ground up as a virtualization file system. With each release of vSphere, VMFS has been tweaked, and its functionality and capabilities have been extended. With vSphere 6.5, VMware introduced VMFS 6.0, featuring support for 4K Native Devices in 512e mode and automatic “unmapping” functionality to reclaim unused blocks.
Administrators need to understand the capabilities of each type of virtualization file system. Not all data protection solutions support Microsoft Hyper-V Cluster Shared Volumes, so it is important to understand the requirements for today’s Hyper-V environments and the compatibility requirements of CSVs.
VMware uses Snapshots and Hyper-V uses checkpoints
Both have mechanisms that enable them to quickly save the state and data of a virtual machine at a given point in time. The term “snapshot” is by far the popularized word for this functionality and was coined by VMware. A snapshot operation in VMware creates the following files for the saved state and data:
.vmdk – The flat.vmdk file contains the raw data in the base disk.
-delta.vmdk – The delta disk is represented in the format of .00000x.vmdk. This is the differencing disk; it contains the difference between the current data of the virtual machine disk and the data at the time of the previous snapshot.
.vmsd – This database file contains all the pertinent snapshot information.
.vmsn – This contains the memory information of the virtual machine and its current state at the point in time of the snapshot.
It uses “checkpoints” as their terminology to define the means to save a “point in time” state of a virtual machine. Let’s look at the architecture of the checkpoint.
A Snapshots folder is created that may contain the following files:
VMCX – This is the new binary format for the configuration file introduced in Windows Server 2016. It replaces the XML file found in 2012 R2 and earlier.
VMRS – This is the state file, which contains information about the state of the virtual machine.
AVHDX – This is the differencing disk that is created. It records the delta changes made after the snapshot creation.
As a VMware administrator, you should be advised that Microsoft has introduced “production” checkpoints with Windows Server 2016. These interact with VSS (Volume Shadow Copy) to perform checkpoints that the guest operating system is aware of. These types of checkpoints function much like backup operations performed by data protection solutions.
Importantly, Microsoft allows these “production” checkpoints to be run in production environments. This is significant because before Windows Server 2016, this technology was not supported, and it is still not supported with VMware snapshots.
VMware changed block tracking vs. Hyper-V resilient change tracking
With the release of ESX 4.0 back in 2009, VMware introduced a feature called Changed Block Tracking (CBT) that dramatically increases backup efficiency. Using this technology, data protection solutions are able to copy only the blocks that have changed since the last backup iteration. This method works for every backup iteration following an initial full backup of the virtual machine. You can now efficiently back up only the changes, at the block level, instead of taking full backups of a virtual machine every time, which is what generally happens with traditional legacy backup solutions.
If you are a VMware administrator shifting to administrating Microsoft Hyper-V, you should know that Microsoft’s equivalent offering, called Resilient Change Tracking (RCT), was only introduced with Windows Server 2016.
When you back up with Hyper-V’s Resilient Change Tracking, the following files will be created:
The Resilient Change Tracking (.RCT) file – a detailed representation of changed blocks on the disk (less detailed than mapping in memory). It is written in write-back or cached mode, which means that it is used during normal virtual machine operations such as migrations, startups, shutdowns, etc.
The Modified Region Table (.MRT) file – is a less detailed file than the (.RCT) file; however, it records all the changes on the disk. In the event of an unexpected power-off, crash, or another failure, the MRT file will be used to reconstruct the changed blocks.
Make sure your chosen data protection solution can take advantage of the latest advancements in Hyper-V’s implementation of change tracking technology known as Resilient Change Tracking. This will ensure the quickest and most efficient Hyper-V backup iterations.
VMware uses VMware tools vs Hyper-V uses integration services
Both VMware and Hyper-V make use of components installed in the guest operating system to ensure more powerful integration between the hypervisor and the guest operating system. In VMware vSphere, this is handled with VMware Tools.
VMware Tools is a suite of utilities that can be installed for better virtual machine performance, including driver-supported 3D graphics and mouse and keyboard enhancements, as well as time synchronization, scripting, and other automation features. Importantly, it also enables you to perform “application-aware” backups, which ensures that database applications are backed up in a transactionally consistent state.
Concluding thoughts
In today’s world of hybrid infrastructures and multi-hypervisor environments, at some point, you will most likely be asked to act as an administrator of both VMware vSphere and Microsoft Hyper-V environments for production workloads.
Understanding the differences in management, administration, and underlying architecture is important for the successful administration of both VMware vSphere and Microsoft Hyper-V. All of these differences affect data protection solutions and their interaction with the hypervisors.
Check original article here.
Top comments (0)