Pushing beyond the limits of virtual desktop density
0 comments, 2209 views
Unidesk was formed a bit over three years ago to bring to market a new approach to virtual desktop management, built on two key inventions. These inventions - CacheCloud and Composite Virtualization - make it possible to have a fully persistent desktop, but with the management and cost benefits of a non-persistent one. Finally users can have a desktop just like they are used to - one they can personalize with user installed applications and unique settings - but also where IT can provision and patch single images of the operating system and applications, and automatically have those updates available to the users. And all this with massive storage savings - which is so important to achieving reasonable density (and therefore, cost) with VDI.
The trick to doing this was to deeply understand Windows, including how it boots and operates. By understanding how the file system, registry and boot process works, we were able to create a single layering technology that can deliver the operating system, applications, and user personalization - with rich application compatibility, even across some of the most complex application types (such as system services, device drivers and antivirus). Unlike other systems that operate on the disk block level (too low) or upon user authentication (too high), we operate on the files, directories and registry keys, and do it "above the hypervisor and below Windows" - delivering rich application compatibility (read How is Unidesk different than...? to learn more).
About a year ago, it struck us that having this deep awareness of Windows could be the key to solving another VDI challenge - how to increase desktop density per host. Since we now know exactly what operating system and applications are being used across a wide range of guests (thanks to Composite Virtualization), it opens the door to another opportunity to reduce overhead. If so many desktops have redundant operating systems, applications and data, doesn't that mean they will also have redundant processing of those same elements? For example, every desktop launches Office - over and over again. It's a substantial amount of overhead, and a common source of CPU and IOPS spikes. So we got to thinking - what would happen if you could predict and eliminate that redundancy?
Shortly after this, we had our top engineers and architects seclude themselves in a conference room for a week and let them hack away on this idea - to see if they could identify commonality in process executions and if so, find a way reduce it. What we discovered is that if you look at processing with deep awareness of Windows - where you know what the application is, which process and thread is being executed, etc. - you can predict the outcome of many of the threads and processes.
We call the technology Quantum Virtualization™. Conceptually, it breaks down every executing process (more specifically, each thread within a process) into consistent, predictable time slices (called a "Q-slice"). Given a known process and the known state of a thread, and the fact that we know exactly what software is being executed (because the software is delivered from Unidesk Composite Virtualization layers), we can fingerprint the slice to track it (called a "Q-print"). From there, we quickly determine if we have already seen this pattern before (by indexing the Q-print into an inverted polynomial hash table to see if we can optimize it or not). If we can't exactly match the Q-print, we simply let the process execute as normal. But if we do find a match, we can avoid the overhead of the entire Q-slice, replacing it with the known outcome of a prior Q-slice, thereby accurately and reliably reducing computational overhead.
The results to date have exceeded our expectations. For example, on a typical dual-socket hex-core system, we would typically max out at around 80 desktops when using the LoginVSI Pro 3 Medium workload (before % RDY went above 10%). But now we are acheiving 340+ desktops using the same load generator and same measurement system, and with no measurable degredation in application response time. This represents a better than 4x improvement in desktop density over traditional VDI. We find similar results across a wide range of loads - anywhere from 3-5 times improvement in desktop density based on the load. When we deployed this technology using our own employee's desktops, where the workload varies substantially across the users, we saw an improvement of 320% in overall CPU efficiency, as well as a decrease in IOPS by almost half.

Of course, nothing is for free. There is some overhead to this approach, especially for workloads that don't have much similarity in their execution. In our tests, we found a worst-case performance degradation of 13% (the overhead to monitor and track the Q-slices) when we had every virtual machine run totally different software and workloads. So while this technology might not apply to all, it is showing tremendous benefits where similar workloads can be grouped on hosts.
We are still putting the final wraps on the technology, but look for it in our upcoming 2.0 release later this summer. We are signing up beta sites now, so if you are interested and have a workload of at least 1,000 desktops, please contact us and sign up for our beta.
From Chris's Desktop
Unidesk CTO Chris Midgley (@cmidgley) peels back the covers on the Unidesk vision, takes a deep dive technically, and gives it to you straight on the pros and cons on the Unidesk software and its competing solutions.
Popular Blogs by Chris
-
[13,116 views]
-
[3,546 views]
-
[3,298 views]
-
[3,175 views]
-
[2,822 views]



Post new comment