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

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

[Ian Pratt]

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 device

add/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

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

[Sean Dague]

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

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

[Mark Williamson]

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

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

[Josh Triplett]

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

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

[Daniel Hulme]

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

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

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

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

Re: RE: [RFC] xm interface proposed changes

[Sean Dague]

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

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

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

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

[Ian Pratt]

 
> It isn't in xm info today.  It could be added, or given it's 
> own place. 
> Honestly, it might make sense to make all the sched commands 
> have a sched- prefix, mostly to make it clear to the user 
> what bvt really is.

Yep, having a sched- prefix is definitely helpful.

Ian

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

[Ian Pratt]

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

That's a fair point about making them too long to type. 

However, its useful to indicate that it is a 'target', and the domain
may not actually be able to relinquish that much memory. Using mem-max
can be a fairly brutal operation if you haven't adjusted the target
first.
 
> what about mem-limit and mem-set?

mem-max and mem-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 ?
> 
> 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>?

It's a propery of the vcpu. Perhaps vcpu-affinity ?
vcpu-set isn't too bad.

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

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

Yep. I think (hope?) 'xm info' reports this.

> > > * 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".  

I was thinking 'v' as we needed it for vcpu. Not sure if we may have
similar controls for setting up 'physical' networking in future e.g.
tweaking the bridge setup. My inclination would be for vblock and
vnetif, but I'll go with flow...

Ian

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

[Mark Williamson]

> > 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.
>
> Yep. I think (hope?) 'xm info' reports this.

Not last time I checked.  There is a dom0 op that gets the current sched ID 
(although not a textual name, so some kind of mapping needs to be done).  I 
guess this could either be rolled into the info ops, or extended in place.  
Either makes sense.

Cheers,
Mark

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

[Sean Dague]

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

On Tue, Aug 02, 2005 at 02:17:00PM +0100, Mark Williamson wrote:
> > > 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.
> >
> > Yep. I think (hope?) 'xm info' reports this.
> 
> Not last time I checked.  There is a dom0 op that gets the current sched ID 
> (although not a textual name, so some kind of mapping needs to be done).  I 
> guess this could either be rolled into the info ops, or extended in place.  
> Either makes sense.

It isn't in xm info today.  It could be added, or given it's own place. 
Honestly, it might make sense to make all the sched commands have a sched-
prefix, mostly to make it clear to the user what bvt really is.

	-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

[RFC] xm interface proposed changes

[Sean Dague]

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

In order to have this discussion in a structured way, we should figure out
how we want commands structured in general (i.e. where is the verb).

It seems the following policy would be mostly in line with the existing
command set.

If the command direct object is a xen domain (it does something directly to
a domain core) then we use "verb" (i.e. create, destroy, save...).  If the
command direct object is a part of a domain, like a block device or memory,
we use "object-verb", mostly so the object commands cluster in a directly
command listing.  Examples today would be "vbd-list" for instance.  If there
is a difference of opinion here, we should hammer that out first, because
the rest of the discussion is pretty pointless without at least these ground
rules. :)

To make this easier, here is the command help today (with attributes added
in to each command).

=========================================================================
---------XM HELP TODAY---------------------------------------------------
call                Call xend api functions
help                Print help.

Commands related to consoles:

console <DomainId>  Open a console to a domain.
consoles            Get information about domain consoles.

Commands on domains:

balloon <DomainId> <Mem>  Set the domain's memory footprint using the balloon driver.
create <ConfigFile>       Create a domain.
destroy <DomainId>        Terminate a domain immediately.
domid   <DomainName>      Convert a domain name to a domain id.
domname <DomainId>        Convert a domain id to a domain name.
list                      List information about domains.
maxmem <DomainId> <Mem>   Set domain memory limit.
migrate [options] <DomId> <Host> Migrate a domain to another machine.
pause  <DomainId>         Pause execution of a domain.
pincpu <DomId> <VCpu> <CPUS>    Set which cpus a VCPU can use. 
restore <File>            Create a domain from a saved state.
save    <DomId> <File>    Save domain state (and config) to file.
shutdown [options] <DomId>  Shutdown a domain.
sysrq   <DomId> <letter>    Send a sysrq to a domain.
unpause <DomId>           Unpause a paused domain.
vcpu-hotplug <DomId> <VCPU> <0|1> Enable or disable a VCPU in a domain.

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.

Commands related to virtual block devices:

vbd-create <DomId> <BackDev> <FrontDev> <Mode> [BackDomId]    Create a new virtual block device for a domain
vbd-destroy <DomId> <DevId>  Destroy a domain's virtual block device
vbd-list    <DomId>          List virtual block devices for a domain.
vbd-refresh <DomId> <DevId>  Refresh a virtual block device for a domain

Commands related to virtual network interfaces:

vif-limit   <DomId> <Vif> <Credit> <Period> Limit the transmission rate of a virtual network interface.
vif-list    <DomId> List virtual network interfaces for a domain.

Try '/usr/sbin/xm help CMD' for help on CMD
-------------------------------------------------------------------



The following is a proposed set of changes based on the "obj-verb" paradigm,
plus trying to make commands make more sense to a user that may not know
things about Xen internals.  Commands that have renames are marked with (*),
commands that are "new" to create what seems like a complete interface are
marked with (+).

===================================================================
---------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.
* cpus-set <DomId> <VCpu> <CPUS>    Set which cpus a VCPU can use. 
+ 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.

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.

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

Try '/usr/sbin/xm help CMD' for help on CMD
-----------------------------------------------------------------



Additionally, if we are to move to a model where command aliasing can easily
be done (for backwards compatibility), I actually think we need to majorly
restructure main.py from an object based model to a declaritive model, where
main() would be a dispatcher to possibly many functions that would be the
equiv of the main methods in each object today.  I also believe that this is
the only way to get 'xm help' to run as non-root, which I consider a goal. 
I'd like at least tenative approval for this idea before I code it up, but I
am *willing to volunteer* for this conversion of main.py from object based
-> declaritive structure.

Comments welcome, flame away.

	-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

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

[harry]

I think you should move towards a model where the tools dynamically
discover the available configuration commands from components which are
installed in the system such that the tools eventually contain no
command specific code at all.

For example, on installation, the balloon driver might register itself
as a configurable component which provided a single configuration action
called (for the sake of argument) resize.  When the balloon driver was
installed in a domain, the configuration tools would discover the
balloon driver as a new configurable sub-object belonging to the domain
and query the registered configuration interface to discover the resize
method, the help text, the parameter types and the valid parameter
range.

Subsequent invocations of xm-help would list the domain-balloon-resize
method with an indication of the parameters and help text.

A mechanism like this would allow 3rd parties to extend the system
without having to modify the low-level configuration tools. Having the
entire specification and implementation of the configuration interface
in a single location (in the example, the balloon driver code) also
makes it easier to avoid incompatibilities between the tools and
configurable components since there is less coupling. In fact, the level
of coupling has been shifted from the component specific details of the
configuration interface to the component-independent aspects of the
mechanism for specifying interfaces.

I think this would naturally tend towards an object-verb form of
expression since this would be consistent with the discovery process.

Harry.

On Fri, 2005-07-29 at 09:04 -0400, Sean Dague wrote:
> In order to have this discussion in a structured way, we should figure out
> how we want commands structured in general (i.e. where is the verb).
> 
> It seems the following policy would be mostly in line with the existing
> command set.
> 
> If the command direct object is a xen domain (it does something directly to
> a domain core) then we use "verb" (i.e. create, destroy, save...).  If the
> command direct object is a part of a domain, like a block device or memory,
> we use "object-verb", mostly so the object commands cluster in a directly
> command listing.  Examples today would be "vbd-list" for instance.  If there
> is a difference of opinion here, we should hammer that out first, because
> the rest of the discussion is pretty pointless without at least these ground
> rules. :)
> 
> To make this easier, here is the command help today (with attributes added
> in to each command).
> 
> =========================================================================
> ---------XM HELP TODAY---------------------------------------------------
> call                Call xend api functions
> help                Print help.
> 
> Commands related to consoles:
> 
> console <DomainId>  Open a console to a domain.
> consoles            Get information about domain consoles.
> 
> Commands on domains:
> 
> balloon <DomainId> <Mem>  Set the domain's memory footprint using the balloon driver.
> create <ConfigFile>       Create a domain.
> destroy <DomainId>        Terminate a domain immediately.
> domid   <DomainName>      Convert a domain name to a domain id.
> domname <DomainId>        Convert a domain id to a domain name.
> list                      List information about domains.
> maxmem <DomainId> <Mem>   Set domain memory limit.
> migrate [options] <DomId> <Host> Migrate a domain to another machine.
> pause  <DomainId>         Pause execution of a domain.
> pincpu <DomId> <VCpu> <CPUS>    Set which cpus a VCPU can use. 
> restore <File>            Create a domain from a saved state.
> save    <DomId> <File>    Save domain state (and config) to file.
> shutdown [options] <DomId>  Shutdown a domain.
> sysrq   <DomId> <letter>    Send a sysrq to a domain.
> unpause <DomId>           Unpause a paused domain.
> vcpu-hotplug <DomId> <VCPU> <0|1> Enable or disable a VCPU in a domain.
> 
> 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.
> 
> Commands related to virtual block devices:
> 
> vbd-create <DomId> <BackDev> <FrontDev> <Mode> [BackDomId]    Create a new virtual block device for a domain
> vbd-destroy <DomId> <DevId>  Destroy a domain's virtual block device
> vbd-list    <DomId>          List virtual block devices for a domain.
> vbd-refresh <DomId> <DevId>  Refresh a virtual block device for a domain
> 
> Commands related to virtual network interfaces:
> 
> vif-limit   <DomId> <Vif> <Credit> <Period> Limit the transmission rate of a virtual network interface.
> vif-list    <DomId> List virtual network interfaces for a domain.
> 
> Try '/usr/sbin/xm help CMD' for help on CMD
> -------------------------------------------------------------------
> 
> 
> 
> The following is a proposed set of changes based on the "obj-verb" paradigm,
> plus trying to make commands make more sense to a user that may not know
> things about Xen internals.  Commands that have renames are marked with (*),
> commands that are "new" to create what seems like a complete interface are
> marked with (+).
> 
> ===================================================================
> ---------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.
> * cpus-set <DomId> <VCpu> <CPUS>    Set which cpus a VCPU can use. 
> + 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.
> 
> 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.
> 
> 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
> * 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.
> 
> Try '/usr/sbin/xm help CMD' for help on CMD
> -----------------------------------------------------------------
> 
> 
> 
> Additionally, if we are to move to a model where command aliasing can easily
> be done (for backwards compatibility), I actually think we need to majorly
> restructure main.py from an object based model to a declaritive model, where
> main() would be a dispatcher to possibly many functions that would be the
> equiv of the main methods in each object today.  I also believe that this is
> the only way to get 'xm help' to run as non-root, which I consider a goal. 
> I'd like at least tenative approval for this idea before I code it up, but I
> am *willing to volunteer* for this conversion of main.py from object based
> -> declaritive structure.
> 
> Comments welcome, flame away.
> 
> 	-Sean
> 
> _______________________________________________
> Xen-tools mailing list
> Xen-tools@lists.xensource.com
> http://lists.xensource.com/xen-tools

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

[Sean Dague]

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

On Fri, Jul 29, 2005 at 03:25:04PM +0100, harry wrote:
> I think you should move towards a model where the tools dynamically
> discover the available configuration commands from components which are
> installed in the system such that the tools eventually contain no
> command specific code at all.
> 
> For example, on installation, the balloon driver might register itself
> as a configurable component which provided a single configuration action
> called (for the sake of argument) resize.  When the balloon driver was
> installed in a domain, the configuration tools would discover the
> balloon driver as a new configurable sub-object belonging to the domain
> and query the registered configuration interface to discover the resize
> method, the help text, the parameter types and the valid parameter
> range.
> 
> Subsequent invocations of xm-help would list the domain-balloon-resize
> method with an indication of the parameters and help text.
> 
> A mechanism like this would allow 3rd parties to extend the system
> without having to modify the low-level configuration tools. Having the
> entire specification and implementation of the configuration interface
> in a single location (in the example, the balloon driver code) also
> makes it easier to avoid incompatibilities between the tools and
> configurable components since there is less coupling. In fact, the level
> of coupling has been shifted from the component specific details of the
> configuration interface to the component-independent aspects of the
> mechanism for specifying interfaces.
> 
> I think this would naturally tend towards an object-verb form of
> expression since this would be consistent with the discovery process.
> 
> Harry.

I actually think this is exactly the opposite from what we want, and is
actually what is in there now and makes it such a mess.

Let's look at xm help, for instance.  In order to run xm help, which you
think would be simple, you have to import about 10 objects for every feature
that xm could possibly support, if any of these fail you die.  Then you need
to instantiate classes for every sub command, if any of these fail, you die. 
Then you run through each object, figure out what group it is in, pull help
from each object, and stick that together.  If anything fails here, you die.

The real rub is that those 10 imported objects, all import their own
objects, etc.  If any of those fail, you die.  A really good instance is
"why can't I run xm help as none root?".  Because xm needs write access to
the xend log files (buried about 5 object imports down).  You can't seperate
that out in any reasonable way to check permissions upfront.  You can't move
the imports into main() to trap there, because all the 20 classes for each
command expect those objects to be global in main.py to operate on them.

So lets say you end up with a model where you *can* catch each object
failure, what do you do?  Do you quietly turn off/on options based on what
is there?  That means the interface of xm would change day to day.  I'd hate
to have to answer support questions on that. :)

While quite interesting from an engineering elegance point of view, it is
quite problematic from a user point of view.  xm help should provide the
same set of options this morning and this afternoon, unless I very
intentionally upgraded the program.  Additionally the future architecture is
really centered on xenstore as the management interface.  I don't think
integrating every possible usage of xenstore into xm/xend is the right
approach.

I think this needs to take a much more user centric, Model-View-Controler
approach.  Forcing the User Interface to be a direct reflection of how we
happen to have objects underneath usually just causes no end of usability
(and maintenance) pain.

Such is my 2 cents.

	-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

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

[Ronald G. Minnich]

On Fri, 29 Jul 2005, Sean Dague wrote:

> On Fri, Jul 29, 2005 at 03:25:04PM +0100, harry wrote:
> > ... interesting ideas. 
> >
> > I think this would naturally tend towards an object-verb form of
> > expression since this would be consistent with the discovery process.
> > 
> > Harry.
> 
> I actually think this is exactly the opposite from what we want, and is
> actually what is in there now and makes it such a mess.
> 
> I think this needs to take a much more user centric, Model-View-Controler
> approach.  

I think I'm with sean on this one. 

ron

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

[harry]

On Fri, 2005-07-29 at 08:54 -0600, Ronald G. Minnich wrote:

> > I think this needs to take a much more user centric, Model-View-Controler
> > approach.  
> 
> I think I'm with sean on this one. 

Well, I don't think anything I said is incompatible with a
model-view-controller approach so I'm probably with Sean on that one
too.

Harry.

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

[harry]

On Fri, 2005-07-29 at 10:44 -0400, Sean Dague wrote:
> On Fri, Jul 29, 2005 at 03:25:04PM +0100, harry wrote:
>> <big snip>
> I actually think this is exactly the opposite from what we want, and is
> actually what is in there now and makes it such a mess.

No, it's not remotely what's in there now.  Right now, the configuration
tools contain a lot of explicit knowledge about the system.  In fact,
every single aspect of the system has part of its function in the python
tools.  This is why the tools are a mess.

I'm saying relocate all of that back to the individual components which
are to be configured such that each individual configurable aspect has
both the implementation of the function and the configuration interface
in once place rather than split into two with half in python.

This would leave the configuration tools as a combination of a discovery
mechanism and a simple pipe from the command line to the component to be
configured.

> 
> Let's look at xm help, for instance.  In order to run xm help, which you
> think would be simple, you have to import about 10 objects for every feature
> that xm could possibly support, if any of these fail you die.  Then you need
> to instantiate classes for every sub command, if any of these fail, you die. 
> Then you run through each object, figure out what group it is in, pull help
> from each object, and stick that together.  If anything fails here, you die.

That's just crap implementation.  The basic idea is vaguely correct.
There's no good reason for any of this to fail so failure simply
shouldn't be an option.

> 
> The real rub is that those 10 imported objects, all import their own
> objects, etc.  If any of those fail, you die.  A really good instance is
> "why can't I run xm help as none root?".  Because xm needs write access to
> the xend log files (buried about 5 object imports down).  You can't seperate
> that out in any reasonable way to check permissions upfront.  You can't move
> the imports into main() to trap there, because all the 20 classes for each
> command expect those objects to be global in main.py to operate on them.
> 
> So lets say you end up with a model where you *can* catch each object
> failure, what do you do?  Do you quietly turn off/on options based on what
> is there?  That means the interface of xm would change day to day.  I'd hate
> to have to answer support questions on that. :)

In the previous note, I proposed that the xm interface reflect the
components which were explicitly active.  A compromise would be for the
xm interface to reflect the installed components rather than those that
were explicitly active. With this compromise, a new component would have
two parts: a configuration plug-in and an active implementation of the
component.  Xm would discover the installed configuration plug-ins. This
would still be relatively easy to extend and maintain compared to the
current monolithic system.

> 
> While quite interesting from an engineering elegance point of view, it is
> quite problematic from a user point of view.  xm help should provide the
> same set of options this morning and this afternoon, unless I very
> intentionally upgraded the program.  Additionally the future architecture is
> really centered on xenstore as the management interface.  I don't think
> integrating every possible usage of xenstore into xm/xend is the right
> approach.

I would say that xm help should reflect what I could currently do with
the system, not what would be possible if I downloaded and installed
every single possible 3rd party extension.

I don't understand what you mean by "integrating every possible usage of
xenstore into xm/xend".  I wouldn't want anything in xm/xend apart from
the generic pipe and discovery mechanism mentioned above.

> 
> I think this needs to take a much more user centric, Model-View-Controler
> approach.  Forcing the User Interface to be a direct reflection of how we
> happen to have objects underneath usually just causes no end of usability
> (and maintenance) pain.

With either extensible proposal, the user interface doesn't need to be a
reflection of the low-level underlying objects.  Each installable
component gets to design whatever user interface is appropriate to best
configure its functionality.  If components are independent then
reflection of underlying objects in the interface is natural at the
component level and if they are not independent there's no reason why
they can't have a common configuration component which provides a
spanning configuration model.

Also, we are talking about the lowest level configuration interface here
which in practise will be an internal interface between the system
components and a higher level user GUI. So, I think there is a slightly
different trade-off desired here than ultimate ease-of-use.

In particular, it is required that the system support 3rd party
extensions and I think it will prove essential that integrating
configuration and help support for those extensions should avoid a
dependency on changes to the low-level tools and serialisation through a
single maintainer.

Harry

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

[Sean Dague]

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

On Fri, Jul 29, 2005 at 04:28:56PM +0100, harry wrote:
> On Fri, 2005-07-29 at 10:44 -0400, Sean Dague wrote:
> > On Fri, Jul 29, 2005 at 03:25:04PM +0100, harry wrote:
> >> <big snip>
> > I actually think this is exactly the opposite from what we want, and is
> > actually what is in there now and makes it such a mess.
> 
> No, it's not remotely what's in there now.  Right now, the configuration
> tools contain a lot of explicit knowledge about the system.  In fact,
> every single aspect of the system has part of its function in the python
> tools.  This is why the tools are a mess.
> 
> I'm saying relocate all of that back to the individual components which
> are to be configured such that each individual configurable aspect has
> both the implementation of the function and the configuration interface
> in once place rather than split into two with half in python.
> 
> This would leave the configuration tools as a combination of a discovery
> mechanism and a simple pipe from the command line to the component to be
> configured.
> 
> > 
> > Let's look at xm help, for instance.  In order to run xm help, which you
> > think would be simple, you have to import about 10 objects for every feature
> > that xm could possibly support, if any of these fail you die.  Then you need
> > to instantiate classes for every sub command, if any of these fail, you die. 
> > Then you run through each object, figure out what group it is in, pull help
> > from each object, and stick that together.  If anything fails here, you die.
> 
> That's just crap implementation.  The basic idea is vaguely correct.
> There's no good reason for any of this to fail so failure simply
> shouldn't be an option.

First rule of software, things always fail.  There are plenty of reasons for
things to fail.  A daemon died somewhere along the way, you ran out of
resources to run in, you didn't have enough permissions, etc.

If the software can't detect a failure in a useful way, and regroup then I
certainly wouldn't run it on my network, and I definitely wouldn't trust it
to run my virtual machines.

> > The real rub is that those 10 imported objects, all import their own
> > objects, etc.  If any of those fail, you die.  A really good instance is
> > "why can't I run xm help as none root?".  Because xm needs write access to
> > the xend log files (buried about 5 object imports down).  You can't seperate
> > that out in any reasonable way to check permissions upfront.  You can't move
> > the imports into main() to trap there, because all the 20 classes for each
> > command expect those objects to be global in main.py to operate on them.
> > 
> > So lets say you end up with a model where you *can* catch each object
> > failure, what do you do?  Do you quietly turn off/on options based on what
> > is there?  That means the interface of xm would change day to day.  I'd hate
> > to have to answer support questions on that. :)
> 
> In the previous note, I proposed that the xm interface reflect the
> components which were explicitly active.  A compromise would be for the
> xm interface to reflect the installed components rather than those that
> were explicitly active. With this compromise, a new component would have
> two parts: a configuration plug-in and an active implementation of the
> component.  Xm would discover the installed configuration plug-ins. This
> would still be relatively easy to extend and maintain compared to the
> current monolithic system.
> 
> > 
> > While quite interesting from an engineering elegance point of view, it is
> > quite problematic from a user point of view.  xm help should provide the
> > same set of options this morning and this afternoon, unless I very
> > intentionally upgraded the program.  Additionally the future architecture is
> > really centered on xenstore as the management interface.  I don't think
> > integrating every possible usage of xenstore into xm/xend is the right
> > approach.
> 
> I would say that xm help should reflect what I could currently do with
> the system, not what would be possible if I downloaded and installed
> every single possible 3rd party extension.
> 
> I don't understand what you mean by "integrating every possible usage of
> xenstore into xm/xend".  I wouldn't want anything in xm/xend apart from
> the generic pipe and discovery mechanism mentioned above.
> 
> > 
> > I think this needs to take a much more user centric, Model-View-Controler
> > approach.  Forcing the User Interface to be a direct reflection of how we
> > happen to have objects underneath usually just causes no end of usability
> > (and maintenance) pain.
> 
> With either extensible proposal, the user interface doesn't need to be a
> reflection of the low-level underlying objects.  Each installable
> component gets to design whatever user interface is appropriate to best
> configure its functionality.  If components are independent then
> reflection of underlying objects in the interface is natural at the
> component level and if they are not independent there's no reason why
> they can't have a common configuration component which provides a
> spanning configuration model.
> 
> Also, we are talking about the lowest level configuration interface here
> which in practise will be an internal interface between the system
> components and a higher level user GUI. So, I think there is a slightly
> different trade-off desired here than ultimate ease-of-use.

Calling a python program the lowest level interface means we clearly have
different definitions of lowest. ;)  libxenstore is the low level interface,
xm & xend is a user interface.
 
> In particular, it is required that the system support 3rd party
> extensions and I think it will prove essential that integrating
> configuration and help support for those extensions should avoid a
> dependency on changes to the low-level tools and serialisation through a
> single maintainer.
> 
> Harry

	-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