Containers in VDI Environments: When It Helps, When It Doesn't

"Containerized VDI" is one of those phrases that sounds modern and ends up meaning five different things depending on who's talking. For some vendors it means the Windows desktop OS itself running in a container. For others it means application delivery via App Layering, MSIX app attach, or FSLogix app containers. For others still it means running the VDI control plane — brokers, gateways, management services — on Kubernetes. Each of these is a real thing, each solves different problems, and some of them are worth doing. Here's our take, based on deploying all of them in production.

The Four Places Containers Show Up in VDI

1. Application layering and attach

This is by far the most common and most valuable use of "container" concepts in VDI. Instead of baking every application into the golden image — which means every image update requires repackaging everything — you deliver applications as separate containers that attach to the desktop at login.

Microsoft MSIX app attach is the Microsoft-native version. Applications get packaged as MSIX bundles, stored on a file share, and attached as virtual disks when the user logs in. FSLogix application containers (older, still supported) do the same thing via VHD/VHDX files. Citrix App Layering and Omnissa App Volumes are the mature, more capable commercial versions — they handle more application edge cases, support more packaging methods, and scale to larger environments.

This pattern is worth the effort. The golden image becomes small, stable, and changes rarely. Applications update independently without rebuilding the image. Different user groups see different applications on the same base desktop. Image rebuild times drop from hours to minutes.

The catch: packaging applications for layered delivery is real work, some applications never quite behave (we're looking at you, apps that write to Program Files at runtime, or apps with kernel drivers, or apps that register COM components in odd places), and troubleshooting a broken layer is harder than troubleshooting a broken install.

When it helps: any environment with more than about 15 applications in the image, especially if those applications update on different cadences or if different user groups need different subsets.

When it doesn't: small environments with a handful of stable applications. The overhead isn't worth it.

2. Profile containers

FSLogix profile containers are technically a container too — they wrap the user's profile in a VHDX that attaches at login. This is not optional in 2022. If you're running non-persistent VDI with Office 365 and you're not using FSLogix (or the equivalent in Citrix Profile Management or Omnissa DEM), you are doing it wrong, full stop. Cached Exchange mode, OneDrive, Teams, and Outlook search index all expect a persistent profile with fast local-disk semantics.

FSLogix gives you that by mounting the profile as a container from an SMB or CIFS share. It works. It has its quirks — bloat over time, concurrent access conflicts, storage tier sensitivity — but it works.

When it helps: always. This is the de facto standard.

When it doesn't: effectively never, for non-persistent Windows VDI with Microsoft 365.

3. Containerizing the VDI control plane

Running brokers, gateways, monitoring, and management services on Kubernetes is an idea that's been talked about for years and is finally shipping in real products. Omnissa (and VMware before the spinout) has been moving control plane services to containerized, cloud-native deployment. Citrix is moving in the same direction with Citrix Cloud. Microsoft's AVD control plane is already fully managed and cloud-native from the user's perspective.

Is this useful for your deployment? Probably not yet. The benefits are operational — easier upgrades, better resilience, simpler scaling — and they mostly matter for organizations running multiple VDI pods across regions. If you have a single site with a few thousand users, running the brokers on plain Windows Server is still simpler and well understood. Kubernetes adds an ops skill set that your VDI team may not have.

When it helps: large, multi-site deployments where control plane resilience and rolling upgrades are genuinely painful today.

When it doesn't: single-site, mid-market environments. Don't add Kubernetes to simplify VDI. It won't.

4. The Windows desktop itself in a container

This is the idea that sounds exciting and mostly isn't — yet. Projects to run Windows desktops inside containers (as opposed to VMs) promise faster provisioning and higher density. Some vendors have shipped early versions. In our testing, the density gains are modest, the isolation guarantees are weaker than VM-based VDI, and the compatibility surface is smaller.

For most organizations this is not production-ready for their primary user fleet. It may be the right call for specific use cases — throwaway lab desktops, specific stateless kiosk workloads, high-density task worker scenarios — but it isn't replacing your main VDI pool in 2022. Keep an eye on it. Don't bet the project on it.

When it helps: very large task-worker deployments where every percent of density matters, in specific pilot scenarios.

When it doesn't: general purpose user populations, anything with a serious application portfolio.

What Actually Happens in a Good Deployment

A well-built VDI environment in 2022 typically looks like this:

• Brokers and management services on Windows Server VMs, maybe clustered, maybe in an HA pair, not containerized.
• Session hosts as Windows Server VMs on a hypervisor, running either a single-session client OS (Windows 10/11 Enterprise) or multi-session (Windows 11 Multi-Session on AVD, RDSH on others).
• A lean golden image containing the OS, the agent (FSLogix, Citrix VDA, Horizon agent, whichever), and a short list of always-on applications.
• Applications delivered via MSIX app attach, App Layering, or App Volumes — each user group sees the apps they need and nothing else.
• Profiles in FSLogix containers on fast SMB storage with careful sizing and monitoring.
• No Kubernetes anywhere unless the team already runs Kubernetes for other reasons and the VDI control plane fits a platform strategy.

The "containerization" in this stack is real — profile containers, application containers, MSIX — but it's invisible to users and almost invisible to operations after the initial setup. That's the point. Good infrastructure is boring.

Where We See People Get This Wrong

Over-containerizing. Packaging every tiny utility as its own MSIX layer because layering is cool. The overhead of managing 80 layers exceeds the overhead of having 40 things in the base image. Keep the base image reasonable and layer the things that actually change independently.

Under-containerizing. Still running a giant, monolithic golden image with 60 applications baked in, and rebuilding it every time one app updates. This is 2014 VDI. Upgrade your packaging strategy before your image.

Confusing app virtualization with containers. App-V (older) and ThinApp (deprecated) were application virtualization, a different technology with different trade-offs. MSIX app attach, FSLogix app containers, and modern layering are the current state of the art. Don't revive App-V for new deployments.

Treating Kubernetes as a goal instead of a tool. If your VDI team is spending more time on Kubernetes than on users, you're optimizing the wrong thing.

Three Takeaways

1. Layered application delivery is the container pattern that matters. MSIX, App Volumes, App Layering — pick one, commit to it, train the team. The payoff in image agility is huge.
2. FSLogix profile containers are mandatory, not optional. If you're not using them, fix that before anything else on this list.
3. Don't containerize infrastructure for its own sake. Boring, well-understood VM-based infrastructure is still the right answer for most VDI control planes. Use Kubernetes when you have a Kubernetes reason.