I have a situation where I'm attempting to move a sparse vmdk to another datastore and convert it to a thin format in the process with Move-VM. I'm able to do this with the GUI successfully, but when I try to do it with $vm | Move-VM -Datastore $NewDS -DiskStorageFormat thin, the VM is migrated but the disk is converted to thick. $vm is the VM Object and $NewDS is the Datastore Object of a local VMFS datastore I'm moving the VM to. The location of the sparse vmdk is on a NFS Share. Also, my PowerCLI Version is 5.5R2.
I was able to get this to work in a scripted manner by using a snippet of code from LucD in this article (Move-VM to datastore cluster with DiskStorageFlag throws error.) but I just cut out the datastore cluster section.
Has anyone else seen similar problems from Move-VM? Seems to me that it may be a bug.
Then it looks indeed more and more as if you might have found a bug.
I would advise to open a SR with VMware Support, and yes, PowerCLI is supported
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Out of curiosity, does it work when you try to convert the VMDK individually ?
Like this
Get-VM -Name MyVM | Get-Harddisk | Set-Harddisk -Datastore MyDS -StorageFormat Thin
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
No, that doesn't work. I tried it where "MyDS" is the datastore where the sparse disk currently resides and with the destination datastore, both fail with the same message listed below.
Set-HardDisk : 7/22/2015 3:47:37 PM Set-HardDisk
Required property fileName is missing from data object of type VirtualDiskFlatVer2BackingInfo
while parsing serialized DataObject of type vim.vm.device.VirtualDisk.FlatVer2BackingInfo
at line 1, column 384
while parsing property "diskBackingInfo" of static type VirtualDeviceBackingInfo
while parsing serialized DataObject of type vim.vm.RelocateSpec.DiskLocator
at line 1, column 303
while parsing property "disk" of static type ArrayOfVirtualMachineRelocateSpecDiskLocator
while parsing serialized DataObject of type vim.vm.RelocateSpec
at line 1, column 297
while parsing call information for method RelocateVM_Task
at line 1, column 218
while parsing SOAP body
at line 1, column 207
while parsing SOAP envelope
at line 1, column 38
while parsing HTTP request for method relocate
on object of type vim.VirtualMachine
at line 1, column 0
At line:1 char:52
+ get-vm -Name testvm | get-harddisk | Set-HardDisk <<<< -Datastore $ds -StorageFormat thin
+ CategoryInfo : NotSpecified: (:) [Set-HardDisk], InvalidRequest
+ FullyQualifiedErrorId : Client20_ClientSideTaskImpl_ThreadProc_UnhandledException,VMware.VimAutomation.ViCore.Cmdlets.Commands.VirtualDevice.SetHardDisk
Also, I noticed some interesting things in the properties of the disk with get-vm -name testvm | get-harddisk. StorageFormat shows as Thick, DiskType is RawVirtual, and the Filename is null. Viewing the disk in the VI Client, it shows as Spares and displays the path to the disk.
There seems to be something wrong with that harddisk.
Can you a disconnect (no remove) of the VMDK, and then connect it again to the VM ?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
I disconnected and reattached the vmdk and tried the same test as earlier and got the same results.
And you only have this for that specific VM and that specific harddisk ?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Any time I try to convert a sparse disk created in the manner this one was, I get this problem.
Do you see the same issue when the svMotion/conversion is done directly through the API method ?
$vmName = 'MyVM'
$dsName = 'MyDS'
$vm = Get-VM -Name $vmName
$disk = Get-HardDisk -VM $vm
$ds = Get-Datastore -Name $dsName
$spec = New-Object -TypeName VMware.Vim.VirtualMachineRelocateSpec
$dev = New-Object VMware.Vim.VirtualMachineRelocateSpecDiskLocator
$dev.Datastore = $ds.ExtensionData.MoRef
$dev.DiskId = $disk.ExtensionData.Key
$dev.DiskBackingInfo = New-Object VMware.Vim.VirtualDiskFlatVer2BackingInfo
$dev.DiskBackingInfo.Filename = ''
$dev.DiskBackingInfo.DiskMode = ''
$dev.DiskBackingInfo.ThinProvisioned = $true
$spec.Disk += $dev
$vm.ExtensionData.RelocateVM($spec,[VMware.Vim.VirtualMachineMovePriority]::defaultPriority)
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
No, it works when I use the API. I didn't test that exact code but what I was able to make work earlier (that I got from an earlier post of your's) is very similar, posted below. I'm guessing I don't need all the additional parameters. I'll need to simplify my function to use your latest code.
$spec = New-Object VMware.Vim.VirtualMachineRelocateSpec
$spec.datastore = $DSMoRef
$vmobj.ExtensionData.Config.Hardware.Device |
where {$_ -is [VMware.Vim.VirtualDisk]} | %{
$disk = New-Object VMware.Vim.VirtualMachineRelocateSpecDiskLocator
$disk.diskId = $_.Key
$disk.datastore = $DSMoRef
$disk.diskBackingInfo = New-Object VMware.Vim.VirtualDiskFlatVer2BackingInfo
$disk.diskBackingInfo.fileName = $_.Backing.FileName
$disk.diskBackingInfo.datastore = $DSMoRef
$disk.diskBackingInfo.diskMode = "persistent"
$disk.diskBackingInfo.split = $false
$disk.diskBackingInfo.writeThrough = $false
$disk.diskBackingInfo.thinProvisioned = $true
$disk.diskBackingInfo.eagerlyScrub = $false
$disk.diskBackingInfo.uuid = $_.Backing.Uuid
$disk.diskBackingInfo.contentId = $_.Backing.ContentId
$disk.diskBackingInfo.digestEnabled = $false
$spec.disk += $disk
}
$MoveTask = $vmobj.ExtensionData.RelocateVM_Task($spec, $null)
Then it looks indeed more and more as if you might have found a bug.
I would advise to open a SR with VMware Support, and yes, PowerCLI is supported
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Opened a case and confirmed your code is a valid workaround. Thanks again!