Networks, host OSes strained by VMware VDI deployments

The impact of virtualization on network architecture and design--both server virtualization and desktop virtualization--is a big topic. I'll cover these topics in depth in future tips. So far, in my series on VDI on VI3, I've offered advice on a number of topics, such as using the three main components of VDI and VirtualCenter and the connection broker in VDI.

VDI and the network

VDI will impact network infrastructure in at least three ways:

• First of all, the network must be able to accommodate the virtualization infrastructure to support the hosted desktop instances. For an organization that has not previously implemented a virtualization infrastructure, this may mean significant changes to the data center network design.

• The network will no longer need to provide significant bandwidth to the end users because their devices will only serve display functions using a presentation/display protocol such as Remote Desktop Protocol (RDP) or Independent Computing Architecture (ICA). This won't have a tremendous impact today given that Gigabit Ethernet network ports are now ubiquitous. It does, however, impact the rise of 10GB Ethernet and its applicability to desktop workloads.

• Finally, most VDI implementations go hand-in-hand with a broader adoption of remote workers, such as telecommuters or offshore developers. This means that many VDI implementations may require changes in the remote access infrastructure. Perhaps the connection broker selected for the VDI implementation offers its own SSL VPN functionality, or perhaps the organization is seeking greater integration between the existing SSL/IPSec VPN equipment and the connection broker. Either way, streamlining--or simply providing--access to the hosted desktops can mean changes to the organization's remote access infrastructure.

VDI and hosted OS instances

We've seen how a VDI design and implementation should take the network into consideration. Now let's turn our attention to the hosted desktop instances. Note that in this article I'll use the phrase "traditional OS installation" when referring to an installation of an OS directly on hardware without the use of virtualization.

Although we are simply virtualizing a desktop OS instead of a server OS in a VDI implementation, there should be differences in a hosted OS installation compared to a traditional OS installation. There are two things in particular that stand out:

• Each hosted OS instance only needs to support the virtualized hardware presented by VI3. There is no need to support a wide variety of IDE controllers, SCSI controllers, video controllers or network cards. Therefore, the use of a utility such as nLite can be very beneficial. NLite streamlines a hosted installation of Windows to remove unnecessary drivers, unnecessary hardware support and unnecessary components. This results in improved performance of the VMs. Keep in mind that the storage requirement reductions can be especially significant when dealing with VDI deployments of 500 or 1000 virtual machines.

• The hosted OS instances need to integrate in some fashion with the connection broker. This is because the connection broker manages connections -- typically RDP connections -- to the hosted OS instances.

  To prevent assigning a user to a hosted OS instance that is already assigned, the connection broker has to track which VMs have been assigned to a user, whether the user is still logged in, or if a user is logged in but disconnected from the session. This is usually accomplished by installing an agent inside the hosted OS instance. This agent communicates back to the connection broker and allows the connection broker to more closely monitor the state of the VM.

  The connection broker agent's presence and the need for the hosted OS to communicate regularly with the connection broker mandates that any OS-level firewalls -- such as the Windows Firewall with Windows XP SP2 or later -- must usually be disabled. Otherwise, the connection broker agent is blocked and the connection broker's functionality is negatively affected.

As I've described over the past few articles, there are a number of different components and architectures that need to be considered in a VDI project. Understanding the complex relationships between the virtualization infrastructure, the connection broker, VirtualCenter, back-end directory services such as Active Directory, the network, and the hosted OS instances will help you properly design, deploy, and debug your VDI implementation.

About the author: Scott Lowe is a senior engineer for ePlus Technology, Inc. He has a broad range of experience, specializing in enterprise technologies such as storage area networks, server virtualization, directory services, and interoperability. Previously he was President and CTO of Mercurion Systems, an IT consulting firm, and CTO of iO Systems.

Rate this Tip To rate tips, you must be a member of SearchVMware.com. Register now to start rating these tips. Log in if you are already a member. Digg This!     StumbleUpon     Del.icio.us    DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.