One of the most significant architectural decisions when setting up a Citrix provisioning environment is the question of, where Where the vDisks are actually located: on a central SMB share on the network—or locally on the PVS servers themselves. In practice, many customers opt for the network share because, at first glance, it seems simpler and more cost-effective. Technically, however, this is the worse choice in the vast majority of cases. This article explains why—and how the disadvantages of local volumes can be resolved with PVS Forge.
Why Local Volumes Are Technically Superior
The key point is simple: With a local volume, No network connection between the streaming service and the vDisk. There is no SMB layer, no network latency, and no dependence on the configuration of a file server. The PVS server reads the blocks directly from local storage and streams them to the targets.
As soon as an SMB share comes into play, you’re opening the door to a whole chain of potential bottlenecks—and you have to actively manage each and every one of them to ensure optimal streaming performance.
The SMB Issue in Detail
For a network share to even compete with local storage, several factors must align:
- CPU configuration of the PVS server. SMB throughput is directly dependent on available CPU power. If the server is underpowered, the CPU will limit throughput long before the network or storage reaches its limits.
- Receive Side Scaling (RSS). Without active and correctly configured RSS, all network interrupt traffic is bundled onto a single CPU core. This single core becomes a bottleneck, while the remaining cores remain idle. Only RSS distributes the network load across multiple cores and unlocks the full throughput of the NIC. For this to work, RSS must not only be present but also configured on the adapter— and It must actually be active at the operating system level and properly mapped to the available cores—otherwise, you'll be wasting exactly the throughput you need for smooth streaming.
Important—and this is a point that many customers don't realize: Traditional RSS works for physical Servers. However, PVS servers now run almost entirely in a virtual environment, and there it is not RSS, but rather vRSS (Virtual RSS) The key factor. Microsoft introduced vRSS with Windows Server 2012 to solve precisely this problem in virtual machines: distributing a VM’s network traffic across multiple virtual processors. Without active vRSS, you’ll run into the single-core bottleneck again even within the VM—no matter how many vCPUs are assigned. So if you’re streaming a virtual PVS server via an SMB share, you need to be familiar with vRSS and actively configure it; otherwise, throughput will remain unnecessarily limited.
These aren't just „nice-to-have“ tuning tweaks. They are prerequisites without which an SMB-based setup simply cannot achieve optimal speed and the necessary throughput. With a local volume, this entire set of issues is eliminated entirely.
DFS: A Common but Dangerous Deviation from the Norm
Some people also reach for DFS Shares — and you shouldn't do that. The problem lies in the timestamps: If a vDisk is copied to the DFS, the replica on the second server may end up with a timestamp that differs slightly. A PVS server that detects this discrepancy then classifies the vDisk as not synchronized — and simply fails to start it on that server. Unless the administrator explicitly checks the PVS console to see if the vDisk is reported as synchronized and matching on both servers, this goes unnoticed: As a result, the vDisk is only available on one of the two servers. This is a real problem that is difficult to diagnose in practice—because at first glance, „the disk is on both servers.“.
Why Customers Still Shy Away from Local Volumes
If local volumes are so clearly superior from a technical standpoint—why do so many people still use network shares? There are essentially two reasons.
Reason 1: PVS does not synchronize vDisks on its own
That's the real Achilles' heel. PVS does not include any built-in functionality to synchronize the created vDisks across all PVS servers. If you use local volumes, you must ensure that every new vDisk and every new version is identical on every PVS server—otherwise, not every server will stream the same version.
There are a few individual scripts and homemade script bundles available online for this purpose. But there's nothing that integrated into the product ensures that the vDisks are kept in sync automatically and reliably. It is precisely this manual, error-prone process that deters many users—and drives them back to the central share, where there is only one copy.
Reason 2: Multiple storage needs
The second reason is storage requirements. A central share with one terabyte is exactly that: one terabyte. If you want to keep the same data locally, it must be stored on every PVS server—so, with the usual minimum of two PVS servers, it must be stored twice, meaning two terabytes for the same content.
This additional requirement is real and should be factored into planning honestly. However, it is put into perspective considerably when viewed against today’s storage capacities: Volumes of one, three, or four terabytes are no longer unusual—they’re almost commonplace. In most environments, the additional cost of storage is a much smaller price to pay—compared to the performance gains achieved.
What's at stake: Streaming performance
The network dependency of an SMB share hits many customers hard: performance drops during streaming, systems that feel sluggish and slow—simply because the data isn't coming in fast enough. Especially under heavy load, such as during morning boot storms, the network path becomes the limiting factor.
Local volumes demonstrate their superiority most clearly here: full, unrestricted access to the storage, no network or SMB variables in the way, and maximum throughput when streaming blocks.
And this is exactly where a second adjustment can be made: the type of storage. Many companies now use SSDs in their storage systems, and the difference between slow and fast drives is immediately noticeable when streaming. For the volumes on the PVS servers, it therefore makes sense to specifically SSD Storage — because read access dominates PVS streaming, and that is precisely where SSDs really shine. The result is optimal, fast read throughput and, consequently, fast, stable streaming to the targets.
This is where PVS Forge comes in
The single most important reason against using local volumes—the lack of synchronization—is eliminated with PVS Forge. PVS Forge automatically synchronizes the vDisks across all PVS servers. No custom-built scripts, no manual copying, and no risk of a server streaming an outdated version. Every new vDisk and every new version is reliably distributed across the entire farm.
This fundamentally shifts the balance: The only remaining „drawback“ of local volumes is the higher storage requirement—and given today’s volume sizes, that’s easily manageable and can be planned for with confidence. The real showstopper—synchronization—has been resolved.
Conclusion
Technically, the matter is clear: Local volumes on the PVS server are the superior option. No network, no SMB dependencies, no need for CPU and RSS tuning, no DFS sync pitfalls—instead, full throughput and stable streaming even under load. The two reasons that have held customers back so far were the lack of synchronization and the need for multiple storage devices. PVS Forge completely resolves the first issue through automatic, farm-wide vDisk synchronization; the second is no longer a serious obstacle given today’s storage capacities.
The clear recommendation is: local volumes—and PVS Forge finally makes them feasible without compromise.
German 
English