wiki:Web/VirtualMachinesMigration

Introduction

A hot topic on computing nowadays is virtualization, and virtual machine migration. Quattor already supports creation, destruction and management of virtual machines. But no work has been done yet on VM migration. Here I propose a couple of additions to current VM structures that would allow the component to make the decision on where the VM should be located and trigger migrations, if needed. The basic idea is that, although a migration is an action, the VMs running are clearly part of the host's state.

Data structures

VMs are declared as usual, on ncm-xen and ncm-openvz components. But if we add two fields, migration is possible:

 master : fqdn
 host : fqdn

master is the name of the physical machine that is expected to usually own the VM. This PM is responsible for creating the VM. host is the name of the PM where the machine must be actually running. When this changes a migration must be triggered.

How it should behave

This is the pseudo-code the components should have. $guest is the VM description.

 if (!$profile->contains($guest)) {
    destroy($guest)
 } elsif ($guest->master = $guest->host = hostname()) {
    if (!running($guest)) {
       create($guest);
    }
 } elsif ($guest->host != hostname() && i_am_hosting($guest)) {
    migrate($guest, $guest->host);
 } else {
    do_nothing();
 }

So, only the master is allowed to create a given VM. Then, a VM description is included by a pool of physical machines. The component will, as usual, check its current state and if it doesn't match with the profile, trigger the appropriate actions.

An example

So, suppose we have two physical machines, called Springfield and Shelbyville. And we have Homer, Marge, Bart, Lisa and Maggie hosted on Springfield. But Bart grows up (he should be 28 by now, why is he still in 3rd grade??) and there is no room for him in Springfield, so he moves to Shelbyville. Let's explain this in Pan language: Springfield city looks like this:

 object template springfield;
 
 # Let's declare the VMs
 include {"simpsons/homer"};
 include {"simpsons/marge"};
 include {"simpsons/lisa"};
 include {"simpsons/bart"}:
 include {"simpsons/maggie"};

 ...

And Shelbyville is well aware of the existence of the Simpson family, although they don't live there.

 object template shelbyville;
 
 # Let's declare the VMs
 include {"vms/simpsons/homer"};
 include {"vms/simpsons/marge"};
 include {"vms/simpsons/lisa"};
 include {"vms/simpsons/bart"}:
 include {"vms/simpsons/maggie"};
 
 ...

Similar, right? But now, let's describe how Bart is seen by both cities:

 template vms/simpsons/bart;
 
 "/software/components/<virt>/guests" = npush (
     "bart", nlist (...
         "master", "springfield",
     "host", "springfield"
     )
     );

Easy to remember: Bart is born in Springfield and lives on Springfield. Now, to trigger a migration just change the above template to this:

 template vms/simpsons/bart;
 
 "/software/components/<virt>/guests" = npush (
     "bart", nlist (...
         "master", "springfield",
     "host", "shelbyville"
     )
 );

And now, no matter where Bart was living, he will move to Shelbyville.

Warning!!

The PM hosting a virtual machine is also allowed to destroy it. So, if you remove the bart line on shelbyville's profile after Bart has moved there, Bart will die.

To be thought

  • How to detect a scheduled downtime on a VM and avoid triggering a new VM machine creation? Perhaps we should check something on the guest's /system/maintenance?
Last modified 14 years ago Last modified on Mar 21, 2010, 11:32:36 AM