Re: [Xen-tools] [RFC] xm interface proposed changes

[Sean Dague <sean@dague.net>]

[-- Attachment #1.1: Type: text/plain, Size: 5597 bytes --]

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.
__________________________________________________________________

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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