There is an important distinction between virtual networks and networks inside of a hypervisor. If you hook up a bunch of VMs to a vswitch inside of an ESX server, you might call that a virtual network, and that would be reasonable because its a network inside of a vmware server, right? But if you hook up a bunch of things using a VLAN, you might call that a virtual network too. After all, a VLAN is a Virtual Local Area Network. So which of these views is correct?

You might say, why don't you just call the second thing a VLAN? Why do you need to give it a generic name? Well, what if you wanted to set up a tunnel to connect the VLAN across the internet to another VLAN in a different site? You could even set up a VRF (Virtual Routing and Forwarding) domain to connect the VLAN to the tunnel, to make sure routes did not leak out. The concept that all of these things (VLANs, VRFs, GRE tunnels, IPSec tunnels) have in common is encapsulation, putting the packet into another layer of headers, sticking it into a transmission medium, and having the receiver remove the header and pretend it just got the contents off the wire. You can use this trick to set up a virtual network, on the underlying substrate network, on any kind of network technology. If you want all the gory details, here is a good book (disclaimer, I don't know the author and am not affiliated with him or his company).

Anyway, my point is that since there are so many different ways of wrapping something into something else and shipping it across a local or wide area network, we need a general term to describe it, and the network guys call this Network Virtualization.

Now, I think that they are going to have to come up with a whole new set of jargon words to separate these notions, but for the time being, I am going to invent my own. I am going to call the network inside the hypervisor the substrate network. Because that's the equivalent of the physical switch on which we create VLANs. And when I set up a VLAN inside the vswitch server, and maybe connect it to a VLAN on a physical switch and use that to connect the VM to a specific interface of a physical firewall, I am going to call that a virtual network connecting the VM to the firewall. And if I tunnel that packet at the firewall and carry it across the Internet, well, that's still the same VM being extended across the WAN.

So is this just a Cisco centric view of the world, and completely irrelevant for the typical VM administrator? Actually, I think VLANs (and tunnels and all the rest of it) are very cool for a VMWare installation. The reason is that they extend the flexibility and reconfigurability of virtualization to the network. Here is how.

Lets say that you are using server virtualization to help you adapt your data center to changing load patterns. As load increases, you can pick physical servers with additional free capacity and deploy VMs on them, and load balance across them to pick up the slack. If you have your typical 3-tier application architecture, with web-servers, app-servers, and database servers, you would want to separate these out into different L2 domains for security and performance. By using VLANs for this, and also coordinating the configuration of VMs in ESX servers and VLANs in the substrate network (physical and virtual switches), you can get the security and performance benefits of separation, without breaking up your server resource pools and losing the cost and efficiency benefits of virtualization.

Of course, all this is easier said than done. You need something, scripts or software, to automate the coordination. But, at least, there is some hope that you can make your whole data center flexible without compromising security and performance.