VM BUG = "Object reference not set to an instance of an object"

[senfinger]

I have two users that when they revert from a snapshot and it powers off when they go to power it back on they receive an “Object reference not set to an instance of an object.”. They will then call the IT dept to manually power them back on and it comes up fine.

Any ideas?

Thanks in advance!!!

[senfinger]

They are using the EXE client not the browser. (We use Ver. 2.0)

[VirtualNoitall]

Hello,

I am troubleshooting with issue right now with VMware. It has been about a month I have a Webex session with them tomorrow. If I find out anything I will respond back.

This started for us right after patch 2 was applied to our VC server. The users are also able to power up the virtual machine via the VC Webclient. If you have it running\available you could point your users there to save a call to the Helpdesk.

[senfinger]

Sounds about what happened with us! LOL

Let me know something whenever you can~

Thanks-

Stephen

[VirtualNoitall]

Sure thing!

[luizhbedin]

Same issue here, sometimes...

[senfinger]

Anything Anything??? = )

[VirtualNoitall]

No, just more frustration with support.

*They had me reproduce the error while they were watching. I passed these details on 6 weeks ago . The screen capture I sent them looks exactly the same.

*They upped the VC logging and had me reproduce the issue

They have all the logs and are going over them now.

[senfinger]

You rock! Keep us updated!!!

-S

[VirtualNoitall]

Had another WebEx session this am. Still investigating. It sounds like it is going to get filed as a bug. I pointed him to this thread to see that others are seeing this as well.

If anyone has anything to add feel free to log a support call and/or post details here. Does the VC web client work for folks who see this message in the VC client? It does for us.

[senfinger]

Does the VC web client work for folks who see this message in the VC client? It does for us.

Yes, it does for us... I hate to think we are the only ones who have this so-called "bug"...

[VirtualNoitall]

OK, what kind of access do you setup your users with?

In our environment users get placed in two groups. One that gives them very restrictive access to a vm or folder of vms and another that gives them access on the hosts to do snapshots. When we have a test user only in the group that gives permissions at the VM level all is well. As soon as we add them to the group that also gives them access on the host, for doing snapshots, then they see this message. This is not great because our users, we run hundreds ot test and development servers in this environment, need to be able to do snapshots. Does this sound at all like what you do?

[senfinger]

We usually give every one Manage and Snapshot to their specific VMs. Also we will make app-owner groups so a folder per person with all of their VMs under it.

[senfinger]

Still waiting on an answer... hugh...?

[VirtualNoitall]

Yes, I need to provide them a little more info as they are trying, so far unsuccessfully, to recreate the problem. They are also in the midst of filing an engineering PR.

[senfinger]

Thanks for the update!!! = )

[senfinger]

Anything yet? = )

[wes_prather]

I've just stumbled upon the same bug, and have opened a case this morning.

I can poweron the VM in question using an "Administrator" role applied at the Hosts & Clusters level, but not using a limited role which normally can perform this action.

We applied Patch2 to VC2.01 a couple of weeks ago.

Tried restarting the VirtualCenter Service on the VC server, to no avail.

I can also connect with VI Client 2.01 (build 40644) DIRECTLY to the ESX node hosting the VM at this time and power it on.

Not sure what the deal is yet, but that's why the support is there, eh?

Will post results of this inquiry when completed. (or they give up and finally build this on Linux. -- Where's my Linux Remote Console ?

w

[VirtualNoitall]

For ours we are still working with support. It looks like the problem only happens on hosts in a cluster ( regardless of if DRS or HA are turned on or off ). The next step for us is to move one host to a new cluster and see if the problem surfaces there.

[VirtualNoitall]

Hello,

Looks like the issue, for us, was an absence of permissions on the cluster itself. We typically assign users permissions on virtual machines, or folders of virtual machines, and hosts. When I added read only to the cluster and set it to not propagate my users were able to start their virtual machines without getting the error.

Hope this helps someone else. Only 2-3 months working with support only to stumble upon this myself