Changes between Initial Version and Version 1 of Web/VirtualMachinesMigration

Timestamp:

Mar 20, 2010, 10:32:26 PM (14 years ago)

Author:

loomis

Comment:

--

Web/VirtualMachinesMigration

@@ +1 @@
+[[TracNav]]
+
+= 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
+
+<tt>master</tt> is the name of the physical machine that is expected to usually own the VM. This PM is responsible for creating the VM.
+<tt>host</tt> 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}}?
+