February 7, 2018
Hyper-V Backup Guide for VMware Administrators
With Microsoft Hyper-V gaining more market share and coming of age, VMware administrators are finding themselves having to 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 (if not more major) 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 make note of and understand. These differences also can affect backup processes in the administration of Hyper-V vs. VMware.
#1 all-in-one solution for VMware and Hyper-V backup – Download and try for free!
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.
Typically, as a VMware administrator, you will 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 management and control of the resources that get 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 Hyper-V 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. To manage your Hyper-V cluster resources, including setting up and configuring Clustered Shared Volumes (or CSVs), you can use the Failover Cluster Management console. Also, without SCVMM licensing, you can use the Hyper-V Manager console to manage each Hyper-V host, etc.
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. 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 backups and Hyper-V backups.
vSphere Cluster vs. Hyper-V Cluster
When thinking of high availability in dense virtualization environments, clustering provides the means to achieve high availability of virtual machines. By clustering multiple hosts together, the virtualization environment can withstand a single- or even multiple-host failure and still be able to run virtual machines. It also allows balancing virtual machine workloads between multiple hosts and provides an easy way to “scale out” resources. The processes of creating, managing, and interacting with vSphere and Hyper-V clusters differ.
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.
With Hyper-V, 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 a bit more complexity to configuring a Hyper-V virtualization cluster. However, the task can be accomplished in a relatively short amount of time 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 Hyper-V cluster configuration.
Understand VMware VMFS and Hyper-V Cluster Shared Volumes
A crucial area of consideration for any cluster that supports virtual machines is the file system. With cluster-based virtualization, it needs to be possible for any hosts in the cluster to access files within the shared storage, simultaneously. Thus, all hosts in the cluster are able to mount, read, and write to shared storage, and multiple hosts can be accessing and performing operations on the same storage device.
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.
Prior to Windows Server 2008 R2, Hyper-V utilized NTFS (Microsoft’s proprietary file system) as its file system for virtual machine storage. NTFS was never written with simultaneous access in mind, and therefore limited earlier versions of Hyper-V from allowing multiple hosts access to the same LUN (logical unit number) at once. When virtual machines were failed over, all the virtual machines on the same LUN had to fail over together. This was due to the single host access limitation inherent in the NTFS file system. In a traditional Windows Failover Cluster, a change in ownership of a drive required a dismount and remount of the storage between the nodes as ownership changed.
Microsoft has since removed this limitation in Windows Server 2008 R2 and all subsequent versions with Hyper-V by creating Cluster Shared Volumes, or CSVs. With CSVs, multiple Hyper-V hosts can have simultaneous access to a storage volume containing multiple virtual machines. Clustered Shared Volumes have evolved in the latest versions of Windows to include support not only for Hyper-V, but also for other use cases, such as Microsoft SQL Server.
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; Hyper-V Uses Checkpoints
VMware and Hyper-V 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.
Hyper-V 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 Hyper-V 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 working with Hyper-V, 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 prior to Windows Server 2016, this technology was not supported, and it is still not supported with VMware snapshots.
It is extremely important for VMware administrators and Hyper-V administrators alike to recognize that snapshots or checkpoints are not backups. Even with the “production” checkpoints Hyper-V offers, complete backup of business-critical data is not ensured. They are simply checkpoints that are supported for production purposes, and they rely on the underlying virtual disk infrastructure to operate properly.
With Hyper-V, it is also important to recognize the difference between saved state and child VM snapshots. Saved state snapshots are “all else fails” snapshots. They are sometimes referred to as “offline backups”, as they require at least a brief period of virtual machine downtime. The Hyper-V virtual machine is quickly hibernated, VSS snapshots are taken, and the virtual machine is returned back to the previous state, as it was before the snapshot was taken. In the “saved state” snapshot, connectivity will briefly be interrupted. Also, as it is not an “application-aware” snapshot, it will not be transactionally consistent.
By contrast, a child VM snapshot is sometimes referred to as an “online backup”, because connectivity to the virtual machine is maintained throughout. The requirements for making sure a “child VM” snapshot works are much more stringent than for a “saved state” snapshot. The following must be true in order to take the snapshot:
- The Hyper-V virtual machine must be powered on;
- Hyper-V’s Integration Services must be installed and running;
- Snapshot files must be in the same location as the VHD(X) disks;
- No dynamic disks are supported in the guest operating system (static disks only);
- The guest OS file system must be formatted using NTFS (FAT32 is not supported).
Making sure your chosen data protection solution interacts with both VMware and Hyper-V and understanding the differences between the two can minimize the issues you encounter when making VMware or Hyper-V backups and ensure that the most efficient means for capturing backup data are utilized.
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 happened with traditional legacy backup solutions. To learn about other 21 differences between legacy backup solutions and modern native backup solutions, download our White Paper.
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. If you are administering a legacy Hyper-V environment (prior to Windows Server 2016), your data protection solution should have a proprietary change tracking technology to allow you to perform incremental backup.
With the release of Windows Server 2016, this feature is now natively found inside Hyper-V, allowing more powerful and efficient tracking of changes on Hyper-V virtual machines, which allows incremental backups to be carried out faster.
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 to in write-back or cached mode, which means that it is used during normal virtual machine operations such as migrations, startups and shutdowns, etc.
- The Modified Region Table (.MRT) file – a less detailed file than the .RCT file, however it records all the changes on the disk. In the event of an unexpected poweroff, crash, or other 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. As RCT was only recently introduced with Windows Server 2016, many data protection solutions have yet to officially support its use.
VMware Uses VMware Tools; 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.
Similarly, Hyper-V’s Integration Services allow this same type of hypervisor – guest operating system interaction, including time synchronization, data exchange, heartbeat, backup, and other guest services. It is also essential for Hyper-V Integration Services to be running to enable the “child VM snapshot” method, which allows application-aware backups to take place, as mentioned above. Data protection solutions will require Integration Services functionality for effective and efficient backups of Hyper-V virtual machines in transactionally consistent states.
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 successful administration of both VMware vSphere and Microsoft Hyper-V. All of these differences affect data protection solutions and their interaction with the hypervisors. Taking them into consideration when configuring and performing VMware vSphere and Microsoft Hyper-V backups ensures that your backup data is valid and restorable.
It’s also important to utilize a data protection solution that already understands the key differences in architecture between the two platforms, and can interact with the latest technologies instituted by both vendors. NAKIVO Backup & Replication is a powerful backup solution that is equally adept at protecting VMware vSphere and Microsoft Hyper-V environments. It utilizes the latest technologies of each hypervisor and allows you to have a “single pane of glass” view of both VMware vSphere and Microsoft Hyper-V data protection processes in your environment. This saves you time and money by empowering you to effectively and efficiently protect both environments with a single product.