Isolation and State Separation
Isolation and State Separation are two very important concepts in the world of application virtualization, but we throw those terms around a lot without really explaining what we mean by them. I’m going to attempt to explain what those concepts mean to us and the roles they play with application virtualization. I will dive pretty deeply into some technical details to explain this, especially the isolation part, so hang on and let’s go for a ride.
When we talk about isolation, we’re talking about hiding all of an application’s resources from everything else on the system. So for example, if the app has a file on disk, or a value in the registry, or a COM object registered, only processes running inside the app’s “bubble” (a.k.a. “virtual environment”) can see the file, value, COM object, etc.. This is a core feature of the desktop Application Virtualization product, but when we built the Server App-V product on top of the desktop product, we significantly relaxed this isolation. Apps do still run in a bubble, but the bubble is much more permeable.
One of the most significant changes from the desktop is that the application’s files on the file system drive (generally the Q: drive) are visible to everything else running on the system, as if the app were natively installed. They can be protected by file permissions just like any other app’s files, but there is no explicit hiding of these files as we do in the desktop product.
Another significant change is that we register more extensibility points in Server App-V than the desktop product does. In the desktop product, we only register file type associations and shortcuts. We still register those in Server App-V, though they are not as useful or common in server apps, but we have added more. We register NT services, IIS applications and sites, WMI components, and COM/COM+/DCOM objects with the appropriate components in the local system. To give a quick example, if an application includes an NT service, we register this service with the native Service Control Manager, so you can control the virtualized service just like you control natively-installed services (from the Services MMC snap-in or using PowerShell cmdlets like Start-Service and Stop-Service, for example). This also enables scenarios like the SCM automatically starting the virtualized service when the machine boots. I won’t dive any deeper into our integrations with the SCM, IIS, etc. in this post; suffice it to say that we expose a lot of stuff outside the bubble than we did on the desktop.
A third change we made to relax isolation is that we turned off the isolation of named objects (pipes, memory mapped files, mutexes, etc.). With Server App-V, if two applications are using any of these objects to communicate, the bubble won’t get in the way. For those of you very familiar with the desktop App-V product, this is similar to turning on ALLOW_LOCAL_INTERACTION on the desktop.
We have not completely removed all the isolation present in the desktop App-V product. One thing that we still isolate is the registry. Except for a handful of things we explicitly export (like service registrations), any registry keys and values that an app creates remain private to that app. We did not change this behavior from the desktop product.
File system mappings are also kept within an app’s bubble. As in the desktop App-V product, when an application expects to find a file on the C: drive but the file only exists under Q: (or whatever your system drive and the App-V file system drive are called), App-V redirects the application’s request on the fly, mapping a path like C:\Program Files\MyApp\foo.dll to Q:\MyPackage\VFS\CSIDL_PROGRAM_FILES\MyApp\foo.dll. These mappings are only available to processes running inside the bubble. Note that it’s only the mappings that are private—the actual files on Q: are accessible to all processes.
What does this set of isolation-related changes imply? Unlike the desktop product, if two applications cannot coexist natively on a single machine, they generally still won’t be able to coexist under Server App-V. And in fact, we decided not to support multi-tenancy at all for Server App-V 1.0, except in the case of IIS applications that can coexist natively.
Some of you might be wondering why we diverged from the desktop product like this. On the desktop, there are a lot of scenarios where strong isolation is helpful. Running apps side-by-side that would normally conflict is a very common App-V scenario in the desktop world. In fact, the initial uptake of App-V (way back before it was called App-V or owned by Microsoft) was largely driven by companies that wanted to be able to run conflicting apps together on Citrix servers rather than having separate “silos” to avoid conflicts, allowing them to have fewer total pieces of hardware to buy and manage. But when we looked at server apps in datacenters, we didn’t see as much value in the scenario. Outside of web apps, customers told us they generally run one app per VM, citing availability, performance, and security among other reasons.
On the flip side, isolation was hurting us because it meant that applications were hidden, not just from each other and from the OS but also from all the tools that have been built to manage them. So relaxing that isolation allows a lot of existing tooling to keep working without modification. When we weighed the pros and cons of app isolation in the datacenter, we decided that we’d be better off letting server apps be more integrated and visible, so we made the changes I described to turn off a lot of the isolation supported by desktop App-V.
That was a lot to digest, but as I mentioned at the top, there are actually two topics I wanted to cover together. This brings us to…
State separation is a feature of both the desktop Application Virtualization product and Server App-V. “State” refers to any changes the application makes to the native system while it is running, like a log file it writes or a registry value it updates. So “state separation” means we’ve found a way to separate an application’s state from other things that are changing on the system, unrelated to the app. When an app (or something acting on its behalf, like a WMI provider) makes a change to a resource, we keep track of it. In Server App-V, we don’t always isolate it from other apps or from the OS—those other entities can see some of the changes that are made—but we do keep track.
Why is state separation important in the datacenter? When it’s time to move an app to a different machine, since we know what changes are part of the app’s state and which ones aren’t, we can lift up the app’s state and take it along! Separation of application state is a very powerful feature of Microsoft’s application virtualization products. It enables scenarios like a backup, a repair, a move to a patched OS, a move to different hardware, and some fundamental cloud management operations.
To give a more concrete example, let’s imagine I have a web app that implements a blog, or maybe a forum—something where people can post blocks of text and others can comment on them. Let’s call it a blorum . I virtualize my blorum and have it running on a server. But my blorum becomes immensely popular and I want to move it to a more powerful server. Without Server App-V, I could install the software on my new hardware, then scrape around the old machine and try to find whatever blog posts or forum discussions people created and somehow copy them all to the new machine. Maybe the blorum happens to support some kind of export/import functionality for this scenario… or maybe it doesn’t (uh oh). With Server App-V, I don’t have to worry. I back up the state of the blorum on the old machine, deploy the blorum to the new machine, and restore the state there. Server App-V figures out what was important to include in that backup/restore and what wasn’t—all the blog posts and forum discussions along with any configuration changes I made to the blorum come along to the new machine.
Isolation, the ability to keep an app’s resources hidden from other apps and the system, is a great feature in the desktop App-V product, but we decided the cons outweighed the pros in the datacenter so it is mostly removed from Server App-V. State separation, however, is an incredibly important feature of Server App-V that allows you to back up, move, and restore an app’s state instead of having to start over when you deploy. I hope this article helps clarify those concepts and why we included one as a feature of Server App-V and not the other.
Eric Jewart, Principal Development Lead, Server App-V