Free ESG report : Seamless data management with Avere FXT

We migrate virtual machines (VMs) for all sorts of reasons: to load balance our physical hosts, say, or to offload a server so it can be taken offline for maintenance, or because the original host has failed. But in every case we want no interruption to the VM's operation, or at least as little interruption as possible.

That means its network resources need to move with it so that when it lands on a target physical server it can immediately start processing data and moving it across the network.

Much of that is taken care of by the hypervisor and the migration tools, according to Jon Cairns, director of systems engineering for northern Europe at VMware.

“You do need the ESX hosts to be on the same subnet to ensure connections are maintained,” he says.

Double vision

He adds that to move a VM, you also need networked storage that both hosts can see, as it is only the image in memory, not the data, that moves. And it needs a fast interconnect – ideally a second network.

“VMotion starts with a pre-copy in the background. The VM is still accessible as normal but the software is doing a dynamic page copy. Then eventually it suspends the VM for a split-second, does a final copy and restarts it on the new host,” he says.

“VMotion manages the virtual MAC address, and when the memory copy is complete and the VM comes up, it pings the router to ensure the new host is recognised. Everything configured within the VM should go with it.”

Paul Martin, systems engineering manager EMEA for VM replication specialist Quest Software, says the same-subnet requirement can be a problem.

Play your cards

For example, if the reason for moving a VM is fail-over, it may not be an option to run both hosts on the same site or subnet. In this case one option is dual virtual network interface cards (NICs) within the VM, either using Powershell to automate NIC failover, or editing the VM by hand.

“Other customers use NAT [network address translation] to get round the problem of different subnets,” he says.

However, there are also network layer factors that are external to the VM. For example, the source and target hosts may also need to be on the same virtual LAN (VLAN), which can limit the reach of your migration capabilities.

A solution for some is bridged VLANs, says Martin. But he adds: “That doesn't work for everyone, as not every environment can cope with it.”

And as Ken Duda, vice-president of software engineering at switch developer Arista Networks, notes: “You don't want to carry every VLAN everywhere. So the 802.1Q trunk needs to be able to dynamically modify a VLAN in response to say a VM migration. But how do you do that?”

By hook or by crook

Arista's solution was provide the hooks in its Eos operating system so its software partners can use their management tools to tie VLANs to key places.

“The VMware tracer talks to the network management and automatically provides the VLAN connection rack to rack,” Duda says.

Other vendors use port profiles to achieve something similar. Port profiles allow you to configure an interface to a particular role on the network, for example by applying access control lists, attaching VLANs, setting up broadcast limits, and so on.

They can be used to push out the same configuration to multiple interfaces, and because they can be applied to physical or virtual interfaces they are also a useful way to set up ports on softswitches for VMs.

The challenge with VMs is that, since they are no longer tied to a physical interface, they are also not tied to a switch port. But when you move a VM, the softswitch in the new server must have the same policies, VLANs and security settings as the old one, otherwise the migration will fail. Port profiles let you edit the new switch to match the old one.

“You throw it into the cloud which then manages where it runs”

Yet however you manage your switch reconfiguration, it adds complexity and administration time and requires the server and network admins to co-ordinate their work. Network vendors and software developers are looking for ways to move port profiles automatically, so that they follow the VMs that need them.

Johan Ragmo, data business development manager for northern Europe at Alcatel-Lucent Enterprise, says this is one of the many jobs for the management layer within a data centre or private cloud that take care of VM migration, load balancing and so on.

“You need to build a virtual network profile, taking account of quality of service and so on, that's managed in software with the virtualisation manager,” he says.

Follow the leader

Cairns agrees. “The long-term concept is that each VM will carry with it a set of policies, such as security level, availability and so on, and you throw it into the cloud which then manages where it runs. Underneath that, a foundation layer ensures adherence,” he says.

Brocade's Simon Pamplin says this is why Brocade developed automatic migration of port profiles (AMPP). It is part of Brocade's Virtual Cluster Switching technology, which enables a migrating VM’s network profile to follow it automatically.

“If you want to move a virtual image, setting up its port profile is a headache,” Pamplin says. “AMPP presets the destination port with the correct settings.”

The message is that, for the moment at least, a VM migration should be seamless – within certain boundaries. The area within those boundaries is constantly growing, but as a server admin it is always wise to know where the VM boundaries currently lie. ®

5 ways to reduce advertising network latency