Given we had a server with a CIFS share that was fast approaching its limit (on the file server, not just the share) I built a Hyper-v machine around two iSCSI shares: one held the Windows guest, the other held the CIFS data. Now I knew the data was going to be about 4TB so created the CIFS share at that size, but because we’ve decided to use VHDX as the “visible” storage medium (rather than pass-through, purely for portability) I thought I’d start off with a 1TB VHDX file and then expand it “on the fly” to see how easy it was. I started RoboCopying all the data on the above CIFS share to the new VHDX, knowing it would start failing to copy at the 1TB mark.
And the answer was incredibly easy, if only I’d connected the 1TB VHDX to the guest’s SCSI connector first time. Basically, it’s impossible to disconnect an IDE drive while the VM is live, but no such problem with SCSI (should have realised this).
Step 1 was to use DISKPART on the guest to set disk 1 offline, then on the host ran Remove-VMHardDiskDrive -VMName xxxx -ControllerType SCSI -ControllerNumber 0 -ControllerLocation 0 (no path for Remove-… as it’s only removing a disk from the guest). Next, I used a Resize-VHD script (possibly pointlessly as it was a dynamic VHDX, but it worked…or at least didn’t fail), used Add-VMHardDiskDrive -VMName xxxx -ControllerType SCSI -ControllerNumber 0 -ControllerLocation 0 -Path X:\xxxx.vhdx. I could then use DISKPART on the guest to switch the disk back online, extend it with server manager (on another machine- the storage server is Server Core) to- again deliberately- just 3.5TB to put limits on the copy process for experimentation. As soon as the extend had finished, the RoboCopy process kicked back in. All that’s left now is for the Windows DeDuplication to sort out the copied data and we should be ready to migrate over (I’m not sure how much it can compress the data given that it’s all unique images, which would already be considerably compressed through the jpg format etc. Currently running at 2% deduplication..)