Getting your virtual hands dirty with virtual networking
You need something to link all those virtual servers
We're all familiar with the concept of a virtual server. However, when planning and implementing a virtualisation project, it's not just the servers that can be and should be virtualised – it's the network too.
Among the first differences that you'll notice when setting up a virtual machine (VM) is the network setup. Naturally, it's not possible physically to plug a VM into the network, but the OS expects to be connected. The answer is a virtual Ethernet adapter which allows an OS inside the VM to operate as if it were physically connected.
Both Microsoft's Hyper-V and VMware's ESX – the virtualisation market leaders – provide virtual networking services in the form not just one or more virtual NICs but virtual switches too. This means that the hypervisor handles all layer 2 accesses to the network, and provides support for standard networking protocols and services such as VLANs. Both hypervisors allow you for example to build virtual networks both inside individual hosts and across hosts, allowing VMs to communicate as if they were physically connected, and to provide a connection internally between the guest machine and its host.
Virtual networking can also help reduce network management overheads
Virtual switches provide the same services as their physical analogues, so you'll find MAC port forwarding tables, the ability to create VLANs, and ESX for example also makes available a SPAN or mirror port to allow network sniffing for diagnostic purposes. The connection is made in the host's RAM so it's virtually instantaneous and free from the kinds of problems that hardware can throw up.
And because you only need one virtual switch per host machine – the host can add as many ports as the network configuration needs – one of the first changes you'll notice once you start consolidating servers is that the number of network ports required drops. If the host supports a large number of VMs and/or they're particularly I/O-intensive, then it may need several physical NICs, but this number should still be smaller than the number of VMs; if not, then one or more of the VMs may benefit from being re-constituted as a physical server. It's always advisable of course to use at least two physical NICs per host anyway, for redundancy and load balancing purposes.
Virtual networking can also help reduce network management overheads, as the virtual switch will incorporate a DHCP server that can deliver IP addresses appropriate to the VM's location and/or subnet, which is a consideration if the implementation of some form of datacentre orchestration is likely.
Ideally too, a virtual switch should be able to apply network policies no matter where in the datacentre the VM resides, such as VLANs and security policies. For example, Cisco's Nexus 1000V virtual switch does this by integrating into VMware's ESX kernel, displacing VMware's virtual switching system to provide services such as security, policy enforcement, automated provisioning and diagnostics. This allows the management of virtual machines as they migrate across physical servers during routine hardware maintenance or while balancing server workloads.
In an ideal world, the datacentre's network hardware infrastructure should be required to change as little as possible on the introduction of virtualisation, apart perhaps from an increased emphasis on the reliability aspects, given the number of servers dependent on each host although clearly some change will be needed. But at the higher layers, the key is to automate as much as possible, aiming for the holy grail of the datacentre as a unified computing fabric. ®