Edward Pilatowicz wrote: > hey max, > > so zones already has a standard terminology for creating caps and > reservations on various resources. this functionality is documented in > the following arc cases: > > PSARC/2006/496 Improved Zones/RM Integration > PSARC/2004/402 CPU caps > > to sum up the terminology, a resource cap is specified as "capped-XXX" > and a resource reservation is specified as "dedicated-XXX", where XXX is > the resource. currently zones supports caps and reservations for memory > and cpu, but this terminology was designed to allow for easy future > enhancements like network caps and reservations. > > since you're going to be introducing new network bandwidth cap mechanism > for xvm, it'd be really nice if we could try to keep the naming > conventions consistent between xvm and zones. hence, i was thinking > that instead of "rate" (which is actually pretty pretty vague, how do i > know that this doesn't set a reservation instead of a cap?) you could > use "capped-bandwidth". this update would apply to the "--rate" option > to virt-install/virsh, the "rate" option to xm, and the internal xml > storage format. > > if there is already a convention on other xen based platforms for a > "rate" option, then instead of eliminating that option, it would > probably make sense to add a "capped-bandwidth" option, make "rate" an > alias for "capped-bandwidth", and only document the "capped-bandwidth" > option on solaris. > Thanks Ed! I think 'capped-bandwidth' is a better name for 'rate'. I'll apply this name to virsh/virt-install and the related XMLformat. But, I intend to keep using 'rate' in 'xm' command since: + it is already there + virsh is the way to go, we don't encourage people to use 'xm' in the future, so minimize our maintenance burden seems to be more important here. How does that sound?
Max > thanks > ed >
