Adding existing hard disk via New-HardDisk gives "Incompatible device backing specified for device '1'"

[Guy Leech]

I've taken an existing vmdk file,from a snapshot, modified its contents as I'm renaming the disk file and changing the parent disk to create a linked clone, but when I call New-HardDisk with -DiskPath set to something like "[SSD] Scripted Clone/Scripted Clone.disk1.vmdk" , where that file exists in that folder in the datastore, and -VM set to a new VM the PowerShell script has just successfully created, the cmdlet fails with the error "Incompatible device backing specified for device '1'". The disk file exists and seems to be fine because if I add it from the web console then it adds just fine and the VM boots ok so presumably I'm either missing some parameters to New-HardDisk or there's potentially a bug.

[LucD]

Is the Controller in that new VM of the same type as the one from where you copied that VMDK file?

[Guy Leech]

It will be. At the point I create it, there aren't any SCSI controllers in the new VM so I pipe the created hard disk object into New-ScsiController, if it isn't null. When the disk I've created isn't a differencing disk, it's although still renamed as are the extents for the flat file, it works just fine.

The same happens in another VM which had a renamed differencing disk attached via the console after I remove it via the console and then try and re-add it via New-Harddisk. This VM has a SCSI controller when I try and re-add the removed disk so I don't think it is controller related. All the controllers involved are LSI SAS ones.

[LucD]

I'm a bit confused by your terminology I'm afraid (and it;s probably me).

I only know the term "differencing disk" from VHD disks (Virtual Server).

Do you mean the delta disk from a VM's snapshot?

Perhaps a screenshot would help to show what your trying to do?

[Guy Leech]

Sorry, yes delta disk. For instance, I have the following in a vmdk file:

# Disk DescriptorFile

version=1

encoding="UTF-8"

CID=5d55d2f9

parentCID=63bb325c

createType="seSparse"

parentFileNameHint="../Server 2016 Sysprepd/Server 2016 Sysprepd.vmdk"

# Extent description

RW 83886080 SESPARSE "Manual-sesparse.vmdk"

# The Disk Data Base

#DDB

ddb.grain = "8"

ddb.longContentID = "88265253c9729dba4ea0744f5d55d2f9"

Which gives the error if I add it via New-HardDisk but works fine if I add it via the web console. All of the referenced disks exist, otherwise it would either fail to add via the console and/or wouldn't boot presumably. I've tried it with an absolute path for parentFileNameHint but that makes no difference. parentCID is correct but again if it was wrong surely it wouldn't work outside of PowerCLI?

[LucD]

Is that a delta disk from a snapshot?

Or a regular full disk from a VM?

How did that disk look in the original VM? Meaning what does it show when you do a Get-Harddisk | Select *

What did you actually change for that vmdk? Only the name?

I'm trying to replay what you are doing, but it's unclear to me where your vmdk comes from, and what you did with it.

[Guy Leech]

It's a delta disk from a snapshot. In the original VM, this is what Get-Harddisk returns where there is currently only one snapshot:

StorageFormat   : Thin

Persistence     : Persistent

DiskType        : Flat

Filename        : [BOOT] Server 2016 Sysprepd/Server 2016 Sysprepd-000001.vmdk

CapacityKB      : 41943040

CapacityGB      : 40

ParentId        : VirtualMachine-64

Parent          : Server 2016 Sysprepd

Uid             : /VIServer=[e-mail]:443/VirtualMachine=VirtualMachine-64/HardDisk=2000/

ConnectionState :

ExtensionData   : VMware.Vim.VirtualDisk

Id              : VirtualMachine-64/2000

Name            : Hard disk 1

It's thin provisioned. So I copied this vmdk, and the associated sesparse.vmdk binary file, to the folder for the new VM my script has created, renamed the files and then changed the parentFileNameHint line to point back to the base disk for this delta disk and changed the extents to the renamed file as per my earlier post.

It's at that point when I call New-HardDisk on my copied, renamed and edited vmdk file that I get the error but if I add the same disk to the same VM via the web console then it works fine.

I've looked at the hostd.log file trying to spot the difference from when it works via the web console to when it fails via PowerCLI but I can't see anything obvious.

Thanks for your continued help on this.

[LucD]

Ok, I was able to recreate the issue you are seeing.

I suggest you open a SR for this issue.

I'm using PowerCLI 11.0.0

The only way around it is to call the API method directly.

Something like this

$vmName = '<your-vm-displayname>'

$vmdkName = '[<dsname>] Folder/<vmdk-name>.vmdk'

$vm = Get-VM -Name $vmName

$ctrl = Get-ScsiController -VM $vm

$dsName = $vmdkName.Split(']')[0].TrimStart('[')

$ds = Get-Datastore -Name $dsName

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec

$spec.deviceChange = @()

$spec.deviceChange += New-Object VMware.Vim.VirtualDeviceConfigSpec

$spec.deviceChange[0].device = New-Object VMware.Vim.VirtualDisk

$spec.deviceChange[0].device.backing = New-Object VMware.Vim.VirtualDiskFlatVer2BackingInfo

$spec.deviceChange[0].device.backing.datastore = $ds.ExtensionData.MoRef

$spec.deviceChange[0].device.backing.fileName = $vmdkName

$spec.deviceChange[0].device.backing.diskMode = "independent_persistent"

$spec.deviceChange[0].device.unitnumber = -1

$spec.deviceChange[0].device.controllerKey = $ctrl.ExtensionData.Key

$spec.deviceChange[0].operation = "add"

$vm.ExtensionData.ReconfigVM($spec)

[Guy Leech]

Many thanks for reproducing and confirming it's a bug. Unfortunately as I'm just a home user, I don't have  a support contract to raise an SR.

Your workaround code is great except I don't have a SCSI controller in my VM as I remove the hard drive that New-VM creates and that removes the SCSI controller too. Given that New-SCSIController seems to need a disk, I ended up using your same API method to create all of the same SCSI controllers as in my "template" VM before I then create the hard disks using your workaround.

Thanks again for your help.