Can (should?) an existing writable volume be upgraded to a new template when upgrading App Volumes Manager?

[rcscott44]

We just upgraded to 2.13.2 from a clean install of 2.13.1.  We did this to resolve the Error 500 on connection bug.  Now we are having issues with users getting a consistent black screen when disconnecting from one terminal and connecting to another.   We upgraded the AppVol Manager and the AppVol agent on all our Instant Clone (non-persistent) desktops, however we did nothing to the existing AppStacks and Writable volumes.  I have uploaded the new templates to our datastores, but all existing volumes are running on 2.13.1 templates.

Is there any way to upgrade the Writable Volumes without deleting and starting over?

-Bob Scott

[Lakshman]

Yes, please have a look here:

Update Writable Volumes

[pchapman]

I suggest being extremely careful in your decision to enable that feature.  Once you start using it there is no way to turn it off.  You also can't choose to update only certain writables - this setting applies to all.

[rcscott44]

When you say it can't be turned off, do you mean it will even be applied to every new writeable created after we push the update?  I understand it is applied to every existing writable when we run an update and that is what we want.  However, I don't want it to be applied to future writeables we create in the future.  I am hoping the update is a one-time event.  We are doing this to update the snapvol.cfg file on existing writable volumes to match the templates for 2.13.2.  If the update applies to all future disks, then when we eventually need to go to 3.x (or 2.14.x) the new writable template will be automatically downgraded by this .zip upgrade. 

[pchapman]

Yes, it will get applied to everything, even after the update.

I suggest the following:

Evaluate the differences in the new snapvol.cfg and determine if the changes truly warrant upgrading the existing writables.

If they do, either delete all writables and re-create them with the new template, or manually replace the snapvol.cfg/related files in your existing template.  That option is much more labor intensive but could definitely be automated with a script of some sort...

It is not an elegant solution, but I'm open to hearing other ideas.  I did use the "update writables" option in one environment but it is not ideal.  For example, I'd like to maintain a different writable template with a test snapvol.cfg that has changes to it, but I can't anymore, because ALL writables get overwritten by whatever's in the zip file.

[rcscott44 · Accepted solution]

We have decided to move forward with the update procedure for the writeable volumes via .zip file.  Once we have ensured that all our existing writeables have received the update, we will then load a new .zip with a blank .txt file.  That overwrites the .zip with the snapvol.cfg update and ensures new writables after that do not get an outdated snapvol.cfg in the future.  Clearly not the ideal, but way less impacting to end users than having to rebuild their writable completely.  We use writables w/user profile, so it would create a lot of grief. This method was confirmed by VMware as the only current way to make sure n update stops being used.

So far the new snapvol.cfg seems to be updating as expected.

I will add that if you move from 2.13.1 to 2.13.2 to fix any "error 500" issues at logon or black screens after disconnect / reconnect (both listed as resolved issues for 2.13.2) You will definitely need to update any existing writables.  The issues actually got worse when we only updated the AppVolumes Manager and Agent in the Instant Clone master image.   Updating the writable seems to solve the issue.

-Bob