
A VDI server is the physical or virtual server that hosts virtual desktops and delivers them to end users over a network. It runs the hypervisor, holds the desktop images, and supplies the processor cycles, memory, and storage that every user session consumes. In a Virtual Desktop Infrastructure (VDI) deployment, the server is where the desktops actually live.
The device on someone’s desk shows a screen and sends back keystrokes. Everything else happens on the server.
That distinction matters more than it sounds. Most VDI projects that go badly do so because the server layer was sized for the wrong workload, not because the software was wrong.
This page covers the server and infrastructure layer specifically. For the concept from the ground up, including persistent versus non-persistent desktops and display protocols, start with what VDI is and how it works.
A VDI server performs three jobs at once: it virtualizes hardware, hosts operating systems, and brokers user connections to the right desktop.
Start with the hypervisor. It divides the physical machine into virtual machines, each with its own allocation of virtual CPUs (vCPUs), memory, and disk. Those virtual machines run Windows® or Linux and become the desktops your users see.
Then there’s the brokering. When someone logs in, something has to decide which desktop they get, whether it already exists, and whether they are allowed to have it. That decision happens on the server side, not the client.
Storage is the third job and the one people underestimate. User profiles, application data, and the desktop images themselves all sit somewhere. If that somewhere is a slow shared disk, every user feels it at 9 AM when forty people log in at the same time.
A single physical box rarely does all of this alone. In practice, a VDI server refers to a stack of roles, sometimes spread across several machines.
| Component | What it does | Common implementations |
|---|---|---|
| Hypervisor host | Runs the virtual machines that become desktops | VMware ESXi, Microsoft® Hyper-V®, Citrix Hypervisor, Proxmox VE |
| Connection broker | Authenticates users and assigns each one a desktop or session | Citrix Delivery Controller, Omnissa Horizon Connection Server, RD Connection Broker |
| Session host | The Windows instance users log into, single-session or multi-session | Windows Server® with RDSH, Windows 11 Enterprise multi-session |
| Profile and storage layer | Keeps user data and settings separate from the desktop image | FSLogix, roaming profiles, NVMe or SAN storage |
| Gateway | Handles encrypted access from outside the corporate network | RD Gateway, Citrix Gateway, Unified Access Gateway |
| Management plane | Image updates, provisioning, monitoring, license tracking | vCenter, Citrix Studio, RDS Manager |
Small deployments collapse several of these roles onto one server. Larger ones separate them, partly for performance and partly so a single failure does not take down the whole environment.
Service virtual machines count against your capacity too. Domain controllers, brokers, backup agents, and monitoring tools all consume cores and memory. Size only for desktops and you will be short on day one.
There is no single specification that fits every deployment. What exists instead is a set of per-user baselines you multiply out.
Microsoft publishes sizing guidance for session hosts that most architects use as a starting point, whether they are running in Azure® or on physical hardware.
| Workload type | vCPUs | RAM | OS storage | Typical user |
|---|---|---|---|---|
| Light | 2 | 8 GB | 32 GB | Data entry, browser, single line-of-business app |
| Medium | 4 | 16 GB | 32 GB | Office suite, Teams, several browser tabs |
| Heavy | 8 | 32 GB | 32 GB | Photo and video editing, large datasets, CAD |
Add roughly 30 GB per user for profile container storage on top of the operating system disk.
Processor clock speed deserves attention alongside core count. Applications like AutoCAD and older accounting packages do not parallelize well, so a 32-core chip at a modest frequency can feel slower than a 16-core chip that clocks higher.
For disks, use enterprise SSD or NVMe. Spinning disks will survive a normal Tuesday afternoon and fall apart during a boot storm, when hundreds of desktops start simultaneously and generate a burst of input/output operations per second (IOPS) far above the steady-state average.
Memory is where most estimates break down. A workable formula: desktop memory plus service machine memory plus hypervisor overhead, then a reserve of 15% to 30% on top.
User density depends on whether desktops are single-session or multi-session, and on what those users actually run.
In a single-session setup, one user gets one virtual machine. Density is straightforward arithmetic: total available resources divided by the per-desktop allocation, minus overhead.
Multi-session changes the math. Several users share one Windows instance, which cuts operating system overhead considerably. Microsoft’s published maximums are 6 users per vCPU for light workloads and 4 per vCPU for medium workloads, on a virtual machine of at least 8 vCPUs and 16 GB of RAM. Heavier and graphics-intensive profiles fall well below those numbers.
Two constraints are easy to miss. Multi-session hosts should stay between 6 and 24 vCPUs, and returns start diminishing past roughly 16 vCPUs because of the overhead of scheduling processes across them.
There is also a failure question buried in density planning. One large server hosting 100 desktops looks cheaper per user on a spreadsheet. It also means a single hardware fault removes 100 people from their work at once. Most designs use N+1: enough hosts that losing one still leaves capacity for everybody.
The alternative to buying and racking a VDI server is renting the outcome. Desktop as a Service (DaaS) providers run the server layer and hand you desktops.
| Factor | On-premises VDI server | Hosted DaaS |
|---|---|---|
| Upfront cost | Server hardware, hypervisor licenses, storage, networking | None |
| Capacity planning | Size for peak demand and buy ahead of it | Add or resize desktops as demand changes |
| Maintenance | Your team patches, replaces drives, tests failover | Provider handles the infrastructure |
| Failure domain | A host going down takes its desktops with it | Provider redundancy and an uptime SLA |
| Time to first desktop | Weeks to months, including procurement | Minutes |
| Cost model | Capital expenditure plus a refresh cycle every 4 to 5 years | Predictable monthly cost |
| In-house skills | Hypervisor, storage, and broker expertise required | General IT familiarity |
Most teams asking this question are trying to solve something simpler than VDI. Staff need Windows applications from anywhere, on whatever laptop they already own.
A VDI server answers that by making you the infrastructure owner. You size and buy the host, stand up a connection broker and a gateway, license Windows Server and Remote Desktop Services (RDS), then keep patching all of it.
We took the other path. Our platform is Desktop as a Service, so the host, broker, and gateway are ours to run. You pick a virtual machine sized to the workload, Basic through Power, and assign people to it.
A team running QuickBooks Desktop alongside Office can share one Mid Level VM rather than paying per person for capacity nobody uses individually. That is usually where the cost comparison turns. It is also why QuickBooks cloud hosting runs on a shared desktop for most small firms instead of a dedicated machine each.
Build the server yourself when there is a concrete reason: data residency rules that rule out third-party hosting, specialized hardware nobody else will support, or a data center already paid for. Otherwise the real question is not how to size a VDI server. It is whether you need to own one.
Sizing from vendor marketing numbers is the first one. Density figures in a datasheet assume an idealized workload that nobody actually runs.
Second: forgetting the login peak. Average utilization tells you almost nothing about how the environment behaves between 8:45 and 9:15 on a Monday.
Third: treating all users as one profile. Five engineers running CAD alongside 45 office workers should be sized and often hosted separately. Blending them means either overpaying for everyone or underserving the engineers.
Fourth: skipping the pilot. Run 10 real users on the intended configuration for two weeks before committing to hardware. The measured number is almost never the calculated one.
No, though they overlap. A terminal server (now Remote Desktop Session Host) gives multiple users shared sessions on one Windows Server instance. A VDI server typically runs a hypervisor hosting separate virtual machines, each with its own operating system, although many modern deployments use both approaches side by side.
For a small pilot, yes. Production deployments need server-grade components: error-correcting memory, redundant power supplies, enterprise SSDs, and out-of-band management. Desktop-class hardware lacks the reliability features that matter when 30 people depend on one box.
Total desktop memory, plus memory for service virtual machines, plus hypervisor overhead, plus a 15% to 30% reserve. A 50-user mixed-workload environment commonly lands between 512 GB and 1 TB of total RAM.
No. With a hosted DaaS platform, the provider owns and operates the server layer. You manage users, applications, and access policies instead of hardware.
The host runs a hypervisor such as VMware ESXi, Microsoft Hyper-V, or Citrix Hypervisor. The desktops on top of it usually run Windows 10 or 11 Enterprise, Windows Server with the RDSH role, or a Linux distribution.
Rarely just one. Splitting 100 users across three or four hosts with N+1 capacity is standard practice, because it keeps a single hardware failure from taking down the entire environment and makes patching possible without downtime.
Related terms: What Is VDI?, Desktop as a Service, desktop virtualization, server virtualization, cloud VDI, VDI for small businesses
Your V2 CloudCare team — real people, on the line.