| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [Xen-tools] [RFC] xm interface proposed changes
On Tue, Aug 02, 2005 at 12:10:48PM +0100, Ian Pratt wrote:
>
> Sean,
>
> Thanks for having a go at this. I've appended a few suggestions in-line.
>
> > ===================================================================
> > ---------XM Proposed-----------------------------------------------
> > help Print help.
> >
> > Commands related to consoles:
> >
> > console <DomId> Open a console to a domain.
> > * console-list Get information about domain consoles.
> >
> > Commands on domains:
> >
> > domid <DomName> Convert a domain name to a domain id.
> > domname <DomId> Convert a domain id to a domain name.
> >
> > create <ConfigFile> Create a domain.
> > destroy <DomId> Terminate a domain immediately.
> > restore <File> Create a domain from a saved state.
> > save <DomId> <File> Save domain state (and config) to file.
> > * shutdown [-w|-a] <DomId> Shutdown a domain.
> > + reboot [-w|-a] <DomId> Reboot a domain.
> >
> > list List information about domains.
> >
> > * 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.
what about mem-limit and mem-set?
>
> > * 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>?
> > + cpus-list <DomId> <VCpu> Get the list of cpus for a VCPU
> > * vcpu-enable <DomId> <VCPU> Disable VCPU in a domain.
> > + vcpu-disable <DomId> <VCPU> Enable VCPU in a domain
> > + vcpu-list <DomId> Get the list of VCPUs for a domain
> >
> > migrate [options] <DomId> <Host> Migrate a domain to another machine.
> >
> > sysrq <DomId> <letter> Send a sysrq to a domain.
> > pause <DomId> Pause execution of a domain.
> > unpause <DomId> Unpause a paused domain.
>
> Perhaps we should list these with the other domain-specific ones e.g.
> shutdown and friends.
Yeh, reclustering the commands is easy.
> > 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.
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.
> > Commands related to virtual block devices:
> >
> > * block-create <DomId> <BackDev> <FrontDev> <Mode>
> > [BackDomId] Create a new virtual block device for a domain
> > * block-destroy <DomId> <DevId> Destroy a domain's virtual
> > block device
>
> add/remove (or add/del) might sound a little less brutal than
> create/destroy.
Yep, good point.
> > * 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". However,
I don't feel all that strongly about it, so whatever you like there is fine.
:) I definitely think vbd and vif need to be deprecated though. I think a
lot of newbie xen users might never figure out what vbd actually stands for.
;)
-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.
__________________________________________________________________
pgpRza67JzpBP.pgp
Description: PGP signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home