Registering VM with PowerCLI and multiple disks on different datastores

[jmapt]

Hello,

I am working on a PowerCLI script for automating some DR testing environment work.  One issue I have is that we are taking a SAN snapshot of multiple volumes and created clones of them and are then registering all of the vmx files on that datastore using code provided by others in the community.  When these register, it registers the initial disk on the VM, but there are usually 2-3+ other hard drives on the VM and they are each on independent datastores (SQL Data, Logs, tempdb, etc).  Those all come in with errors if you look at the VM settings and it shows the path to the disk as /vmfs/volumes/guid/VMname/diskname.vmdk rather than showing the actual datastore.

The cloned datastores also exist but my guess is that the VMX is referencing the original vmfs datastore not the cloned and resignatured VMFS that is attached.

Does anyone have a good solution to this or a workaround to automate grabbing the disk?  Was thinking perhaps scanning all the other datastores for a matching vmdk filename and updating the VM to use it?  But not sure of the best way to scan for all "broken" vmdk's on all the VM's and then trying to search for each resulting disk and "updating" it.

Code used to register all vm's:

# register all the vm's
Write-Host "Attempting to register all of the vm's from datastores we just added."
foreach($ds in Get-Datastore | Where-Object {$_.Name -match ($addedVolNames -join "|")}) {
# Collect .vmx paths of registered VMs on the datastore
$registered = @{}
Get-VM -Datastore $ds | %{$_.Extensiondata.LayoutEx.File | where {$_.Name -like "*.vmx"} | %{$registered.Add($_.Name,$true)}}
   # Set up Search for .VMX Files in Datastore
New-PSDrive -Name TgtDS -Location $ds -PSProvider VimDatastore -Root '\' | Out-Null
$unregistered = @(Get-ChildItem -Path TgtDS: -Recurse | `
where {$_.FolderPath -notmatch ".snapshot" -and $_.Name -like "*.vmx" -and !$registered.ContainsKey($_.Name)})
Remove-PSDrive -Name TgtDS
   #Register all .vmx Files as VMs on the datastore
   foreach($VMXFile in $unregistered) {
      Write-Host "Attempting to add VM: $($VMXFile.Name)"
   New-VM -VMFilePath $VMXFile.DatastoreFullPath -Location $recoverySiteVMFolder -RunAsync -ResourcePool "DR" | Out-Null
   }
}

[LucD]

Wouldn't it be a better idea to list the VMDK for each VM before taking the snapshot?

Starting from that report, and since you must know which datastore produced which snapshot, it shouldn't be too hard to attach the correct VMDK to the VM

[jmapt]

In this case, not really an option.  We are using the SAN snapshots, independent of VMware and are testing a DR failover, so being able to access that information is out of scope of the test.  I am testing just turning everything on from a snapshot.

the workaround I am trying will be to just not resignature the VMFS, which should let the links to the disks still work.  Not ideal, but since it is in a separate site, it should be ok on this test.

the only other idea was to try searching the attached volumes for a matching disk and theN removing the existing and attaching the found one.  But keeping track of controllers and locations is a lot to remap each time.

[LucD]

There is a lot of info in the .vmx file.

You would first need to find out how many, and of what type, controllers there are.

For that you would need the lines

scsi0.virtualDev = "lsilogic"

scsi0.present = "TRUE"

Then you will have to scan for the .vmdk entries.

From the x and y, you can find out the bus and deviceid of the VMDK

scsi0:0.deviceType = "scsi-hardDisk"

scsi0:0.fileName = "myvm.vmdk"

But there might be some flaws in the logic, one could definitely have .vmdk files with the same name in different folders on the same datastore.

Can you rely on the foldername, which should correspond with the DisplayName of the VM?

Another point, if the VMDK are on different datastores, can we be sure that the folder in which they are located, corresponds with the DisplayName of the VM?