virtualization.info

Last week Microsoft announced some remarkable changes in its VDI strategy, including new licensing options and the upcoming integration of Calista technology in Remote Desktop Services (RDS) under the name of RemoteFX.

The announcement, and the fact that Microsoft highlighted a stronger-than-ever partnership with Citrix in this effort, will impact the VDI ecosystem and, by some degrees, the customers adoption of desktop virtualization technologies.
The first reactions already came in: VMware, Quest and WYSE already published some comments on RemoteFX.

VMware, threatened by the “Rescue for VMware VDI” promotion, has a lot to say of course and lists the downsides of the offering:

• The trade-down includes two different product suites from two different companies with overlapping components.  Both solutions come with a hypervisor platform and connection broker.  This creates confusion leaving the customer asking which components to use when?
• A set of non-integrated products marketed as a solution with no reference architecture for deployment
• The included licenses are actually only free for one year (on the Citrix side) and then you’ll need to pay for that license + SA in subsequent years.
• Hidden costs of more infrastructure, more time and increased complexity to deploy and manage

A further elaboration on the complexity aspect would be greatly appreciated, but the other points are clear and the first one is very relevant: the overlap of Microsoft and Citrix virtualization offering always created confusion and the two partners never did a good job in providing guidance about this aspect.

VMware also has a long list of comments on RemoteFX:

• With the release of RemoteFX, Microsoft has acknowledged that the best way to deliver a rich user experience is via a protocol, like PCoIP, designed for effective host side rendering.

• Citrix joins in the acknowledgment by agreeing to support RemoteFX alongside their own “HDX” and in turn points to some of the deficiencies of ICA.
• On the management side, only VMware View offers a single centralized management solution. Other vendor solutions, such as Citrix XenDesktop and Microsoft RDS, use a myriad of non-integrated tools, consoles, and wizards to perform even the most basic tasks.
• RemoteFX will be a LAN-only solution (much as RDP is today). This is more limited than the PCoIP protocol which was designed to provide a great user experience on both local and wide area networks.
• While Microsoft spoke of vendors providing both RFX enabled thin clients and server offload cards, so far all that has been provided is a reference design – no vendors have publicly committed to delivering these components. By contrast, there are already a number of vendors delivering PCoIP zero clients and PCoIP monitors including Dell, IBM, Samsung, and Wyse. Furthermore, Teradici has had hardware-enabled solutions on the host side for more than 2 years.
• RemoteFX does not treat the desktop as a composition of multiple types of content. Instead it treats each element of the desktop exactly the same. An advantage of the PCoIP protocol is that it has different CODECs to handle different image content such as text, graphics, and video. Since RemoteFX cannot recognize and transmit the desktop by content type, end-users need to settle for a lowest common denominator experience versus the high-definition environment the PCoIP protocol can deliver.
• |One of the key features of VMware View with PCoIP is the ability for the display protocol to dynamically adjust to changing network conditions. PCoIP can “build to lossless” , which means that the user will receive the best experience possible as network conditions change. Both ICA/HDX and RDP/RemoteFX “dial in” the user experience when a user first connects and have limited ability to dynamically adapt to changing network conditions or user interactions.
• The idea of virtualizing physical GPUs is quite compelling, but unfortunately it’s a “chicken and the egg” type of problem. Most of today’s enterprise class servers are not designed to accept high-end graphics cards. Additionally, the cost of the GPUs can be quite high (upwards of $4,000 each) while only supporting a small number of users per card.

Quest, which could be seriously damaged by the advent of RemoteFX and the renewed partnership with Citrix on VDI, even releases an official press announcement to clarify its commitment and explain where vWorkspace will add value to the new platform:

Quest Software, Inc., provider of vWorkspace, a single virtualization solution for application delivery and desktop deployments, today announced plans to support Microsoft RemoteFX, a Windows Server 2008 R2 Service Pack 1 feature currently under development, in future versions of Quest products.

…

Added Rolls, “With our vWorkspace product, we will continue to enhance and extend the Remote Desktop Services platform to deliver user experience optimizations, especially for remote workers with WAN or Internet connections. We believe these optimizations will be especially important for customers using RemoteFX, and currently plan to extend our support to include RemoteFX within 30 days of its availability.” …

Last but not least, Wyse Technology, one of the largest thin client vendor in the VDI/SBC space, mentioned by VMware in the comments above, releases a press announcement too, to clarify the support to RemoteFX in every future product:

Wyse Technology, the global leader in thin computing and client virtualization, today announced plans to support Microsoft RemoteFX technology, enabling rich media experience across all Wyse client platforms.

Microsoft RemoteFX, a feature being developed for Windows Server 2008 R2 SP1, will integrate with any and all Wyse devices and both companies expect today’s announcements to accelerate desktop virtualization deployments…

Update: Microsoft published a complete list of partners that have announced support for RemoteFX. The list includes AMD, AppliedMicro, DevonIT, HP, ThinLinx and Via.
The HP support statement is particularly interesting considering the uncertain destiny of its RGS protocol.