Move VMs Disk to custom path on datastore

[hujiko]

Hey,

because of the migration to a new storage, I need to migrate the VMDKs of my VMs to a new storage.

For normal disks, I will just do a storage vMotion from old_storage to new_storage.

During this, on the new storage, it will create a new directory named after the VM and place the disk in there.

But I also have "special" vmdk attached to some VMs. They live in a /shared/a/b/c path of my old_storage.

When doing a normal vMotion, it would move those as well into the directory of the other VM-disks.

Is there a way to move those special disks into the same /shared/a/b/c subdirectory on my new_storage?

[Alex_Romeo]

Hi,

you can export the HDDs, copy them to the new path and mount them by hand on the VMs

ARomeo

[LucD]

Provided both are visible on the ESXi nodes, you could use the MoveVirtualDisk method directly.
There is also a CopyVirtualDisk method if you want to play it safe.

Have a look at Re: Move, Remove, or Copy an orphaned VMDK all result in a Flat file?

[hujiko]

Hey,

thanks a lot for that hint.
But I guess, exporting/copying would only work, when detaching the VMDKs from the VM or shutting the VM down.

I need to do those moves, while the VMs keep running and the VMDKs being mounted writeable to them.

The old_storage and new_storage are both visible to all ESXi hosts.

Regarding the MoveVirtualDisk​. When reading the documentation, I wasn't sure if this is possible for a running VM. Is it?

Well, apparently, the Disks I want to keep separate are no VDisks, at least a Get-VDisk -Datastore "old_datastore" does not show any

Thanks so far

[LucD]

No, MoveVirtualDisk is not a svMotion.

You can use the RelocateVM method with only 1 or more specific disks.

That would work for a powered on VM as well.
There is some sample code to be found in Re: Move only config files of a vm
In your case you would only specify the specific harddisks

[hujiko]

Hey LucD,

I had a look at the sample code you linked.

There it is about only moving individual disks, which is super cool.

But as far as I understood the code, there you also can only specify a destination datastore.

Not a custom path on the destination data store:

Get-HardDisk -VM $vm | %{

            if($_.Name -ne 'Hard disk 1'){

                $disk = New-Object VMware.Vim.VirtualMachineRelocateSpecDiskLocator

                $disk.diskId = $_.Extensiondata.Key

                $disk.datastore = $_.Extensiondata.Backing.Datastore

                $spec.disk += $disk

            }

        }

Would it be possible to also somehow inject a custom path there?

[LucD]

If you use the diskBackInfo property in there, you can use the VirtualDeviceFileBackingInfo, which has a Filename property.
I haven't used that recently, but that allows you to specify the path where the VMDK should be relocated to,

[hujiko]

Hey LucD,

sorry for the delayed answer.

I read about the diskBackInfo and the VirtualDeviceFileBackingInfo​.

But I did not found a way to specify a diskBackInfo for a svMotion.

My path looks like this:

- VirtualDeviceBackingInfo

- VirtualMachineRelocateSpecDiskLocator

- VirtualMachineRelocateSpec

But to me it looks the VirtualMachineRelocateSpec I can only specify when doing a RelocateVM, which afaik does not work while the VM is powered on.

Or do I miss something here?

Thanks a lot in advance

[LucD · Accepted solution]

I did some additional testing.

1. You can svMotion 1 harddisk to a separate datastore. The VM can be powered on during that svMotion.
2. You can not svMotion a harddisk to a special folder. It will always be in [new-datastore] VM\hd.vmdk, even when specifying [new-datastore] Special-Folder\Folder\name.vmdk
   • You can move a harddisk to a special folder on the same datastore, but there can't be a lock on the harddisk in that case. In other words, the harddisk needs to be detached from the VM or the VM needs to be powered off.

[hujiko]

Hey LucD,

thanks a lot for the additional investigation you did.

Sad to hear that this is not possible, but now we have certainty and can check if we find other ways to migrate the data.