Xen devel - Aug 2005 - RE: [Xen-tools] [RFC] xm interface proposed changes

> > > * mem-max <DomId> <Mem>             Set domain
maximum
> memory limit.
> > > * mem-set <DomId> <Mem>             Set the
domain''s memory
> > > dynamically.
> > 
> > I think this should be mem-set-max and mem-set-target ?
> 
> My only concern is that those are getting pretty long to type 
> out, and I''m not sure that -target helps clarify.
That''s a fair point about making them too long to type. 

However, its useful to indicate that it is a ''target'', and the
domain
may not actually be able to relinquish that much memory. Using mem-max
can be a fairly brutal operation if you haven''t adjusted the target
first.
 
> what about mem-limit and mem-set?
mem-max and mem-target ?
> > 
> > > * cpus-set <DomId> <VCpu> <CPUS>    Set which
cpus a VCPU
> can use. 
> > 
> > I''m not sure about this one, but an struggling to think of
anything
> > better.
> > cpu-set-affinity ?
> 
> Yeh, I was scratching my head a lot on this one too.  Trying 
> to brainstorm now (help in this regard would be good):
> 
> cpu-allocate <DomId> <VCpu> <CPUS>?
> vcpu-set <DomId> <VCpu> <CPUS>?
It''s a propery of the vcpu. Perhaps vcpu-affinity ?
vcpu-set isn''t too bad.
> > > Commands related to the xen host (node):
> > > 
> > > dmesg   [--clear]         Read or clear Xen''s message
buffer.
> > > info                      Get information about the xen host.
> > > log                       Print the xend log.
> > > 
> > > Comands controlling scheduling:
> > > 
> > > bvt DOM MCUADV WARPBACK WARPVALUE WARPL WARPU   Set BVT 
> > > scheduler parameters.
> > > bvt_ctxallow CTX_ALLOW                          Set the BVT 
> > > scheduler context switch allowance.
> > > sedf DOM PERIOD SLICE LATENCY EXTRATIME WEIGHT  Set simple EDF 
> > > parameters.
> > 
> > It would be nice to list only the ones for the currenty active 
> > scheduler, or at least have it such that the commands fail if the 
> > scheduler isn''t in use.
> 
> I 100% agree.  It is actually sort of amazing how many 
> commands can fail but don''t return error codes right now.  
> I''m hoping to fix that.
Excellent.
 
> sched-list might be useful to also expose the current 
> scheduler, and provide a graceful failure message if you try 
> to run a command for the wrong one.
Yep. I think (hope?) ''xm info'' reports this.
> > > * block-list    <DomId>          List virtual block devices
> > > for a domain.
> > > * block-refresh <DomId> <DevId>  Refresh a virtual
block
> device for 
> > > a domain
> > > 
> > > Commands related to virtual network interfaces:
> > > 
> > > * network-limit   <DomId> <Vif> <Credit>
<Period> Limit the
> > > transmission rate of a virtual network interface.
> > > * network-list    <DomId> List virtual network interfaces
for
> > > a domain.
> > 
> > We should have commands for network-add and network-del.
> > 
> > In fact, are network and block the right nouns? 
> > Would vblock/vnetif be better?
> 
> It seems to me that network and block are known concepts, and 
> the user is already in a virtual control environment, so the 
> "virtual" part should be implied by the fact that you are 
> running xm in the first place.  So I would lean towards 
> network or netif and block directly without the "v".  
I was thinking ''v'' as we needed it for vcpu. Not sure if we
may have
similar controls for setting up ''physical'' networking in
future e.g.
tweaking the bridge setup. My inclination would be for vblock and
vnetif, but I''ll go with flow...

Ian


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

> > sched-list might be useful to also expose the current
> > scheduler, and provide a graceful failure message if you try
> > to run a command for the wrong one.
>
> Yep. I think (hope?) ''xm info'' reports this.
Not last time I checked.  There is a dom0 op that gets the current sched ID 
(although not a textual name, so some kind of mapping needs to be done).  I 
guess this could either be rolled into the info ops, or extended in place.  
Either makes sense.

Cheers,
Mark

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

On Tue, Aug 02, 2005 at 02:17:00PM +0100, Mark Williamson
wrote:
> > > sched-list might be useful to also expose the current
> > > scheduler, and provide a graceful failure message if you try
> > > to run a command for the wrong one.
> >
> > Yep. I think (hope?) ''xm info'' reports this.
> 
> Not last time I checked.  There is a dom0 op that gets the current sched ID
> (although not a textual name, so some kind of mapping needs to be done).  I
> guess this could either be rolled into the info ops, or extended in place.
> Either makes sense.
It isn''t in xm info today.  It could be added, or given it''s
own place.
Honestly, it might make sense to make all the sched commands have a sched-
prefix, mostly to make it clear to the user what bvt really is.

	-Sean

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________


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