WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-tools

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

Attachment: pgplLTZlkHEXE.pgp
Description: PGP signature

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