Hyper-V 2012 R2 merge perminently alters path to VHDX.

[possumdelight]

I am currently having a problem where under the following conditions:

Windows Server 2012 R2 Hyper-V
The Hyper-V server has a volume mount-point: C:\Data Files\Hyper-V = Secondary Drive V:\
The path to the VM's VHDX: C:\Data Files\Hyper-V\Virtual Hard Disks\Machine.vhdx

When a checkpoint is created and then deleted/merged, Hyper-V permanently alters the path to the VHDX file from "C:\Data Files\Hyper-V\Virtual Hard Disks\Machine.vhdx" to "V:\Virtual Hard Disks\Machine.vhdx"... but only if the checkpoint is taken and deleted with the VM OFFLINE. If the VM is running at the time, this does not happen.

I can go in and fix it; but it just does it again next time. This behavior seems consistent across all my virtual machines.

Using the V:\ path is causing other problems with 3rd party software.

Anyone have any thoughts or ideas on how to prevent this from happening?

Thanks all

Charlie

[Deon]

What is the "checkpoint location" (I don't remember the exact name of that parameter) path for the virtual machine in its settings? Could there by by chance a V:\ disk specified there for checkpoint redirection?

[possumdelight]

Checkpoint location is "C:\Data Files\Hyper-V" No references to V:\

Some additional info: If I test removing the drive's letter V:\ and only mount the volume to C:\Data Files\Hyper-V, it works.

When the checkpoint is created, it changes the VHDX's path for the VM to the checkpoint file; upon deleting the checkpoint, the checkpoint file is merged with the original VHDX and then removed. At that point, its like the system queries where the original VHDX is located and enters that path back in to the VM. For whatever reason, it chooses V:\Virtual Hard Disks\ instead of its original c:\Data Files\Hyper-V\Virtual Hard Disks\

Very strange.

[foggy]

Charles, this looks like a Hyper-V issue, we were able to reproduce this internally (even on Windows Server 2012, without R2). So I recommend to remove mount point to prevent this behavior.

[possumdelight]

Thanks foggy; I'm somewhat surprised this hasn't been a noticeable enough bug for MS to attend to. I would like to keep the V:\ mount point so for the meantime, I had the idea of running a PowerShell script to correct the problem pre and post backups.

Code: Select all

$VMs = Get-VM
ForEach ($VM in $VMs) {
  
  $VHDX = Get-VM –Name $VM.Name | Get-VMHardDiskDrive –ControllerType IDE –ControllerNumber 0 –ControllerLocation 0 

  $IncorrectPath ="V:\Virtual Hard Disks\$($VM.Name).vhdx"
  if($VHDX.path -eq $IncorrectPath)
  {
    write-host "Restoring correct path to $($VM.Name).vhdx"
    REMOVE-VMHardDiskDrive -VMName $VM.Name –ControllerType IDE –ControllerNumber 0 -ControllerLocation 0

    $CorrectPath = "C:\Data Files\Hyper-V\Virtual Hard Disks\$($VM.Name).vhdx"
    ADD-VMHardDiskDrive -VMName $VM.Name -Path $CorrectPath
  }

}
write-host "Succesfully repaired all virtual machines."

[foggy]

Nice workaround. Thanks for sharing!