VIEW Manager 4.6 "already used" counts as powered on desktop

[bjm534]

I've seen a variety of posts regarding this "already used" state of a VM with the excerpt from the VIEW 4.6 release notes describing the issue. I may have discovered a new issue related to this. It appears that if I have the power state on the pool set to "take no power action" and the provisioning settings set to keep 2 VM's powered on, the desktop pool counts the "Already Used" VM's as powered on VM's eventhough my users can't connect to them. As a result my users can not connect to the pool because the VIEW admin console thinks that the "powered on" setting is satisfied because my 2 "powered on" VM's are on. Also the "already used" state does not appear to be defined in any of the documentation, so there is no explination of what it is other than on VMTN and release notes. I'm going to try to write a powershell script to get a list of desktops and thier status, and try to get it to filter based on the "already used" status and perform an administrative reset. In the release notes it states that this state can occur from an unexpected shutdown,  a user initiated shutdown of the VM, or unexpected logoff. I'm going to create an active directory GPO to remove the shutdown button from the VM's in that pool, but what constitutes an "unexpected logoff" (is that a disconnect?). In either case this may be a feature request or a fix that needs to take place.

-Brad

[jornlux]

Were you able to solve this ? This is crippling floating pools, and literally makes them unusable.

[bjm534]

We've done a few things that have helped. First we removed the shutdown button from the start menu, which has driven the occurances of this down. Second we've set the pools that have this issue to have a higher number of VM's powered on and ready to go, which seems to have helped. We're researching a way to powershell resetting a desktop based on the status of a desktop being "already used"

[jornlux]

Seems fair enough, but these kinds of workarounds should be unnecessary.

Will try your approaches to reduce the scope of the problem, but if this persists to bug us we need to work out a more permanent fix. Will post here if I work out something.

Hopefully VMware will adress this in a future patch or update.

Thanks.

[wframe]

Greetings,

I was looking to automate resolution of known issues like this.  Unfortunately, I received the following explanation:

"The status of VMs is stored in the ADAM database and is updated by the Virtual Machine to the connection broker on a regular basis. We do not support directly querying the ADAM database for this information.

A feature request has been filed previously and development is working on adding a powershell cmdlet to allow querying the VMs status. At this time there is no workaround aside from using view manager to watch the status."

It sounds like we will be getting the functionality you are looking for (in terms of querying the status).  Hopefully they won't skip over this in VMware View 4.x...

Regards,

W