Re: No Desktop Sources errors and lockups

Full_Throttle · ‎01-26-2010

2 weeks ago I upgraded my view deployment from 3 to 4.0. I have 2 hosts running VSphere 4.0U1. I created a new View connection broker using w2k3, with a separate SQL server. The procedure I used was to remove the VM from the old View 3.0 connection broker, uninstall the view agent, reboot, migrate the VM from the ESX 3.5 host it had been using over to the new Vsphere cluster. At this point I went through the tools upgrade, reboot, version 7 hardware upgrade, reboot, and only then,once the VM reported it was running the correct tools and latest hardware did I install the View 4.0 agent. I would then create the "desktop" in View 4.0 connection broker. I ran a few test VM's for 2 weeks with no issues, so I went ahead and upgraded the rest of my view vm's.

A few days after this process, I began to get calls from my desktop users that there were no desktop sources available. I can drop out and ping the VM, even connect to it via remote computer management. When I go to the console and try and log in, I press "Ctrl, Alt, Delete" & then it locks up. I have to do a power off of the VM. This is happening on 4 or 5 of my 20 VM's. These ran flawlessly before the upgrade, so I am confident it is something with the new agent. I have tried setting some to use RDP vs PCoIP with no change.

Has anyone else experienced this?? Any ideas? These are a 1 to 1 desktop and not in a pool. They are DHCP, and I have confirmed they have an IP address and respond to pings. On 1 machine I remotely connected to it via computer management and restarted the view agent and it worked somewhat, but then a 2nd time that didn't help. very strange. Suggestions are welcome.

Mike

Einherjar55 · ‎01-26-2010

I have experienced similar problems with both persistant and non-persistant pools. Users would try to log in and get the No Desktop Sources Available message or it would try to log in and then the client would disconnect. I found that users would also get this problem if they left their station idle for too long. I haven't done much testing with RDP but this happened most of the time with PCoIP. A couple days ago I disabled the screen saver and power saving settings and so far I have not seen the issue crop up again. Could be worth a shot.

Full_Throttle · ‎01-26-2010

I will look into this. It always happens first thing in the morning. I have my users reboot their VM when they go home in the evening, so noone is actually logged in when they arrive in the morning. I haven't looked at the power save settings, this could well be the problem. I will check and see.

Thanks,

Mike

Full_Throttle · ‎01-26-2010

After pouring over mor info here on the forum, I stumbled across a setting that I didn't realize was "off" by default. I have not enabled the direct connect option in the View server settings. This means that my VM's woud have to be connecting through the View server correct? I wonder if this setting could have an impact like I have been seeing.........hmmmmm.

I have some testing to do.

nonsparker · ‎02-01-2010

I am having the same issue, I have not been able to figure it out. I have an open SR but everything we have tried so far has not worked.

Twitter @thickguythinapp
Website thickguythinapp.com

cdiiorio · ‎02-04-2010

I don't have any lockups but have the same issue in regards to desktop sources. Interestingly, this occurs only wiht Windows 7 and Windows Vista VM's. Our XP VM's work great.

I use non persistent pools to offer different applications in a training environment. Users log on as one of 20 or so Domain entitled users and are presented with 3 desktop choices, XP, Vista and Windows 7. We use the XP VM's for Office training and the others for "introduction to the OS" courses.

Anyway, they are all using RDP. If a class on Office is run, using (say) 12 connections and each user logs off when done then the next class can log in as the same user(s) with no problems (Office on XP). Now, if a Vista or Windows 7 class is run using the same login ID's and those users log off, the only way I can get those desktops to become available again is to log in to each of them manually via direct RDP or the Vsphere console. They show up as READY in the View (4) Administrator pane but even using the "reset" option on the desktop sources (which does force them to reboot) does not allow the sources to become available.

View 4, ESX 4 U1. XP VM's work as intended, Windows 7 and Vista do not.

There MUST be something that is causing these VM's to think they are in use. Help is appreciated.

Chris

P.S. I've made sure they all have IP and can respond to a ping.

thranx · ‎02-08-2010

Any new news on this Full_Throttle? We've been dealing with this issue for quite a while (6 months)... I'm not our VMWare guy, so I'm not as well versed in the issue, but I've been trying to research a possible cause.

My working theory thus far is that if the user remains logged in after the auto-disconnect due to inactivity time window (a view setting as I understand it) it causes this problem. View doesn't appear to log the end user out when time expires so, to view, the machine appears occupied/in use even though the session between the client and the VM has been severed.

Anyhoo, just what I've observed, I'm very interested to hear any progress or discoveries you may have made.

Full_Throttle · ‎02-08-2010

Here is what I have found so far;

It happens with both RDP and PCoIP settings.

It happens even when we bypass the View client and connect directly to the VM with windows RDP.

When it happens, if you go to the console of the VM, the vm is "locked up", requiring a reboot.

Because of this, I suspect it is the agent itself.

I have had the session timeout set to 9999999 minutes, so we can eliminate the session timeout as the problem.

If my users just disconnect from the VM, it seems to work much better than if the reboot or reset the VM.

I had NO problems until I upgraded to View 4.0 and VSphere 4.0 using the 7.0 hardware devices.

The view connection broker was a fresh install, the Vsphere 4 was a fresh install. The view agent was completely uninstalled, then a reboot, vmtools upgrade, reboot, 7.0 hardware upgrade, reboot twice, view agent install. I think that was the order

I do not expect this to be resolved without a patch from VMware.

Mike

Full_Throttle · ‎07-29-2010

Well, here it is SEVERAL months later and we are still having these same, weird issues with no desktop sources available. I have tried everything I can think of. Does anyone have any input?? I have tried uninstalling the agent and the client and re-installing. The vm is pingable on the network but my broker seems to think it is not there....grrrrrr. a reset of the vm fixes the issue. All vms are using rdp.

Mike