VMware Horizon Community
laustintime
Contributor
Contributor

Writable volumes not letting go

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.

16 Replies
Ray_handels
Virtuoso
Virtuoso

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.

laustintime
Contributor
Contributor

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.

Reply
0 Kudos
Gaurav_Baghla
VMware Employee
VMware Employee

@laustintime

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 )

Regards Gaurav Baghla Opinions are my own and not the views of my employer. https://twitter.com/garry_14
Reply
0 Kudos
laustintime
Contributor
Contributor

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

Reply
0 Kudos
Gaurav_Baghla
VMware Employee
VMware Employee

Do you have attachments at computer level as well ?

Regards Gaurav Baghla Opinions are my own and not the views of my employer. https://twitter.com/garry_14
Reply
0 Kudos
laustintime
Contributor
Contributor

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.

Reply
0 Kudos
bv_vfd_11
Contributor
Contributor

Any update on this issue??? We are seeing the same issue. !

Reply
0 Kudos
laustintime
Contributor
Contributor

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.

Reply
0 Kudos
JHarper76
Contributor
Contributor

Hey. I just saw this line of events today. We only use the App Volumes portion. Is there any rhyme or reason to this?

Reply
0 Kudos
Jason_Marshall
VMware Employee
VMware Employee

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.

Reply
0 Kudos
iforbes
Hot Shot
Hot Shot

Hi laustintime,

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.

DanielLineberry
Contributor
Contributor

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.

Daniel Lineberry | Senior Engineer Office: 210-918 9522 dan.lineberry@siriuscom.com Sirius Computer Solutions | www.siriuscom.com
Reply
0 Kudos
LFC
Enthusiast
Enthusiast

All

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.....

Reply
0 Kudos
VDIMega
Enthusiast
Enthusiast

I was having this problem once/twice per week I was using View 6.0.2.  On View 6.2.1 now for a month, I have not had this problem even once.

Reply
0 Kudos
cyberfed2727
Enthusiast
Enthusiast

Same issue here mostly.

Horizon View 6.2.2

App Vols 2.10 installed on Win2012R2

Win7 VDI

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.

Reply
0 Kudos
hockeyguyin714
VMware Employee
VMware Employee

I would make sure you have http://kb.vmware.com/kb/2145119 installed on your VDI pool. 

Reply
0 Kudos