Microsoft Hyper-V
Using this Protected Item type will incur a per-hypervisor Booster charge.
This Protected Item type backs up Microsoft Hyper-V virtual machines. Comet supports Hyper-V backups using three different modes. Latest VM state (Changed Block Tracking), Latest VM state (Standard) and All VM snapshots.
Backing up a Hyper-V virtual machine with Comet includes, but is not limited to:
- its configuration file
- all attached virtual drives
- the contents of memory (if the machine was running)
- the full tree of saved checkpoints
You can select individual virtual machines for backup, or choose "All virtual machines".
Latest VM state (Changed Block Tracking)
The Latest VM state (Changed Block Tracking) option uses WMI/RCT as its underlying technology and is compatible with all versions of Hyper-V running on Windows Server 2016 or later and Windows 10 or later.
Comet integrates with the Hyper-V WMI/RCT writer to perform a backup of Hyper-V virtual machines using WMI mode with RCT acceleration. This includes the latest snapshot data only.
Latest VM state (Standard)
The Latest VM state (Standard) option uses WMI/RCT as its underlying technology and is compatible with all versions of Hyper-V running on Windows Server 2016 or later and Windows 10 or later.
Comet integrates with the Hyper-V WMI/RCT writer to perform a backup of Hyper-V virtual machines using WMI mode. This includes the latest snapshot data only.
All VM snapshots
The All VM snapshots option uses VSS as its underlying technology and is compatible with all versions of Hyper-V running on Windows Server, including Windows Server 2022 (the latest version at the time of writing).
This backup type is only applicable when running on Windows Server. Hyper-V on Windows Desktop is not supported when using the All VM snapshots option.
Comet integrates with the Hyper-V VSS writer to perform a Hyper-V backup snapshot, including support for in-VM quiescence on supported guest operating systems. This includes all previous snapshots.
Consistency and guest additions
The following information applies to all products that perform Hyper-V backup.
When backing up a guest VM, it is important to get a consistent state of the VM. There are some different ways this happens.
If the guest OS has all necessary Hyper-V integration services installed, then the host can request for the guest VM to take a VSS snapshot. The snapshot is then exposed to Hyper-V on the host for Comet to back up. It shouldn't interrupt the guest OS. The VM backup is application-consistent. This is known as a "Production checkpoint".
If the host OS is running Server 2012 R2 or newer, but there are no integration services inside the guest OS, then Hyper-V will take a checkpoint of the VM; Comet will back up the checkpoint; and then the checkpoint will be removed. This kind of checkpoint does not interrupt the guest OS. The VM backup is crash-consistent. This is known as a "Standard checkpoint".
- You can also achieve this behavior by disabling "Production checkpoints" in the Hyper-V settings for the VM.
If the host OS is older than Server 2012 R2, and there are no integration services inside the guest OS, then the VM will be paused; Windows will take a VSS snapshot of Hyper-V's files in paused state; the VM will be resumed and Comet will back up from the VSS snapshot. It would cause a short interruption to the guest OS. The VM backup is crash-consistent.
- You can also achieve this behavior by disabling checkpoints in the Hyper-V settings for the VM.
Replica VM
The following information applies to all products that perform Hyper-V backup.
If you are using Hyper-V replication, you can back up your virtual machines from either the primary or replica host.
A backup taken on the primary VM host is application-consistent (if possible), by quiescing a VSS snapshot inside the VM guest; or crash-consistent otherwise. A backup taken on the secondary VM host is only ever crash-consistent, because the replica VM is not running in order for guest integration services to take a VSS snapshot.
Current versions of Hyper-V do not allow backing up a VM that is currently replicating. If a VM is found to be currently replicating at the time of backup, Comet will retry the operation a few times. If you repeatedly see errors of the form The virtual machine '...' cannot start a backup operation because it is currently executing a conflicting operation. Try the backup again., and you are running backups from the replica VM host, you could consider
- scheduling the backup job to run at a time when it is more likely that the VM replication is up-to-date; or
- using Before / After commands in Comet to temporarily stop VM replication while the backup job is running.
For more information about backing up a replica VM, see https://techcommunity.microsoft.com/t5/virtualization/backup-of-a-replica-vm/ba-p/382208
Pass-through disks
The following information applies to all products that perform Hyper-V backup.
Hyper-V supports passthrough disks, to attach a physical disk from the host directly into the guest VM. This unmounts it from the host OS.
Hyper-V itself does not support backing up passthrough disks (nor does it support replicating them). A Hyper-V backup of the guest machines can be taken from the host, but does not include any data from passthrough disks.
You can work around this issue by either
- installing Comet Backup inside the guest VM, and backing up the extra data at a file level (this will use an extra Device license); or
- changing your passthrough disks to be a real disk containing a large
.vhdor.vhdxfile. The "New Virtual Disk Wizard" in Hyper-V Manager has an option to convert an existing disk to a.vhdor.vhdxfile.
For more information about backing up passthrough disks in Hyper-V, see https://techcommunity.microsoft.com/t5/virtualization/working-around-the-pass-through-limitations-of-the-hyper-v-vss/ba-p/381537
Restoring data from Hyper-V Checkpoints
Granular file restore from Hyper-V requires Comet 22.12.6 or later.
If your selected virtual machine was using Hyper-V checkpoints, these are preserved by the Comet backup job as-is within the Storage Vault.
When using the "Restore as Hyper-V virtual hard disk files" option to restore data, the vhdx (base checkpoint) and avhdx (differencing disks) are both present in the restore directory. You should use the "Import Virtual Machine" wizard in the Hyper-V Manager application to import the VM fully. Once the VM is fully imported, you can select the most recent checkpoint as the active checkpoint.
When using the "Granular restore" option to restore single files from within a Hyper-V vhdx file, only the base checkpoint (vhdx file) is processed. Any data from future checkpoints (avhdx files) is not supported by the "Granular restore" option. To recover individual files from a later checkpoint, you should first restore the vhdx/avhdx files in their entirety.
Importing a running VM into an incompatible hypervisor
When using the "Import Virtual Machine" wizard in the Hyper-V manager application, you can import the running state of a virtual machine. If you are restoring a VM to a different hypervisor that has a sufficiently different CPU, the VM may fail to resume on its previous running state (vmrs / RAM snapshot) because of an incompatible CPU.
To resolve this issue, either (A) use the 'Power off' option to shut down the imported VM, instead of the 'Shut down' option; or (B) re-import the VM from its saved disk files without including the RAM running state.