Ian Pratt
2005-Aug-02 11:10 UTC
[Xen-devel] RE: [Xen-tools] [RFC] xm interface proposed changes
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 ?> * 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 ?> + 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.> 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.> 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 deviceadd/remove (or add/del) might sound a little less brutal than create/destroy.> * 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? Best, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sean Dague
2005-Aug-02 11:32 UTC
[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. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel Hulme
2005-Aug-02 11:39 UTC
Re: [Xen-devel] RE: [Xen-tools] [RFC] xm interface proposed changes
> > * vcpu-enable <DomId> <VCPU> Disable VCPU in a domain. > > + vcpu-disable <DomId> <VCPU> Enable VCPU in a domainYou probably spotted this already, but either the names or the descriptions are the wrong way round. -- Stop the infinite loop, I want to get off! http://surreal.istic.org/ Paraphernalia/Never hides your broken bones,/ And I don''t know why you''d want to try:/ It''s plain to see you''re on your own. -- Paul Simon The documentation that can be written is not the true documentation. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Williamson
2005-Aug-02 13:12 UTC
Re: [Xen-devel] Re: [Xen-tools] [RFC] xm interface proposed changes
> > 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''m inclined to agree with you here; as long as we don''t ever have xm doing any non-virtual things it should be unambiguous. Even then, we could use a "p" prefix (or similar) to denote physical ops in preference. Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Aug 02, 2005 at 12:39:35PM +0100, Daniel Hulme wrote:> > > * vcpu-enable <DomId> <VCPU> Disable VCPU in a domain. > > > + vcpu-disable <DomId> <VCPU> Enable VCPU in a domain > You probably spotted this already, but either the names or the > descriptions are the wrong way round.Right, silly typo from me doing this before I had quite enough coffee. :) -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. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Josh Triplett
2005-Aug-02 23:12 UTC
Re: [Xen-devel] Re: [Xen-tools] [RFC] xm interface proposed changes
On Tue, 2005-08-02 at 07:32 -0400, Sean Dague wrote:> On Tue, Aug 02, 2005 at 12:10:48PM +0100, Ian Pratt wrote: > > > * 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>?How about vcpu-pin? "pin" is a relatively common shorthand for setting affinity.> > > 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.How about attach/detach? - Josh Triplett _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel