Quick Take: VirtualBox adds Live Migra… uh, Teleportation

November 30, 2009

Sun announced the 3.1.0 release of its desktop hypervisor – VirtualBox – with their own version of live virtual machine host migration called “Teleporting.” Teleporting, according to the user’s manual, is defined as:

“moving a virtual machine over a network from one VirtualBox host to another, while the virtual machine is running. This works regardless of the host operating system that is running on the hosts: you can teleport virtual machines between Solaris and Mac hosts, for example.”

Teleportation operates like an in-place replacement of a VM’s facilities, requiring that the “target” host has a virtual machine in VirtualBox with exactly the same hardware settings as the “source” VM. The source and target VM’s must also share the same storage, etc. and must use either the same VirtualBox accessible iSCSI targets or some other network storage (NFS or SMB/CIFS) – and no snapshots.

“The hosts must have fairly similar CPUs. While VirtualBox can simulate some CPU features to a degree, this does not always work. Teleporting between Intel and AMD CPUs will probably fail with an error message.”

The recipe for teleportation begins on the target and is given in an example, leveraging VirtualBox’s VBoxManage command syntax:

VBoxManage modifyvm  --teleporter on --teleporterport

On the source, the running virtual machine is modified according to the following:

VBoxManage controlvm  teleport --host  --port

For testing, same-host teleportation is allowed (source and target equal loopback). Obviously a ready and clean-up script would be involved to copy the settings to a target location, provide the teleport maintenance and clean-up the former VM configuration that is obsoleted in the teleportation. In the case of an error, the running VM stays running on the source host, and the target VM fails to initialize.

SOLORI’s Take: This represents the writing on the wall for VMware and vMotion. Perhaps the shift from VMotion to vMotion telegraphs the reduced value VMware already sees in the “now standard” feature. Adding vMotion to vSphere Essentials and Essentials Plus would garner a lot of adoption from the SMB market that is moving quickly to Hyper-V over Citrix and VMware. With VirtualBox’s obvious play in desktop virtualization – where minimalist live migration features would be less of a burden – VMware’s market could quickly become divided in 2010 with some crafty third-party integration along with open VDI. It’s a ways off, but the potential is there…

One comment

  1. See Eric Siebert’s post on the vMotion give-away question for another take on VMware’s impetus to include this “feature” as standard.

    We do not agree with one of his commenter’s position that this would require giving away vCenter. vCenter is a requirement of non-free VMware, which is NOT what SOLORI is a proponent of – however, adding value to the least common denominator vSphere product IS what we espouse.

    It is SOLORI’s opinion that any deployment of multiple (linked) ESX(i) servers should include a vCenter installation. The utility provided by vCenter is worth the nominal fee – especially if it included vMotion. Although some may argue that Storage vMotion should likewise be given away for free, I would argue that it is a valid value-add feature worth paying for with an upgrade. Migration of storage from a VM in the power-off state is still available, so Storage vMotion is really a application availability feature that has performance migration implications (i.e. worth paying for until competition catches up…)


Comments are closed.

%d bloggers like this: