Q: I'm trying to back up my virtual machine from the host onR2, but I'm receiving an error message because the machine doesn't have a SCSI controller. Why is this error occurring?
A: The process to back up a virtual machine from the Hyper-V host changed in a major way between Windows Server 2012 and Windows Server 2012 R2. Backups taken at the Hyper-V host still call the Volume Shadow Copy Service (VSS) writers within the virtual machine through the backup integration service, which ensures application-consistent backups even when the backup is taken at the Hyper-V host. In Windows Server 2012 there's a time delta between the time the VSS snapshot is taken within the virtual machine and the time the VSS snapshot is taken at the Hyper-V host (because it takes time to pass back the various VSS communications between the guest and the host), which means data could change in that time delta, therefore introducing the risk of data corruption.
To solve this problem, the actual snapshot taken of the VHD at the host is mounted as a volume on the Hyper-V host as part of the backup process to enable the snapshot VHD to be rolled back to the state of the snapshot taken inside the virtual machine (the guest VSS snapshot) and then that state backed up at the host. This approach creates scalability concerns because large numbers of VHDs might need to be mounted; in addition, VHDs from virtual machines are being mounted on the Hyper-V host, which could be a security concern.
Windows Server 2012 R2 solves this problem; Hyper-V actually pretends that Hyper-V has hardware-based snapshot support (which is typically part of high-end SANs). Therefore, when a VSS snapshot request is made inside the virtual machine, the Hyper-V VSS writer is piped directly in the host, which triggers creation of a checkpoint (which in turn creates an AVHD differencing file on the host). Then that checkpoint is used by the actual VSS running on the Hyper-V host, which removes the need for VHDs to be mounted in the host. However, as part of this process an AutoRecovery VHDX has to be mounted to the virtual machine to expose the snapshot back to the virtual machine as part of the fixup phase near the end the backup process, and then the AutoRecovery VHDX is removed. This is invisible to the end user; however, this hot-add of a VHD is possible only on the SCSI controller, which is why the virtual machine must have a SCSI controller present.
If a virtual machine doesn't have a SCSI controller, you'll receive an Event ID 10103 in the log Microsoft-Windows-Hyper-V-VMMS-Admin to notify you that the virtual machine cannot be backed up live:
Note that when this does work, if you look very carefully you'll see some events generated inside the guest OS indicating that a disk was added with the same signature as an existing disk (because the checkpoint is essentially the same disk) and then that a disk was surprise removed. These events are normal and can be ignored.