This article originally appeared in the January 2011 issue of INTERNET TELEPHONY

When I begin a new conversation with someone about virtualization, the topic always goes straight to one of two topics: server virtualization – such as using VMware or Microsoft (News - Alert) for optimization, agility, or consolidation – or cloud computing, virtualizing the location and computing resources required for an application or service. This is a valid course of conversation given IT’s use and reliance on virtualization technologies today to achieve their particular business goals: agility and lowering capex and opex.

One topic that rarely comes up in casual conversation, however, is virtualization of the network, and more specifically how to integrate and manage a virtual network as part of an entire virtual server and/or cloud computing deployment. On one hand this omission makes sense: the network is merely the way we access services. But on the other hand, this lack of attention is somewhat puzzling because the network is an absolutely critical component of any virtualization deployment – and it can be argued that it is the most fundamental component of cloud computing. There is really no point in virtualizing computing resources, or moving applications off premises to the cloud, if users can’t access those dynamic and scalable resources.

Fully virtualizing the network isn’t a requirement for virtual infrastructure or cloud deployments; there is nothing prohibiting a cloud provider from stopping at VLAN allocations for new cloud customers. Offering more advanced and sophisticated options, however, will give both the enterprise customer and the cloud provider more flexibility down the road. First off, virtual platform solutions from VMware and Microsoft rely heavily on virtualized network resources. In fact many advanced platform virtualization solutions require virtual switching to even function. At that level, virtual networking resources become part of the computing fabric.

Networking and server virtualization typically are managed by different groups within IT, which may contribute to the disparity between virtualized computing resources and networking resources. Support staff deploying virtual servers are already on the front lines of merging the network with virtual servers: virtual servers need to have an IP address and be part of a specific VLAN. This is a task that typically is configured in the virtual platforms as part of the server configuration, yet IP addresses, VLANs, routes, access to the network, and other connectivity requirements usually are managed by the networking teams. Complexity and the challenges of these groups working together become more of an issue when virtual networks extend beyond the hypervisor platform.

Beyond that, bringing the same virtualization concepts we use for sophisticated and dynamic deployments such as those for the cloud to the network can drastically increase our ability to be agile. Virtual networking benefits can be foreign to many companies and administrators who are faced with moving to virtualization or looking at the cloud simply to add efficiency or for consolidation. But much as distributed virtual machines seemed foreign to the enterprise five years ago, building extremely sophisticated virtual, distributed networks today feels a bit “out there.”

We are, however, now beginning to see a slow adoption of truly virtualized and distributed networking tools. VMware currently offers customers two options for distributed virtual switching. Citrix is following suit by building a virtual switch off of the Open vSwitch platform – a virtual switch available to other Linux-based virtual platforms as well. Uptake is slow, however, and I believe this has to do with, among other things, the level of complexity involved in virtualizing the network. The network is already a complex beast, and adding virtualization to the mix isn’t a simple task.

Virtualizing at the network layer requires new expertise, new tools, and most importantly, a new paradigm in distributed virtual switching.

Adding in the cloud becomes more complex because now we’re dealing with connecting multiple virtualized networks, on premises and off premises, and pushing those over the WAN (which may include traditional leased lines, dark fiber, MPLS, and any number of other upstream provider topologies and challenges). For example, we can build and deploy virtual switches in our on-premises virtual infrastructure, and replicate that architecture with our cloud provider. But how do we connect those two deployments for transparent and dynamic cloud bursting?

There’s some talk about the next phase of integrated virtual computing and the cloud with fabric-based computing. So much of the concepts needed for true fabric computing, however, rely upon a highly virtualized network. And this is one of the areas where we’re starting to see the real-world implementation of cloud computing catch up to (or rather, challenge) the hype. But we should be cautious: we’re now at a point where talking about yet newer virtualized computing models is putting the cart before the horse. The virtual network needs to catch up to and keep pace with virtual computing today before we can move any further, and the first step is grappling the complexity of virtual networks.

Alan Murphy is technical marketing manager of management and virtualization solutions with F5 Networks (News - Alert).