I retweeted this on twitter, but it’s just too good to not show. Over at rottenbytes.com Nicolas is showing some proof of concept code he wrote with MCollective that monitors the load on his dom0 machines and initiate live migrations of virtual machines to less loaded servers.
This is the kind of crazy functionality I wanted to enable with MCollective and it makes me very glad to see this kind of thing. The server side and client code combined is only 230 lines – very very impressive.
This is a part of what VMWare DRS does Nico has some ideas to add other sexy features as well as this was just a proof of concept. The logic for what to base migrations on will be driven by a small DSL for example.
I asked him how long it took to knock this together: time taken to get acquainted with MCollective combined with time to write the agent and client was only 2 days, that’s very impressive. He already knew Ruby well though ๐ And has a Ruby gem to integrate with Xen.
I’m copying the output from his code below, but absolutely head over to his blog to check it out he has the source up there too:
[mordor:~] ./mc-xen-balancer [+] hypervisor2 : 0.0 load and 0 slice(s) running [+] init/reset load counter for hypervisor2 [+] hypervisor2 has no slices consuming CPU time [+] hypervisor3 : 1.11 load and 3 slice(s) running [+] added test1 on hypervisor3 with 0 CPU time (registered 18.4 as a reference) [+] added test2 on hypervisor3 with 0 CPU time (registered 19.4 as a reference) [+] added test3 on hypervisor3 with 0 CPU time (registered 18.3 as a reference) [+] sleeping for 30 seconds [+] hypervisor2 : 0.0 load and 0 slice(s) running [+] init/reset load counter for hypervisor2 [+] hypervisor2 has no slices consuming CPU time [+] hypervisor3 : 1.33 load and 3 slice(s) running [+] updated test1 on hypervisor3 with 0.0 CPU time eaten (registered 18.4 as a reference) [+] updated test2 on hypervisor3 with 0.0 CPU time eaten (registered 19.4 as a reference) [+] updated test3 on hypervisor3 with 1.5 CPU time eaten (registered 19.8 as a reference) [+] sleeping for 30 seconds [+] hypervisor2 : 0.16 load and 0 slice(s) running [+] init/reset load counter for hypervisor2 [+] hypervisor2 has no slices consuming CPU time [+] hypervisor3 : 1.33 load and 3 slice(s) running [+] updated test1 on hypervisor3 with 0.0 CPU time eaten (registered 18.4 as a reference) [+] updated test2 on hypervisor3 with 0.0 CPU time eaten (registered 19.4 as a reference) [+] updated test3 on hypervisor3 with 1.7 CPU time eaten (registered 21.5 as a reference) [+] hypervisor3 has 3 threshold overload [+] Time to see if we can migrate a VM from hypervisor3 [+] VM key : hypervisor3-test3 [+] Time consumed in a run (interval is 30s) : 1.7 [+] hypervisor2 is a candidate for being a host (step 1 : max VMs) [+] hypervisor2 is a candidate for being a host (step 2 : max load) trying to migrate test3 from hypervisor3 to hypervisor2 (10.0.0.2) Successfully migrated test3 ! |
