| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home