On 14/05/07 18:27 -0400, Chris wrote:
I'm happy to see other folks interested in the concept of domain groups
because it relates to some of my work. We seem to share many common
goals. Particularly, we both made use of the hypervisor to support
groups of domains. My first impressions:
Master/Slave Roles
------------------
While the master/slave model is certainly popular, it is not the only
relationship between domains. Consider a groups of peers. One way to
associate domains without an implicit hierarchy is to make groups a
first-class object, just like domains. You can anchor scheduling
information against the group instead of on a single domain. This
approach also has the benefit of allowing other projects to use group
information for more than scheduling.
This is a good idea. When I made my first attempt at scheduling groups
I put the infrastructure in place to make groups a first-class
object. However, I decided to rewrite the code to push most the
changes into the credit scheduler because doing so dramatically
reduced the size of the patches, and it made the patches more discrete
and modular.
I feel that starting out with a minimal patchset that meets the
specific requirements (accurate scheduling of stub domains) was the
right first step. Extending the concept of groups within Xen is a good
next step.
Usability
---------
Assuming I read your patches correctly, the intended use is that
administrators must remember which domains are masters and which are
members (and do so by domid). Since it's easy to lose track of domids,
I suggest augmenting xm list and the supporting infrastructure to
provide cues to the administrator about group membership and roles.
Yes, that is definitely needed.
Also, it would seem sched-group.c supports specification of members by
domid only. Support for using domain names and uuids would be useful
because domids do change.
Yes, very true. This is probably best implemented in the tools
themselves.
Assigning group names and group uuids quickly becomes essential too.
Imagine the chore of finding one member domain among many groups using
only the master's domid. Reboots, migration, suspend/resume and
save/restore all change the domid, making it much more difficult. This
leads me to my next questions...
Migration
---------
What happens when any of the group members migrate? Ditto for
suspend/resume and save/restore. Automatically rebuilding groups after
these events is crucial. So, it would be nice to see preservation of
the group association across the full lifecycle of domains.
Right now groups are an ephemeral object. They are destroyed when the
group master domain is destroyed (or migrated). Groups are easy to
re-compose using a hypercall, and I haven't seen a use case that would
disallow re-composition of groups after a short interval rather than
abosolute persistence. Without the requirement absolute persistence
I'm not sure this too also cannot be best be implemented using tools.
What are you using domain groups for?
Mike
--
Mike D. Day
IBM LTC
Cell: 919 412-3900
Sametime: ncmike@xxxxxxxxxx AIM: ncmikeday Yahoo: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
| 
Home