VMware Cloud Community
timw18
Enthusiast
Enthusiast

Getting rid of an unknown or inaccessible vm

On my esx 3.5 server I had issues in that I lost a vm, Issues with the drives, but now I am left with an "unknown (inaccessible)" . When I try to do anything with it I get "object reference not set to an instance of an object" error.

I want to get rid of this. How do I do it?

If anyone can help thanks

Reply
0 Kudos
10 Replies
Kahonu
Enthusiast
Enthusiast

Remove from inventory and manually delete the folder???

Reply
0 Kudos
lamw
Community Manager
Community Manager

Just right click on the object and "remove from inventory" and re-register the VMs if they're still on disk or if you've been able to recover. It's just a stale object left in vCenter since the removal was not initiated by vCenter or even the ESX Host, then it does not know what the object is.

Reply
0 Kudos
timw18
Enthusiast
Enthusiast

Wish it was as easy as just a right click. The drive is gone burgers so there is no option to add to inventory. The server has been rebuilt and is running on another esx box. If I do a click of any sort on the unknown vm it comes up with the whole story about the "object reference ......." you know the rest. So I just need to get rid of that silly icon saying unknown object. One way is just to rebuild the ESX server but was wondering if there was any way of doing without the sweat.

Reply
0 Kudos
lamw
Community Manager
Community Manager

Are you doing this directly on the ESX or on vCenter?

Reply
0 Kudos
timw18
Enthusiast
Enthusiast

Was doing on VC but have now removed the ESX server from the VC and the unknown icon has gone with it. So am now trying to get it off the ESX server.

Reply
0 Kudos
lamw
Community Manager
Community Manager

Correct, usually you should be able to just remove from the ESX Host, try connecting directly to the ESX with VIC.

Another thing you could try is check out:

service mgmt-vmware restart

This will not hurt or cause any of your VMs to stop functioning, I would even suggest trying this first and see if you get the unknown instances to go away if you can't right click and remove from inventory. If that fails then check out the XML file to see if it's still lurking in there.

/etc/vmware/hostd/vmInventory.xml

See if you find your VM or the unknown VM and try to remove it and restart the management agent

Reply
0 Kudos
phntsupp
Contributor
Contributor

I had one of these unknown VMs following a failed storage vmotion................

followed this thread today and deleted the entry from the VC database (vpx_entity vpx_vm), edited the vmInventory.xml file on the host to remove the entry, restarted the management service and now the unknown VM has finally disappeared.

Many thanks for this information.

Reply
0 Kudos
RParker
Immortal
Immortal

I had one of these unknown VMs following a failed storage vmotion................

That's one way to do it, but the problem is the ESX host is recognizing a VM that's NOT in the VC inventory, which is why it's 'stuck' in the database. Restarting will force the ESX host to 'refresh' the inventory and thus report to the VC that it now has a NEW list of VM's. Then the VC will remove 'orphaned' entries, and this occurs when the agent synchs with the database.

Your method works, it is a LOT more work. And some people don't want to dig for these VM's in the SQL database.... or have access to that DB.

Reply
0 Kudos
phntsupp
Contributor
Contributor

We tried that first - removing the host from virtual center, restarting the agent, restarting the virtual center service, rebooting the host, editing the db - eventually the thing that worked for us was editing the xml file and restarting the management agents. Some times some things work for some people some times they don't. If it was all easy we wouldn't be looking on here. I just wanted to add what had worked for us.

Reply
0 Kudos
RParker
Immortal
Immortal

Some times some things work for some people some times they don't. If it was all easy we wouldn't be looking on here. I just wanted to add what had worked for us.

True but like you said, that's why we get answers here. We are glad for the extra solutions.

Reply
0 Kudos