[Xen-devel] Re: 0/4 Xen Scheduling Groups

[Chris <hap10@xxxxxxxxxxxxxx>]

Mike D. Day wrote:
>> 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.

Agreed.  The vast majority of the implementation should be in the tools.
 As a matter identifying groups from within the VMM, it is important for
groups to have a uuid in the VMM.  It is useful for the VMM to know that
a migrated group is indeed the same as the original.

>> 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.

Much of my rational for persistence is an effort to reduce burden on
system administrators.  Although manually reconstructing groups is easy
with few small groups, it still creates extra work.  Consider life as an
data center administrator with upcoming planned downtime.  When
migrating a rack full of domains, the administrator doesn't want to
remember which domains belong together.  Migration of the entire group
as a single unit is a major win for the administrator in terms of
reducing the number of moving parts he has to care about.

Another reason for making groups a first class object is that the
administrator doesn't need to care which scheduler the migration target
VMM is using.

> What are you using domain groups for?

We're building a virtualization platform in which groups play a central
role.  Not too long ago I submitted a set of patches with a generic
domain group implementation that strives to address the issues I've
begun to raise.

Scheduling is a natural place for groups.  Groups are also applicable to
security policy.  VMM support for a generic group abstraction allows
simplifications of the security policy and the architecture that
supports it.  I believe groups provide the biggest value as a generic
abstraction that's flexible enough for many purposes.

-Chris

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel