RDM Disks -> Existing Disk - Using New-HardDisk Errors

[CODETL19]

I am writing a powershell/powercli script to automate adding RDM disks to two VM's in a two node Windows Failover Cluster for SQL.
The RDM disks are presented from a physical storage unit and using their naa.id's I can successfully add them to my first VM without issue using the New-HardDisk module like shown below (thanks lucd for earlier help):

$DataStore = "DataStore_Name_RDM"
$VM1 = Get-VM -Name "VM1"
$VM2 = Get-VM -Name "VM2"

New-HardDisk -VM $VM1 -DeviceName "/vmfs/devices/disks/$($Disk)" -Datastore $DataStore -DiskType RawPhysical | New-ScsiController -Type ParaVirtual -BusSharingMode Physical

But when it comes to adding the disk to the 2nd VM (like you would in the GUI by hitting 'existing disk' and finding the .vmdk in the datastore), I am prompted with this error:

"New-HardDisk The specified disk path is not accessible or does not exist: '[DataStore_Name_RDM] VM1/VM1.vmdk"

Here is the code I am using to map the existing disk:

$DiskPath = (Get-VM -Name $Server1 | Get-HardDisk | Select-Object -Property Filename | Where-Object {$_.Filename -Match "_RDM"})[1]

New-HardDisk -VM $VM2 -DiskPath $DiskPath.FilePath | New-ScsiController -Type ParaVirtual -BusSharingMode Physical

I can add the disk no problem via the GUI, using the 'Existing Disk' option, so the disk is accessible and does exist.

The datastore is presented to all hosts in the cluster these VM's sit on.

Any idea what might be causing this error, or any tips on how to troubleshoot it further?.

Please also let me know what other information I can provide here to help troubleshoot.

PowerCLI Version
----------------
VMware.PowerCLI 13.1.0 build 21624340
---------------
Component Versions
---------------
VMware Common PowerCLI Component 13.0 build 20797081
VMware Cis Core PowerCLI Component PowerCLI Component 13.0 build 20797636
VMware VimAutomation VICore Commands PowerCLI Component PowerCLI Component 13.0 build 20797821

[LucD]

The Select-Object cmdlet doesn't return a single String, but an object.
The DiskPath expects a String.

Try with

$DiskPath = ((Get-VM -Name $Server1 | Get-HardDisk | Where-Object {$_.Filename -Match "_RDM"}).FileName)[1]

Note: assuming that the 2nd returned String , with [1], is the correct HD might be risky.
Better is to match part of the value in the FileName

[CODETL19]

Thanks for the reply.

I tried it with:

$DiskPath = ((Get-VM -Name $Server1 | Get-HardDisk | Where-Object {$_.Filename -Match "_RDM"}).FileName)[1]

No luck, same error still unfortunately.

For now using [1] is ok but in my full code for the automation I have an index that increments with every loop.

[LucD]

Did you check what you have in $DiskPath and the type?

[CODETL19]

Yes I did, sorry I should have put the results.

Type

IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True String System.Object

And the output was as expected.

[LucD]

And how did you do the New-HardDisk?
Because that should now be

New-HardDisk -VM $VM2 -DiskPath $DiskPath | New-ScsiController -Type ParaVirtual -BusSharingMode Physical

 No FilePath property

[CODETL19]

Yep the New-HardDisk command was exactly as you pasted, without the .FileName extension:

New-HardDisk -VM $VM2 -DiskPath $DiskPath | New-ScsiController -Type ParaVirtual -BusSharingMode Physical

[LucD]

Then I'm out of ideas I'm afraid.

[CODETL19]

Sad times :(.

I will keep looking and feedback here if I find anything!

[CODETL19]

With a bit more investigation I have found that this is nothing to do with the code. It looks to be down to some specific datastores in our vCenter as I have my script working on a different datastore, using the methods discussed here + some.

No idea what the cause is on the datastore, but we are looking further.

If you have any suggestions, please fire away!

[CODETL19]

Hi again,

So far I've now found this difference.

When running:

$ds = Get-Datastore -Name "DATASTORE_NAME" -Server "server.myserver.com" | Get-HardDisk

$ds.Filename

My files do not show in the results, but if I browse to the datastore in the GUI, the files show.
They show their 'type' is of 'File' as you can see below

However when I run that same code on the datastore that is not giving me grief, the results are returned, and the files are of type 'Virtual Disk' as shown below:

The only difference I could see between the datastores is that the working DS version is VMFS 6.81 and the NON working DS is VMFS 6.82. 

I am adding the disks to each DS in the exact same way... Any thoughts on this one?

[LucD]

You could try to unregister/register that VM, and check if that changes the type of the files.

Do all VMs on that datastore show the VMDK as "file"?

I suggest opening an SR.

[JieX]

I normally create new scsi controller first on second node with flat disk, then get scsi name

New-HardDisk -VM $vm2 -DiskType flat -CapacityGB 1 | New-ScsiController -BusSharingMode Physical -Type ParaVirtual

$scsiname2 = ( $vm2 | Get-ScsiController).name[1]

Then, get disk naa id from node 1 and export result to csv

Get-VM $vm1 | Get-HardDisk -DiskType RawPhysical | Select @{N='VM';E={$_.Parent.Name}},Name,FileName | Export-Csv -Path .\xxx.csv -UseCulture -NoTypeInformation

Then read result from csv and add them each to node 2

Import-Csv -Path .\xxx.csv -UseCulture | ForEach-Object -Process {

  $vm = Get-VM -Name $vm2

  New-HardDisk -VM $vm -DiskPath $_.FileName -Controller $scsiname2

}

This should work, I use it each time to mount RDM disk. Please also make sure both servers power off.

[CODETL19]

Thanks for the suggestion JieX, I already have the naa.id for the disk and the issue isn't creating the SCSI controller.

Considering the code works 100% on Datastores with a version of 6.81, its got to be something related to the versioning and the file type.

We will be raising a SR soon once I get relevant access from the company I work for.

[CODETL19 · Accepted solution]

Just closing the loop here.

After many months of back and forth with vmware we were unable to find a concrete solution for this that we knew would resolve it.

I didn't have much luck with the support team to be honest, which was dissapointing.

But the issue is somewhat resolved in our environment. A recent push from the business forced many of our ESXI hosts and other infrastructure components to be updated to newer versions (7.0.3 +) which resolved the issue in most sites.
Some sites still exhibited the same behavior after this update, but then seemingly went away and no one knew why 💀.

The key point we spotted was that this issue would only occur when the RDM was created and created 2 files on the datastore. One would end in .vmdk and the other would add -rdmp.vmdk to the end of the file. Both files would show with a type of 'File' (screenshot attached).

Whereas this did not occur when the RDM type was of VMDK.

It looks like the raw disk mapping pointer file was showing in our datastore for some reason.

Maybe an old bug on an ESXI version we were using, really not sure!!.