(This is Part 2 of the ‘Real-World VDI’ series – see Part 1 “Multi-Vendor Stack, Part 3 “Cost”, Part 4 “Recent Announcements” and Part 5 “Future of VDI”)
While most clients initially enthusiastically agree to address first the “low hanging fruits” of VDI, almost without exception I had the “dreaded question” come up consistently in the first meeting: “I have this user group with high-end graphics, video conferencing/3D graphics/engineering application (replace this with your graphics intense application) requirements … Can we deliver this with our approach…?
Make sure you understand what the clients view of “high-end graphics” really translates into … For some it was a 720p streamed video for others it’s an OpenGL 3 based CAD app …
Without ignoring the fact that many of these will require proof of concept type of activity in order to verify suitability, the first step for you should be to understand what the clients view of “high-end graphics” really translates into…
For some it was a 720p streamed video for others it’s an OpenGL 3 based CAD app. Understanding which version of the rendering API is used (e.g. OpenGL, DirectX) is a good first step to determine feasibility for HVD in general, alongside with the expected bandwidth requirements based on resolution, number of monitors etc.
Reality is that vendor/technology choice is crucial here – you will be able to achieve different levels of graphics capabilities and (important!) user density for a given use case. And always ask yourself throughout the process whether VDI really is the right answer for this use case.
So, are the capabilities really that different? It’s actually not that easy to get a simple view of how vendors compare here, so I created this little high-level table:
Please note that this table only addresses “advanced graphics capabilities” (like DirectX and OpenGL) which typically require GPU-like functionality in either the host or client device.
In order to e.g. display an avi video you won’t (e.g. for Citrix) require HDX3D (with host-side GPU) and will therefore not incur some of the restrictions and requirements listed below. In the same way, View 4.x with PCoIP is perfectly capable to display “casual graphics”.
It becomes clear why XenDesktop/HDX has been favored by many when it comes to graphics delivery. Again, the last 3 large clients told me pretty much the same story after their initial evaluations or POCs. Efficient bandwidth utilization, good WAN performance and the option to display high-end graphics for e.g. workstation replacements were some of the key decision factors to select HDX. When using HDX3D (typically a small subset of the overall user base), the 1:1 user to host ratio is however very limiting. The GPU-Passthrough function (which is experimental prior to XenServer 6) is a great feature, but still only increases the ratio to one user (vm) per GPU.
Due to VMware Views 4.x lack of host (or client) GPU rendering offload capability none of these advanced capabilities can realistically be achieved. Standard graphics workloads can be delivered with similar user experience than HDX (but sometimes higher bandwidth utilisation).
RemoteFX overcomes the restrictive user to host ratio of HDX3D but can’t deliver full “advanced graphics” functionality and lacks WAN support, still a good fit for those use cases where only casual Aero-like workload is needed.
You might argue that high-end graphics capabilities shouldn’t be the main decision factor for a VDI platform – reality is that most customers want to have at least the option to cover those use cases in the future …
You might argue that high-end graphics are only a small subset of the overall user base requirements and shouldn’t be the main decision factor for a VDI platform – and I partially agree, reality however is that most customers I worked with want to have at least the option to cover those use cases (even if in the future) – so it has almost always been a consideration.
What one can’t argue with is the importance of the cost case for VDI … so let’s look at a common mistake made with that next HERE …