How Virtual Desktops Actually Work: Six Things the Datasheets Skip

Most "how VDI works" articles stop at "there is a server in a data center and a protocol to the endpoint." That is technically correct and completely useless if you are trying to design, troubleshoot, or size a real deployment. Here is how it actually works, in the order that things happen from the moment a user double-clicks an icon, with the pieces that cause real outages called out explicitly.

The Happy Path in Order

When the user clicks the icon on their endpoint, the first thing that happens is the client software — Citrix Workspace, Horizon Client, Windows App, whatever — reaches out to a connection broker. The broker is the traffic cop of the whole system. It authenticates the user, checks which pools or published desktops they are entitled to, decides which host in which pool has capacity, and returns a ticket that tells the client where to go.

The client then opens a second connection, usually through a gateway appliance, to the actual virtual desktop. That connection carries the display protocol. Depending on the stack, this is ICA or HDX (Citrix), PCoIP or Blast (Omnissa, formerly VMware), or RDP with RemoteFX or AVD-flavored extensions (Microsoft). The display protocol takes the screen output, compresses it, and ships it to the client; the client ships keyboard, mouse, audio, USB redirection, and printer traffic back the other way.

Inside the virtual desktop, the operating system boots (or has already booted), the user's profile loads, applications launch, and the session is live. When the user logs off, the session tears down, any profile changes get written back to a profile container, and depending on whether the pool is persistent or non-persistent, the VM either stays as-is or gets reset.

That is the thirty-second version. Here are six things the datasheets do not tell you about.

1. The Broker Is a Single Point of Pain

The connection broker is not a single point of failure because you will obviously cluster it. But it is a single point of pain. Every login, every reconnection, every pool refresh goes through it. If the broker's database is slow, logins are slow. If the broker cannot reach Active Directory, nobody can log in. If the broker cannot reach the hypervisor API, new sessions cannot start.

We have seen more VDI incidents caused by broker-to-AD latency, broker database corruption, or broker-to-hypervisor API rate limiting than by any actual infrastructure failure. When you size your broker tier, do not just size it for concurrent sessions. Size it for login storms — the moment at 9 a.m. when 2,000 people try to log in at once. That is the pattern that breaks under-provisioned brokers.

2. The Display Protocol Is a Codec, Not Magic

The display protocol is not sending you pixels. It is sending you a compressed video stream with sideband data for keyboard, mouse, and peripherals. The compression is adaptive — it gets more aggressive when bandwidth is tight and more generous when bandwidth is abundant. What that means in practice is that protocol tuning is a real skill.

For a typical office worker on a low-motion desktop, you need 150 to 300 kbps of bandwidth and you will not notice anything. For a user watching a video or scrolling through Teams with lots of motion, you need 1 to 3 Mbps and it had better be low-latency. For a graphics user with AutoCAD or Adobe Premiere, you need a GPU in the host, a properly tuned codec, and 5 to 15 Mbps. People who say "VDI feels slow" are almost always experiencing protocol misconfiguration or insufficient bandwidth, not underpowered VMs.

3. Profile Management Is the Actual Hard Part

The VM is the easy part. The profile is the hard part. When a user logs in, their personal settings, documents, Outlook cache, browser profile, and application preferences have to get from wherever they live onto the VM in under thirty seconds. If the profile lives on a slow SMB share, if the cache is enormous, or if the profile container contains corruption from the last session, logins are slow or broken.

FSLogix (Microsoft's profile container solution, included with most Microsoft 365 subscriptions) is the de facto standard now. It works well when it is sized and tuned properly. It falls over spectacularly when you put the profile containers on slow storage, when you do not exclude the right paths from antivirus scanning, and when you do not plan for the OneDrive cache to grow larger than the container can hold. Every profile management tool has these same failure modes.

4. Application Delivery Is a Separate Problem

In a non-persistent VDI world, applications either live in the golden image (fine for Office, terrible for anything you patch frequently) or they get delivered at logon via layering (App Volumes, FSLogix App Masking, MSIX App Attach). Layering is how you deliver a hundred different application combinations from a single golden image.

Layering is also how you run into licensing lawyers and application compatibility demons. Not every app layers cleanly. Some apps assume they are installed locally and will not run if their registry keys arrive mid-session. Some apps have licensing tied to the MAC address of the host, which changes every time the user lands on a different VM. Plan to spend real time testing every application in your portfolio, not just the first ten.

5. GPU Matters More Than You Think

Modern Windows is a graphics-accelerated operating system. Even without 3D applications, Teams, Chrome, Edge, Office, PDF readers, and the Windows shell itself all use GPU acceleration now. Running a VDI host without any GPU works, but it pushes graphics rendering onto the CPU, and the user experience is noticeably worse.

For office workloads, a shared GPU (NVIDIA vGPU, or the AMD equivalent) with 1 GB of framebuffer per user is the modern baseline. For graphics workloads, 4 to 8 GB per user and a serious GPU is the minimum. If you are building new VDI hosts in 2023 without GPUs, you are building yesterday's architecture.

6. The Endpoint Matters as Much as the Host

You can put the world's fastest infrastructure behind a thin client with a 100 Mbps NIC and a 4K monitor, and the experience will still be bad. Endpoints need enough CPU to decode the display protocol at 60 frames per second, enough RAM to run the client, and enough network to carry the bidirectional stream. Cheap endpoints on cheap networks are false economy.

The good news is that a five-year-old laptop or a modern thin client is almost always sufficient. The bad news is that the oldest endpoint in your fleet is often the one owned by the loudest complainer.

Three Takeaways

1. The broker, profile, and display protocol are where real outages live. Infrastructure problems get the blame, but tune these three first.
2. Bandwidth and latency to the endpoint are a real constraint and cannot be engineered around. Pick a display protocol and tune it for your actual network.
3. Graphics acceleration is not optional anymore. Plan for a GPU in every host unless you want a user experience that feels a decade old.