VMware Horizon Community
sclausson
Contributor
Contributor

Error: The assigned desktop source for this desktop is not currently availble

Since we switched our virtual desktop pool to suspend mode (to save on resources) users have been periodiacally receiving this message when they first try to connect to the desktop

The desktop has failed to open (name of pool). The assigned desktop source for this desktop is not currently available. Please try connecting to this desktop again later, or contact

your system administrator.

If they click on OK to close the error message and try again, most of the time the desktop will launch immediately. On rare occasions the users will need to logout of Portal, log back in, and launch the desktop again.

Does anyone know of any timers, retry values, or other settings that might assist in supressing this message and have the desktops launch without the user having to take these extra steps?

Thanks.

Reply
0 Kudos
14 Replies
markvr80
Enthusiast
Enthusiast

I've also been having this problem. I think it can take quite a while sometimes before the agent wakes up after the desktop unsuspends. As you say, most of the time users can connect if they try a couple of times.

However sometimes they can't connect until they call us and we reboot the VM. This is a major problem, as there is nothing the user can do until we've rebooted it. I've had SRs with VMWare who couldn't find anything.

This is holding back our VDI deployment, until users can log on reliably we can't take it any further.

If anyone has any solutions/seen this before I would be very grateful!!

(Another problem is patching/updating VMs that are suspended and essentially never reboot).

sclausson
Contributor
Contributor

We're experimenting with some users using the Win32 client to connect rather than thru the browser/portal. It's too early to say for sure, but so far it looks like the win32 client users are having no connectivity issues, while the browser users are still grumbling.

Reply
0 Kudos
mnasir
Enthusiast
Enthusiast

I have deployed view on our environment, it works like a charm - 70 linked clones on multiple WAN offices

When I was doing the pilot , I experiance the same issue, the way to fix the issue is -- see my settings below, you will notice I power off VMs after they are used (DON"T suspend it), also, you need to calculate the right "Number of Desktops (available)" accurately. For my deployment, when I create the desktop pool for a training room, I usually I keep the available number high (since I assume there is a higher probability, that many users will login at the same time - more resource intensive) but when I deploy it for a remote office, I can keep the available number lower - since not all users will login at the same time.

Number of desktops (minimum): 1
Number of desktops (maximum): 17
Number of desktops (available): 8
Stop provisioning on error: Yes
VM naming pattern: vm-ebtrn-A
When VM is not in use: Power off when not in use
Power off and delete virtual machine after first use: No
Automatic logoff after disconnect: Immediately
Allow users to reset their desktop: False

Please award points, if you find this post helpful.

Reply
0 Kudos
mnasir
Enthusiast
Enthusiast

Hi,

Did you try my recommendation to switch to PowerOff instead of suspend - you will get more consistent behavior that way. Also, just try increasing minimum number of available desktop. I have more that 70 linked clones presented over 2 IBM 3650 quad servers - none of my users are getting pool unavailable messages.

If you find my recommendation helpful, please consider awarding points.

Reply
0 Kudos
sclausson
Contributor
Contributor

I am trying a few suggested changes today. One of which will be the power off instead of suspend mode option. Since we are using a persistent pool, I don't think the number of available desktops will apply in our configuration. I'll post all changes and results tomorrow after users have had a chance to log in.

Thanks for the suggestions thus far.

Reply
0 Kudos
mnasir
Enthusiast
Enthusiast

Great, looking forward to hearing back from you.

Thanks,

Meraz

Reply
0 Kudos
mnasir
Enthusiast
Enthusiast

You should be able to apply my suggested changes even in the persistent pool (automated) - I just tested it - by default it doesn't show - you need to click the advanced tab to see it.

Provisioning Settings
Under the advanced Settings
Check the box : Enable Advanced Number of Desktops Settings
Number of desktops (minimum):
Number of desktops (maximum):
Number of desktops (available):
Please award points, if you find this post helpful. - Thanks.

Reply
0 Kudos
markvr80
Enthusiast
Enthusiast

I think the point about persistant pools and minimum number of available desktops is that users always get the same desktop. The min available number would only apply if large numbers of new, previously unseen users were loggin on at once. For existing users it has no effect.

The problem with shutting down is it takes a few min for the destop to boot, during which the user gets no feedback on what is happening (eg, on a normal PC you can see it loading, on a thin client it just sits there saying "connecting" for ages). Also one of the features of VDI for us is that someone can disconnect their desktop, go home and get it back exactly as it was when they left. If the desktop was to shutdown whenever someone disconnected I think we would have lots of upset users who went to meetings and came back to find their desktop has been killed..

I think there are bugs in the agent/manager. I'm running a scripted automated logon at the moment which firstly monitors the entire setup and then emails me if it fails, so this will pick up any failures in the entire server stack (View server, vCenter server, SQL server) and alerts if it fails to logon so I can try and get a VM to test against. Restarting the agent doesn't help, the entire VM has to be rebooted for them to logon again.

MechaMan
Contributor
Contributor

Number of desktops (minimum): 1

+ Number of desktops (maximum): 17+

Number of desktops (available): 8

+ Stop provisioning on error: Yes+

+ VM naming pattern: vm-ebtrn-A+

+ When VM is not in use: Power off when not in use+

+ Power off and delete virtual machine after first use: No+

Automatic logoff after disconnect: Immediately

+ Allow users to reset their desktop: False+

I am new out here and to VMWare, so you will have to excuse my ignorance on things out here for awhile. I am in the process of learning VMWare. I have a problem similar to the one mentioned here, where are these above settings accessed?

Thanks in advance for any and all help!

Reply
0 Kudos
aryacms
Contributor
Contributor

Hi All,

Is this issue already solved in vmware view 4.0.1? We're testing view using view 4.0.0 Build-210939 and experiencing the same issue and pretty annoying. Sometimes no user can be connected at all even if we're resetting their desktop, and only can be solved if we also reset the view manager server. User desktop is a plain WIndowsXP VMs in vSphere 4.0.0 Buil-16400. We can't use mnasir suggestion due to our application behavior, makes it impossible for us to auto-logoff after user disconnect.

Here's our view configuration:

Desktop Persistence: Persistent

Type: Manual Pool

When VM not in use: Do Nothing

Automatic Logoff after disconnect: Never

Active Desktop : 4

Total Desktop Source: 7

looking forward for any suggestion...

Thanks

Reply
0 Kudos
slachapelle
Contributor
Contributor

Hi, we have been experiencing the same problem, it seems to have been triggered by a virtual center database unexpected shutdown. Following recovery of the database and ensuring VC and View Connection servers were up and fine, a few users started to get the message "The assigned desktop source for this desktop is not currently availble" at logon from their thin client. I suspect this only happens with users that do not logoff (they disconnect or shutdown thin client) but it is not replicable in a consistent manner.

Restarting the View agent did not fix the problem (even though I may not have waited long enough) but rebooting the virtual desktop fixes it always. This problem is also impacting our full deployment of the virtual desktop infrastructure.

We had been using View 4.0.0 and our next step is to upgrade to 4.0.1, anybody knows if the new version fixes the problem?, this seems to have been lingering around for a while.

Cheers,

Reply
0 Kudos
mholgate
Enthusiast
Enthusiast

>Number of desktops (minimum): 1

>+ Number of desktops (maximum): 17+

>Number of desktops (available): 8

>+ Stop provisioning on error: Yes+

>+ VM naming pattern: vm-ebtrn-A+

>+ When VM is not in use: Power off when not in use+

>+ Power off and delete virtual machine after first use: No+

>Automatic logoff after disconnect: Immediately

>+ Allow users to reset their desktop: False+

>I am new out here and to VMWare, so you will have to excuse my ignorance

on things out here for awhile. I am in the process of learning VMWare.

I have a problem >similar to the one mentioned here, where are these

above settings accessed?

Hi MechaMan,

In VMWare View Manager 4.0, these settings are located under Desktop and Pools, Summary tab of a selected pool... here are some screenies.. Smiley Happy

Mike... VM, Virtually!!

Mike... VM, Virtually!!
Reply
0 Kudos
Trog678
Contributor
Contributor

I tried your suggestions and I am still having the problem.

My admin account will always work. It's domain user accounts that will work

then stop working and recieve the "assigned desktop source for the desktop is not currently availble.

Any place I need to add user permissions? But why would it work then stop.

Then start working again?

Reply
0 Kudos
itsmesri
Contributor
Contributor

Hi

Have you got any solution for the issue mentioned.we have vmware horizon 7 and everyday morning people are calling for the desktop unavailable issue.

The desktop is pinging and even in the console it shows the user is logged in if we try a admin account.in view admin console it shows agent unreachable.

Reply
0 Kudos