On Thu, 26 Mar 2009 15:38:51 -0400, Scott Henson
<shenson(a)redhat.com>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> This patch implements 'cobbler system deploy'. Basically, if you have
> func connecting your cobbler server to your virtual hosts, you can now
> have cobbler simply deploy the virtual hosts. You can also manage the
> power state of your virtual hosts over func. You can deploy a system to
> a virt_host or a virt_group. A virt_group is a collection of available
> virt_hosts. Basic usage is as follows
>
> cobbler system edit --name=virtserver01 --virt-group=default
> cobbler system edit --name=virtserver02 --virt-group=default
>
> cobbler system deploy --name=vm01 --virt-group=default
> cobbler system deploy --name=vm02 --virt-host=virtserver02
>
> The first two commands add virtservers 01 and 02 to virtual group
> default. Then the second two commands deploy vms to those hosts. The
> first one will get randomly placed on 01 or 02, while the second will
> get placed on virtserver02.
>
> Currently cobbler picks which virt_host from a virt_group a vm lands on
> at random (random.choice(systems)). I would like to make this choice
> more intelligent based on the load each virtual host. Unfortunately,
> the load a virtual host is under can change from place to place.
> Currently the load factor I would like to use involves over committing
> the physical CPUs by 2 times, and limiting based upon maximum memory in
> the system. So it would be (VRAM+VCPU)/(PRAM+2*PCPU). Which should
> come out to a number less than one and we would grab the minimum. Any
> suggestions on a better way to do it? Its a pretty small/simple piece
> of code, but I bet it will have a large effect on the usability of the
> system.
>
> As for testing, I did initial smoke testing and it doesn't seem to break
> anything else. It should work except I can't get my version of koan to
> contact cobbler, but it is calling koan with all the proper arguments on
> the other side, so I call that 'working'. I'd love comments on it.
> Thanks.
>
> - --
> Scott Henson
> Red Hat CIS Operator
> WVU Alum BSAE/BSME
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org
>
> iEYEARECAAYFAknL2cQACgkQZ+CEIfzQ+Eq/DQCgkV4i97VsVQj8nC1+a4XJC6Ns
> nzwAoKB25abxzXBweE+RCIQICZOAuvg5
> =HvJU
> -----END PGP SIGNATURE-----
>
Very interesting. The only thing I'd think you might also want to look at
is the load averages of the system. Perhaps if systat is installed, you
could look at the last hours worth of performance data and skew your result
from above? A system may have 2-3 VM's running on it, but they could be
killing the box more than 10 idle ones do.
This is a neat idea!
(A) Using the libvirt remote APIs instead of koan as an option (instead
of Func)
(B) Being able to ask the ovirt server's "cloud engine" to deploy for
us as an option instead of evaluating our critera
All in all though, very cool.
I'm still finishing up 1.6.0 so I should have more comments/thoughts and
a chance to look this over soon.
Least number of VMs or most free vcpus seems like a reasonable logic to
use, given if folks want to tailor things
to a specific pool, they may put the same kind of VMs in a common
--virt-group. Disk space would also be important
to consider.
I could see this behavior we could configure from modules.conf (with
maybe the critera function
as a string in settings? Who knows).
Some knowledge of being able to deploy into EC2 would also be nice -- I
believe some other projects have code for
this we might be able to borrow from as yet a third deployment option.
Thanks!
--Michael