Cloud-Based VDI, Part 2

Earlier in the week I mentioned that I would be evaluating a hosted VDI solution from the iland workforce cloud. So far in to the experience I can say that while it works well, there are many considerations that we need to factor into a decision like this.

In this blog post, I want to focus on two critical points that go into any VDI solution. The first is the display technology used. Above all, the workforce cloud is brokered by VMware View over SSL over the Internet. So, that means that the View client is the endpoint display delivery and intermediary display from the actual virtual machine.

There can be a few configurations in use, but what matters is the experience. I have been using the hosted virtual desktop at a residential broadband offering that is a cable-based transport. From an experience standpoint, it is okay. Standard applications like Word, Windows Explorer and navigating the operating system are fine. In fact, I can hardly determine the experience is not native in these applications.

Web browsing is a different story. If I end up on any Web page that has Flash embedded in the display, performance is painful. Flash can be sent through a display technology, and it is only as good as your pipes. I ran a number of Internet connection tests from Speedtest.net on the virtual desktop, and they performed well. Some results were higher; some were lower with the Internet results (see Fig. 1).

Figure 1. Bandwidth matters in the cloud on both ends. (Click image to view larger version)

The iland workforce cloud is different in one respect: Your servers could be in the same cloud allowing for local access.

Back to the display experience; I will soon test the performance on a connection that is better than a residential broadband service. I’ll follow up with the results and share them with you on this blog.

The other key point I want to discuss is device support. The iland workforce cloud worked seamlessly in providing full device redirection. This included options for dual monitor support, printing, local removable media and mapped network drives on the endpoint client. There can be policies in place to address how and if these are redirected. This was refreshing that there was no configuration required to use the devices on the local client. Fig. 2 shows my printer on the local workstation accessible from the hosted virtual desktop.

Figure 2. Printing on the hosted virtual desktop could not have been easier. (Click image to view larger version)

Notice the “TPAutoconnect” in the printer comments. That is a ThinPrint integration for easy printing on the hosted virtual desktop.

Thus far in my use of the hosted virtual desktop I’d say, "so far, so good." I’m going to make the connection on a higher bandwidth network and see how that goes, but even if the performance is better, I’m not happy just yet. I believe that the hosted virtual desktop needs to perform at the residential level, which will include less than optimal bandwidth speeds.

In future blog posts, I'll cover virtual private networking with hosted desktops as well as device connections in lieu of full-blown desktop connections. Also in the crystal ball is the important other half: the hosted virtualized server with the hosted virtual desktop.

Have something you want me to cover? Share your comments here or e-mail me.

Posted by Rick Vanover on 11/02/2009 at 12:47 PM