I just wanted to share an issue I experienced with app volumes causing data loss on a persistent desktop last week.
I had deployed SQL management studio to 100 persistent developer desktops running win7sp1 and app volumes 2.7.
I started receiving calls stating files where missing and performance was very slow.
Upon investigation I found I could recreate the issue by creating folders on the root of c: then remove the assigned app stack. This would cause the new folders/files to disappear. Not good when most of your developers keep source code on the root of c: and their local SQL express databases disappear.
After rolling everything back by removing the app stack and disabling the agent this also caused any new files created after deploying app stack to be removed.Similar to reverting a snapshot.
I was burned big time by this product....
I set up a WebEx and demonstrated the issue to an app volumes tech support VMware engineer. Rolling back the agent to 2.5.2 did not help.
The case has been escalated.
My advice be very careful deploying this product on a persistent desktop.
We are seeing this to in our environment using persistent desktops using App Volumes Agent 22.214.171.1243. If we unattached the AppStacks and install applications or modify C:\ the changes stick but while AppStacks are mounted, changes don't survive a reboot.
This is expected behavior. This is the reason for the Writable Volume to capture user data and changes. App Volumes is currently designed for a stateless environment and will in essence make any persistent environment act as though it is stateless unless a Writable Volume is used. It will not be until A^ is launched that we will be able to fully support persistent environments.
Developer desktops is probably the #1 use case for App Volumes today but it is always in a stateless environment so that you can take the advantages of stateless to a traditionally persistent set up. Basically giving persistent look and feel to the end user but keeping OS stateless.
Not sure why tech support would have recommended rolling back. They have been instructed on this and should be a KB on it as well. Do you have the SR#?
I don't fully agree with you on that one Jason. We also have more than this developer usecase for our enviornment.
Normally the techsupport doesn't want to manage a bundle of different solutions and because personalisation is a buzzz word these days i don't think there are that many tools that can do what Appvolumes does now. Easy applications delivery, if needed personalisation (in the same management enviornment) and SBC like desktops if needed in the same enviornment. For us it's a one stop shop tool.
Yes thre are several different use cases out there but developer desktop is #1 that we see.
And to be fair we are building the solution in a direction of persistent and non-persistent to address more use cases. A^ is the result of that direction
I 100% agree with Andrew. App Volumes has been marketed as an application layering technology for View desktops. It doesn't state anywhere that it should just be used for non persistent desktops, along with either writable volumes or some UEM product. There are many reasons that we might have to deploy persistent desktops to some use cases, and the hope was that App Volumes would provide a nice app deploymentioned tool.
Now it sounds like it's not a tool to deploy apps to persistent desktops without potential issues like this. Does 2.10 resolve this issue or are we in the same boat when using persistent desktops? There will be times when we need to remove an app from the Appstack and don't want to possibly lose data