v2.9 and physical machine requirements

[Scott619]

We're excited to test AppVolumes v2.9 on a physical endpoint. However, the release notes say: "Operating System on the physical endpoint must be non-persistent, streamed, or both"

How do we meet this requirement? What technology/product is this referring to? Citrix PVS? Anybody?

[sappomannoz]

Hullo Scott,

I have tried it on PVS and it works. I know that windows embedded could be configured non persistent with the use of some filesystem  filters.

Cristiano

[Scott619]

Thanks for the input. It would be helpful if someone from VMWare could comment? PVS seems like the only option. Windows embedded won't work for a variety of reasons.

[Ray_handels]

NOT CITRIX!!! .

We've checked into this quite some time ago and Wyse/Dell has a system that could also do this. It is called Dell WSM i believe.

[sachindsharma]

Hi Scott, yes something like Citrix PVS or ILIO that streams the OS to the physical desktop is what's supported today.

[Jason_Marshall]

‌PVS would be ideal but not required. The key is that the OS should be non-persistent in some way. The reason is that any updates/writes to the OS are stored in basically a sandbox that is removed on each log out. So things like OS patches need to be scheduled and scripted with the App Volumes agent disabled to ensure the updates are applied correctly to the base OS.

You don't want a kernel level OS patch instantly ripped out from under the OS when a user logs out.. And then installed all over again when they log back in  

[Scott619]

Ray_handels: Correct, Wyse did/does make a product called WSM. AppVolumes (when it was CloudVolumes) actually did a cross promotion with them a little while back touting the physical delivery capabilities (virtualized server apps on a streamed OS to bare metal dell servers). That product has since been absorbed by the Dell vWorkspace suite. It is very similar to PVS. I'm pretty sure it also does some type of app layering as well now. However, I've never used it and I don't know of anyone with any experience using it in production.

Sachinasharma: Thanks for the confirmation. I think PVS and vWorkspace are the only products that can accomplish this today, correct? You mention ILIO but I'm not sure what that is (I used Atlantis ILIO but that's a SDS product). I do however know of another tiny company called Jentu that also has a PVS-style delivery mechanism but they are too small of a company to bother with.

Regardless, the solution for physical is now getting pretty complicated....PVS is the only real viable solution here givens it's popularity, support and community (well documented). Problem is I just can't see the ROI of Citrix licensing and AppVolumes licensing to accomplish this.

[Jason_Marshall]

"PVS is the only real viable solution here givens it's popularity, support and community (well documented). Problem is I just can't see the ROI of Citrix licensing and AppVolumes licensing to accomplish this."

True for now but keep in mind it is not required, look at my previous post. And we are working on making this better with Project A2.

Making Universal App Delivery and Device Management Real - VMware End-User Computing Blog - VMware B...

[Scott619]

Jason - sorry, didn't realize you were VMWare employee. So if I deploy an OS normally (not streamed) and just withhold patches, this scenario is supported? I guess I'm confused on what VMWare will "officially" support. Let's forget about "streamed" since it's optional. The release notes say "non-persistent". I guess I'm not sure how to accomplish this w/out PVS....

I understand what you are saying in your example - writes (including Win. updates) will go into UIA layer. What if the user was non-admin on the box?

I did see the announcement regarding A2. I'm excited to see how this progresses but I'm not excited at the cost of licensing both products to accomplish this.

[Jason_Marshall]

You wont have to have both products

The real key to being successful with App Volumes and physical is to understand that writes will go into a sandbox and be blown away on a logoff or in the Writable volume if used and ripped out and plugged back in on ever log out/in. Once you understand that it gets a little easier. It basically means that your physical devices need to be highly managed. As an example, I have SCCM to update a virus def and an OS patch. No problem now that I know all this "stuff" this is happening in the background. I either schedule it and detach all volumes from devices with an unassign and log off or I add a little bit to my SCCM script.

net stop svservice

net stop svdriver

updatewhatever.bat

shutdown /r

Little oversimplified I know but the main point is highly manage and lock down the end points and you will be golden. And yes we have customers doing this today, a couple quite large..