[Xen-devel] Re: [Xen-tools] [RFC] xm interface proposed changes
On Tue, Aug 02, 2005 at 12:10:48PM +0100, Ian Pratt wrote:
> 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
> 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
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 Dague Mid-Hudson Valley
sean at dague dot net Linux Users Group
There is no silver bullet. Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
Description: PGP signature
Xen-devel mailing list