While system virtualisation - and to a lesser extent, desktop virtualisation - has held most of the virtualisation limelight, there is also a growing trend in network virtualisation.

Most of you in the network arena probably are familiar with the terms VLAN or VPN. It's a toss-up as to which is actually the older of the two most commonly used virtual network technologies, but it really comes down to whether you've been associated with remote access or traditional wired technologies.

This past fall, we were kicking around an internal discussion of what might be happening around the industry in network virtualisation. At that time we really couldn't put our fingers on what vendors were doing in this particular area, and there wasn't a great deal of press associated with virtualisation in networks as a whole. Sure, there was the traditional news about a new VLAN capability or a new flavour of VPN, but nothing really new and exciting to speak of.

Since that time we've been hearing quite a bit of new developments. There are several interesting technologies that have emerged over the past six months to approach network virtualisation issues from a variety of perspectives. With the latest system virtualisation advancements, administrators can simply and easily configure a new virtual machine (VM) environment and drop it on any available platform that meets their needs.

As the functionality of that VM changes, or demands on its resources increase, the system administrator can easily transfer that VM environment from one platform to another. From the system administrator perspective that's great and the process typically takes very little time these days compared to what they used to go through to configure a new system and bring it up to an operational level.

Now, enter this scenario from the network perspective. What happens when that VM environment is transferred to a physically different platform and ends up with a completely different IP address? How is traffic going to get rerouted? Since the system administrator has the ability to schedule a VM transfer while it's operational, what's going to happen to the live, real-time end user sessions? It all depends on whether the network has been updated with the latest network armament that can rise to the occasion.

Routing of course is the biggest issue with these types of VM transfers, along with caching and load balancing. The network plumbing now has to be VM-savvy to keep up with where the systems are residing at a moments' notice. Routing tables have to be more flexible than ever, and caching elements have to be kept informed when there is a change so they can correctly redirect end user session traffic from one location to another; otherwise the sessions will become stale and the quality of the end user experience will drop dramatically.

The other intriguing development in network virtualisation is loosely referred to as a VM tap. When we typically think of network communications we're almost always thinking of the packet traffic flowing on our wired, wireless, or other type of infrastructure plumbing. But what about the communications between VMs or the communications between a VM and its virtual management layer? Vendors are learning that those communications are as important as the traditional packet-level communications. So they've devised ways to passively intercept those intra-VM communications and channel them outside the VM environment.

Imagine if those redirected intra-VM communiqués could be forwarded over to a no-frills logging system, similar to a SYSLOG server, to gobble up everything thrown its way. What would you pay for that type of business and operational advantage?

Now, what if that same VM communications tap could redirect those intra-VM communiqués over to your favourite network management system or device monitoring tool or network alert system and could package those redirected communications in a form those systems could easily take in. What would be the business and operational advantages for that type of extended intra-system capability?

Perhaps it could eliminate some of your workload, keep you from having to predominately work in pure reactive mode to VM crises, or perhaps it could provide a heads-up before your phone starts ringing from irate end users whose VM sessions are flaking out as a result of the latest VM transfer. Now is the time to start checking out the latest in network virtualisation technologies before your infrastructure starts letting you know you're missing the latest technology boat.