User foo\test could not be allocated a machine for desktop MyDesktopPool - reason: All sessions are busy - check for extraneous console logins

[ragazzi]

HI,

I'm facing a wired problem at the moment.

Users cannot login to a non-persistent desktop pool. they get the Message:

"The desktop failed to open. This desktop is currently not available. Please try connecting to this desktop again later, or contact your system administrator"

The Pool consists of 22 Desktops. The moment a users wanted to log in, only one other Desktop was connected by a different user. When I tried it at the same time from another computer it worked for me.

A few minutes later it also worked for the other user....

This happens to random users all the time.

These are the entries in the log of the View Administrator in chronological order:

first message:

(SESSION:737D03B8032605466D6CE7B5CD5D1C93) BROKER_LOGON:USER:PUKPAT\patasts01;USERSID:S-1-5-21-3664883855-427485546-3830444683-1778;USERDN:CN=S-1-5-21-3664883855-427485546-3830444683-1778,CN=ForeignSecurityPrincipals,DC=vdi,DC=vmware,DC=int;

second message:

(SESSION:737D03B8032605466D6CE7B5CD5D1C93 patasts01) User PUKPAT\patasts01 has successfully authenticated to VDM

third message:

SESSION:737D03B8032605466D6CE7B5CD5D1C93;C7EE9DB221FEAD7D47D781251D2874AE) User Foo\test could not be allocated a machine for desktop MyDesktopPool - reason: All sessions are busy - check for extraneous console logins

fourth message:

(SESSION:737D03B8032605466D6CE7B5CD5D1C93;C7EE9DB221FEAD7D47D781251D2874AE) SERVERS_OVERLOADED:Desktop:CN=Patienten_Desktop,OU=Applications,DC=vdi,DC=vmware,DC=int;USER:PUKPAT\patasts01;USERDN:CN=S-1-5-21-3664883855-427485546-3830444683-1778,CN=ForeignSecurityPrincipals,DC=vdi,DC=vmware,DC=int;Protocols:[RDP];

Has anyone similar problems an has a solution for this?

[mittim12]

It could be a case where a user is being directed to a VM in the pool that is not functioning properly. I have seen instances where a VM is up and running and reporting back to View that everything is ok but it wouldn't accept any RDP traffic. I would run the support script on some of the client machines that experienced the issue and see if you can find a common VM.

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

[ragazzi]

What do you mean by "running the support script"?

[mittim12]

If you look under C:\program files\vmware\vmware view\client\dct there is a file called vdm-support.vbs that can be run. This script gathers all of the logs and events for View. You can look through some of the logs to hopefully determine the issue. Just use a dos prompt, go to the path above, run cscript vdm-support.vbs.

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

[milenapavlovic]

We are running View 4.0.0. and experienced similar problem:

“User could not connect, view log showed error: user could not be allocated a machine for desktop “pool” – reason: All sessions are busy …”

User was able to connect to other pools, number of connections is far from licensed number; pool/desktop sources didn’t show any desktop associated with user;

ESX log didn’t show any VM deleted;

Tried to remove and add user from group entitled with pool, didn’t help;

workaround: We deleted domain account and created new (we were lucky, all personal information was baked up)

We couldn’t find out how to use vdm-support.vbs.

How can we find out what happened and how to prevent it in future?

[ragazzi]

We haven't solved the problem yet. A specialist analyzing the our system mentioned that there is a timeout between a userlogon and and the answer from the desktop pool. If the desktop pool has too much latency the vmware view clients assumes that there is no desktop left.

Although our environment is very small (25 desktops) and running on local disks on the ESX server, local disks were identified as the bottle neck of the systems. Local disks may only do about 30-40I/O per second. Our next test is to attach the server to a SAN disk which allows several hundred I/O's per second. Probalby this will improve system performance over all.