Lieven
Hot Shot
Hot Shot

Writable volumes not detaching and impossible to login to the VDI on 2nd attach

I have an environment with VMware View 6.1.1 linked clones and appvolumes 2.9.

Applications are delivered through Appvolumes appstacks

Users can install applications through Appvolumes writable volumes ((UIA_ONLY)

User profiles are being handled by Persona Management.

When I assign a writable volume to a user and the user logs in to Horizon View, the user gets assigned a VDI from the pool, the writable volume and other appstacks are being attached to the assigned VD, the logon occurs and the user can install applications. So no problem there.

When the user logs out of the VDI, the writable volume and appstack volumes are not being detached automatically. I then detach the appstacks and writable volume manually (via the vSphere client) and delete the desktop.

When the same user logs again in to Horizon View, he gets assigned a VDI from the linked clone pool, writable volume (UIA_ONLY) and other appstacks are being attached to the assigned VDI, but the VDI itself displays the message "Please wait for the App Volumes Service" and the logon process does not finish.

This situation only occurs when users are assigned a writable volume and does not occur when users are assigned only appstacks.

Enabling or disabling the option "Prevent user login if writable is in use on another computer" does not have any effect on resolving the problem.

38 Replies
Ray_handels
Virtuoso
Virtuoso

Have you ever received an answer from support?

We do not have that issue now but I'm not quite sure if you have the exact same setup as we have.

0 Kudos
Lieven
Hot Shot
Hot Shot

No answer from support yet? They are "working on it". It's very frustrating.

0 Kudos
Lieven
Hot Shot
Hot Shot

I'll try to discuss at VMworld Barcelona next month with the product Manager. Are you going to VMworld?

0 Kudos
Lieven
Hot Shot
Hot Shot

Support asked us now to change the registry setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\svservice\Parameters\RebootAfterDetach from 0 to 1

We tested this out but it did not work 😞

Now we're waiting again for support to call us and help us out. I have however the impression that they are doing trial and error with different settings.

0 Kudos
Ray_handels
Virtuoso
Virtuoso

As far as my knowledge goes, rebootafterdetach is useless if you have refres immediatly configured, it does exactly the same thing.

The only reason you would like to this is for as far as i'm aware is due to a timing issue.

I'm very surprised though that you have this issue. You only have the writable volumes at 1 datastore??

0 Kudos
Lieven
Hot Shot
Hot Shot

yes, we have a single dedicated datastore for writable volumes (and the template)

0 Kudos
Lieven
Hot Shot
Hot Shot

There's now a new Support Engineer working on the Support Case at VMware (SR# 15722287707). He is in contact with engineering and is waiting for a response from them.

0 Kudos
Jason_Marshall
VMware Employee
VMware Employee

‌Currently tracking this issue with a few customers and a possible hotfix will be coming in the next few weeks. Will post here when we have a release candidate to share.

0 Kudos
iforbes
Hot Shot
Hot Shot

Hi. Is there any resolution to this annoying issue? I'm seeing exactly the same things.

0 Kudos
aRJayL
Contributor
Contributor

Any updates from Vmware or anyone find a workaround.  Same exact issue using AppVol 2.10

0 Kudos
nuberaldhoore
Enthusiast
Enthusiast

We did not get any resolution from VMware on our case regarding this problem (Case # 15722287707) and the case was closed.

Because of the many bugs in version 2.x of AppVolumes we discovered and the lack of good support from VMware for this product, the end-customer decided to stop all together with AppVolumes 2.x. They are now running full clone machines. Not the ideal solution, not the cheapest solution, but at least it works.

I am now testing version 3.0 in my lab. Hopefully there will be less bugs in this version. Unfortunately there is no upgrade possibility from 2.x to 3.0. It's rip and replace + recreate all the appstacks.

0 Kudos
Smoke14
Hot Shot
Hot Shot

Why is everyone wanting to use WV's when they are not the best solution and bugging?

I use UEM or Persona Management.to handle the Users Profile & Configurations.

Mike_A
aRJayL
Contributor
Contributor

I have a brand new install and have the ability to rip and go right to 3.0  have you seen many issues with 3.0?

0 Kudos
aRJayL
Contributor
Contributor

Hot off the presses:  We are using 2.10 and experienced the same issue identified in this thread.  Opened a ticket and Shaun from VMWare was great!  We performed some cleanup and applied a couple Microsoft Hotfixes

1.  Remove any hidden network cards from your Golden image (we had 1 from the way we spun the VM up originally)  devmgr_show_nonpresent_devices=1    Shaun mentioned uneeded or hidden network cards on your Golden image can cause delays during login on the VDI

2.  Install MS Hotfix KB2550978    https://support.microsoft.com/en-us/kb/2550978     (Best practices if using VMXNET3 adapters for your VDI's)

3.  Install MS Hotfix 2614892      https://support.microsoft.com/en-us/kb/2614892 ‌    this the fix Shaun said fixed the issue we were experiencing in 2.10


NOTE:  If you are using 2.9, Shaun did mention there is a know issue with AppVol not dismouting the writable during loggoff and there is a different fix/update for that condition (although identical locking during logon seen as my issue)


Reference SR#169602332204


Hope this helps!

LFC
Enthusiast
Enthusiast

Hello aRJayL

Thank you very much for the information. We have had this issue affecting our Horizon 6.22 solution for almost 3 weeks now. We have rebuilt pretty much every component of the solution, including the vSAN, Connection Servers, UEM solution and AppVolumes 2.9 and 2.10 servers multiple times.

We have also rebuilt out Windows 7 images multiple times, installing agents in varying different methods and orders. TBH it been an absolute nighmare, and VMware Technical Support have struggled to find a solution despite taking lots of logs and quite a few remote sesisons to our systems.

Finally, last night, I added the 2 x Windows hot-fixes to our build script and added 2 x registry keys suggested by VMware for AppVolumes, then recomposed our Linked Clone Pools. Today we have not had a single session hang at logon - the first clear day for two weeks.

Regards,

Sean

0 Kudos
cyberfed2727
Enthusiast
Enthusiast

So what were the changes exactly that worked for you?

I already have the two MS hot fixes on my VDIs + Gold image.

AV 2.10  on Win2012R2

Win7 - VDI

Same issue for us. Everything was working great (we are doing a test pilot) until today. WV's are not being detached (or App stacks for that matter) upon logoff. I have to reboot the VDI to get the disks to detach. This all started after I applied June MS updates to the gold VDI image and recomposed.

Can't go to AV 3.0 because our vSphere environment is still 5.5

0 Kudos
nuberaldhoore
Enthusiast
Enthusiast

Don't go to AppVolumes 3.0. App volumes 3.0 is not foreseen for on-premises installations.

See http://ituda.com/vmware-appvolumes-vmwares-strategy-for-version-2-x-and-3-x/ for more explanation

0 Kudos
cyberfed2727
Enthusiast
Enthusiast

Well today all 5 of our test users had issues with their WV's and things not detaching and working correctly.

We ended up scrapping 2.10 and started fresh with 2.11. I'll let you know in a few days how its holding up.

0 Kudos
hockeyguyin714
VMware Employee
VMware Employee

I would recommend checking to see if the user is actually logged off by checking Windows Events. You maybe having a hung session issue.

0 Kudos