Sometimes (far to often for my comfort) a writable volume is attached to a View pool member (Windows 7) and the VM will stall on connection. Horizon admin console shows that the status of the VM is still available, but shows multiple datastore attachments, which indicate a writable volume is attached.
At this point, there is nothing that I can do to detach the writable volume from this instance. If I try to reset the pool member, vcenter shows the error "<the writable volume> cannot be opened for writing. It might be shared with some other VM." and does not reset. I also have tried a refresh operation on that instance, but that doesn't proceed either (no error message with that one)
There doesn't seem to be a mechanism inside of the app volumes console to detach a writable volume. There is the delete option, but I don't want to lose user data by doing that.
I would like to deploy this feature because it shows promise, but not with this problem.
Does anybody have any ideas?
Update: after about 1/2 hour it finally did let go. Here's the relevant entries from the System Messages (read from the bottom):
|Jan 14 2015 10:20AM|
Last User Login already ended, no previous log record to match User Logout for User 3
|Jan 14 2015 10:20AM|
Removing attachments scheduled for removal in "Computer <XXXXXX\CADWS201$>"
|Jan 14 2015 10:20AM|
Computer "Computer <XXXXXX\CADWS201$>" went offline unexpectedly
|Jan 14 2015 09:50AM|
Timed out when loading assigned volumes, please retry or contact your administrator.
Normally, if a machine is shut down unexpectedly while an appstack is attached we just start up the machine so the Cloudvolumes Agent can contact the manager and is reconfigured right after that because the manager sees that no user is logged in at that point. Or isn't that hat you meant?
I must say that in previous releases we did see this issue and mostly with XD. We are now working with Horizon in conjunction with Appvolumes and haven't had that issue in a long time.
I think I've narrowed it down to repeat the steps to cause this.
If a View machine has been in the available state (i.e. on) for an extended period of time (at least a day or two) and is then used for a connection, the writable volumes are attached to it (any app stacks are also attached), but the login does not proceed and Horizon does not show it as a "connected" instance; it still just shows "available". In this case, the user just sees the "Welcome" screen and the spinning circle icon.
If the View machine is started from an "off" state, and immediately used for a connection, then the writable volumes attach and login proceeds normally.
Thank you for your efforts towards isolating the problem.Could you please provide more details about your environment as I am unable to reproduce the problem in-House.I can try your Setup please provide me the following details.
1)Vmware View Connection server Version
2)Broker Integration service Version
There are actually 2 versions oen which shipped with GA and hotpatch https://my.vmware.com/group/vmware/get-download?downloadGroup=AV25HOTPATCH
3)Horizon View Connection server
4)VMware view Agent Version
5)Version of Esxi(optional )
6)Storage Vendor (optional )
Connection server: 6.0.1-2088845
Broker integration service: none (The original didn't work and I didn't know about the hot patch. I will be applying that and testing)
View Agent: 6.0.2-2331487
ESXi: 5.5.0 2302651 and 5.5.0 1892794
storage vendor: Nimble
All of the attachments are driven by AD group membership. There are no computer level attachments.
I'm also running everything on Server 2012 R2. Apparently this is not the approved platform.
Since I have posted this problem, I have updated to the latest version of AppVolumes and also stopped using the appstack part of it. The reason for this is that, for my environment, the applications that I was trying to use through AppVolumes needed to install system level components (AutoCAD installs a font) that didn't work when installed via AppVolumes. So for the CAD workstations in this particular pool, I just decided to install all of the applications locally to the base image. As for the writable volumes part of AppVolumes, that is going great providing a place for the user profile.
I haven't ruled out going back to using AppVolumes for applications, depending on the situation. For any usage, I would recommend running on the latest version and strictly adhering to the compatibility specs. I was not doing this initially.
This is directly related to a known bug with 2.9. There is a 2.9.1 Hotpatch available form VMware support that will resolve this issue.
Please contact support directly and be sure to reference the 2.9.1. You will need to upload the logs for verification this is the issue but from the snipet here this is 99% going to be the fix.
I'm seeing the same thing. Running AppVol 2.10 on Windows 2012R2. The client desktop is Windows 7. I had creeated a non-persistent desktop, appstack and writable volume. I initially entitled a tser user to the appstack and writable volume. The user logged in via View client and successfully received the appstack and writable volume. I then unassigned the Appstack (immediately) and saw that it indeed unmounted from the desktop. I then rebooted the desktop. My expectation was that the desktop would come back up and I'd log in, with the appstack attached.
The desktop has come back but it's stuck at the Welcome screen with the spinning ball. It's been like this for a long time (over 20min). In View the desktop shows as "Available" and not Connected. In AppVol Manager I see the writable volume as "Attached" to the desktop.
This sounds similar to your issue. Was their a resolution? This seems very odd. It's the most basic operation with respect to adding a writable volume to a user's desktop.
Any update on this? I also have View 6.2.3, AppVolumes 2.10 on Windows 2012R2. VDI OS: Windows 7 64bit. I am seeing this exact symptom. ESX/vSphere 6.0 Update 2.
I am also getting this. The VM eventually has to be hard reset or powered off. With every release of this software, more bugs are introduced. Doesn't anyone test these products any more? It feels like we are drifting into Citrix territory, where all of the testing is done following the release.....
Same issue here mostly.
Horizon View 6.2.2
App Vols 2.10 installed on Win2012R2
All was working great (dev testing prior to going to PROD) until today. I did a recompose operation after I had updated the gold VDI image with the latest MS patches (June). After that AV has been acting weird.
1st VDI logon after recompose - app stacks worked but my writable volume (which shows as attached) was not working. All my data was not present. So I logoff and to my surprise AV did not detach my WV or App Stacks. I had to reboot the VDI and then the disks were released.
2nd VDI logon after recompose - All appeared fine, WV was working my data was showing up. I log off, again WV and App stacks don't detach. Had to force reboot the VDI machine to get it to detach.
At this point I rebooted the AV Manager - with my WV still attached. When AV manager came back up, it still shows my WV as attached!
Nothing at this point works to detach the volumes, I have to reboot the VDI.
What gives?? Why is AV not detaching the stacks and WV's anymore? It was working fine.
Anything in the logs I should look for? Tricks?
I supposed to pitch this to management to supplement our existing VDI platform but this is not giving me confidence. We aren't doing anything crazy with it either, just 5 app stacks with simple little applications like putty, firefox, vmware client, google chrome ect..we have 5 VDI machines that AV is deployed to. This is just a proof of concept test.