VMware Horizon Community
PvdB013
Contributor
Contributor

View event: BROKER_POOL_OVERLOADED

Hi all,

I have a question about a specific View event: BROKER_POOL_OVERLOADED. This message appears every day on different VM's on all of our Connection servers and all pools.

29-07: End of day, user logoff VM

30-07: User try to logon and receive message: 'The assigned desktop source for this desktop is currently not available'. Following message is in the Event database: BROKER_POOL_OVERLOADED:
"Unable to launch from Pool <poolname> for user <domain>\<user>: All responding machines are currently in use"

The user tries to logon several times, but don't succeeded. After a Reset-VM it's possible to logon again. Does anyone know what 'BROKER_POOL_OVERLOADED' exactly means and is it possible to relate this to a specific logfile?

Client OS: Windows 7 SP1 64-bit
VMWare Horzion View: 5.2(Agent 5.2)

Thanks in advance!

Reply
0 Kudos
6 Replies
Linjo
Leadership
Leadership

Here is the explanation:

BROKER_POOL_OVERLOADED

Unable to launch from Pool ${DesktopId} for user ${UserDisplayName}: All responding machines are currently in use

Found it in the documentation:

VMware View 5.2 Documentation Library

It seems that there are more users then available desktops.

One reason for this is that the desktop is still logging off, maybe a roaming profile or a application that is in a hung state.

Try to investigate what could be interfering with the logout or tweak the setting and close applications faster at logout.

// Linjo

Best regards, Linjo Please follow me on twitter: @viewgeek If you find this information useful, please award points for "correct" or "helpful".
Reply
0 Kudos
PvdB013
Contributor
Contributor

Thanks Linjo. Our users have their own static full clone VM. Because of this it isn't possible that there are more users then available desktops.

In de Application log I see(on logoff) the following events(warnings):

DETAIL -

2 user registry handles leaked from \Registry\User\S-1-5-21-1229272821-1801674531-839522115-138175:

Process 6508 (\Device\HarddiskVolume1\Windows\System32\winlogon.exe) has opened key \REGISTRY\USER\S-1-5-21-1229272821-1801674531-839522115-138175

Process 2068 (\Device\HarddiskVolume1\Program Files\VMware\VMware View\Agent\bin\v4v_agent.exe) has opened key \REGISTRY\USER\S-1-5-21-1229272821-1801674531-839522115-138175\Volatile Environment

AutoEndTaks = On(1)

AutoEndTasks

Reply
0 Kudos
Linjo
Leadership
Leadership

Sure its possible, if the desktop is not reported as "available" then the user can not access it...

Not sure what those event could be related to, is there any other things happening at logut? Any profile that will need to sync back?

You could also try this setting: waittokillapptimeout

// Linjo

Best regards, Linjo Please follow me on twitter: @viewgeek If you find this information useful, please award points for "correct" or "helpful".
Reply
0 Kudos
DrOctane
Contributor
Contributor

We are having the same event error of broker_pool_overloaded.

VMware View 5.1.3 and agent is 5.1.3 . We have both automated and manual pools having this issue. Even with a dedicated pool and the vm showing available, the user is getting no desktop sources available. This has got worse in the past couple of days (before time change) and VMware found a replication warning (been there since 2013) in the adam events on the connection servers that dealt with FSMO...we got that fixed by resetting the Naming Master (bouncing all connection servers and vCenter server also) and all seems to be good on that front. But we are still having issues with users accessing available dedicated VMs and the broker_pool_overloaded event. Im currently waiting on a call back from an engineer but they are taking their time and this needs to be addressed asap. Thanks in advance for any input that someone can provide.

Reply
0 Kudos
Aubman04
Contributor
Contributor

DrOctane - did you ever find a resolution for the issue.

Reply
0 Kudos
h3nkY
VMware Employee
VMware Employee

There is know issue in 5.x similar with this and has been fixed in 6.0.

Please test using 6.0 to see if it solves yours.

Thanks.

Reply
0 Kudos