Invalid configuration for device '0' when removing hard disk

[Trebormint]

I have a script that I've put together from various posts and very useful advice from Luc-D that we use for DR. It runs through a list of datastores and registers any .VMX files it finds. At the same time it changes the NIC configuration and removes all hard disks apart from hard disk 1. Hard disks are removed because they are invalid in the recovered .VMX file due to the path changing, they are added back using another script later on in the recovery process.

Until recently it worked just fine, but after an upgrade to ESX 3.5U4 and VirtuaCenter 2.5 (previously on ESX 3.02 & VC 2) it has stopped working. We tried removing the hard disks manually via the VI Client but that didn't work either. It was then discovered that it would work if connected directly to the ESX server rather than the VC.

A discussion with VMWare support concluded that this is a feature of newer versions of the virtualcenter whereby it is not possible to remove an invalid virtual hard disk or there abouts. This seems most odd.

The script I'm running uses the following to remove the hard disks:

function removevolumes

{

param ($vmObj)

1. write $vmObj.config.hardware.device

foreach ($dev in $vmObj.config.hardware.device)

{

1. Look for all volumes apart from Hard Disk 1

if ($dev.deviceinfo.label -match "Hard Disk" -and $dev.deviceinfo.label -ne "Hard Disk 1" )

{

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec

$spec.deviceChange = @()

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

if($dev -eq $null) {return}

$spec.deviceChange[0].device += $dev

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

$dev.deviceinfo.label

write $vmObj.ReconfigVM_Task($spec)

#$taskMoRef = $vmObj.ReconfigVM_Task($spec)

$task = Get-View $taskMoRef

1. Wait for the task to complete

while($task.info.state -eq "running" -or $task.info.state -eq "queued")

{

$task = Get-View $taskMoRef

}

}

}

}

Is there another way to remove all of the hard disks? Perhaps directly editing the .VMX and removing the invalid hards?

Thanks

[LucD]

I think the key of the problem is the "invalid virtual hard disk".

If I remember correctly, the invalid hard disks point to backing files on datastores that your DR VI environment doesn't know.

One more question, in the DR environment the guest are powered on again.

Is that done via a PowerCLI script ?

Wasn't there a question at that point ?

The ESX server should have recognised that there were invalid paths in the VMX file for some hard disks on the guests.

[Trebormint]

Yes, the invalid hard disks point to datastores that have a difference name / reference - what is this long number refered to as? Is there a way of making the long reference number the same as on the original copy? Or is it assigned when ESX "discovers" a new volume/LUN/datastore and unchangable?

The guests are powered on using a script and during the power on there is a question about the UUID which the script answers.

If I power on the guest I without modification I get an error message stating "virtual disk 'hard disk 2' is not accessible on the host: Unable to access file. [] foldername/filename.vmdk. I'm assuming the datastore value is empty because .VMX file points to the volumes number, rather than the name.

[Trebormint]

After some Googling and trawling through our logs files, I've discovered that ESX thinks our datastores are snapshots and is therefore assigining them a different UUID. Quite why this is the case I'm not sure, but it is discussed in this article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=648264...

The problem appears to be with our SAN, so I'll ask the vendor if they are aware of this.

If I set the resignature value to 0 and disallowsnapshotlun to 0, the datastore gets the original UUID. If this can be set using powershell (be surprised if it is not the case), I'll change the settings temporary just before a scan and then put them back after the scan.

This will make recover of any servers using VMDK files, but I'll still need to do something with the RDM volumes.

[john_gallucci]

In the original post it says that the NIC configuration is changed also. I believe this may be the cause of your error message and not removing the virtual hard disk. I have all my templates sitting on single host. This host recently was upgraded to ESX 3.5 Update 4. Since the upgrade, anytime a template is deployed AND the NIC configuration is changed (we deploy to many different networks) the error message 'Invalid configuration for device '0' appears.

The only way for me to successfully deploy virtual machines now is to leave them powered off after the clone/deployment, manually configure the NIC, and then manually power it on (really pain and waste of time!). Has this problem been addressed anywhere or been opened up as an official bug by VMware?

[Trebormint]

I worked around the problem by running the script against the ESX host, rather than the through the Virtual Centre server. I prefer to use the latter because it uses AD authentication whilst the former requires ESX/Unix authentication which is not something we use very often.