From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Dague Subject: Re: [Xen-tools] [RFC] xm interface proposed changes Date: Tue, 2 Aug 2005 07:32:46 -0400 Message-ID: <20050802113246.GA13850@underhill.no-ip.org> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0938959958==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: xen-tools@lists.xensource.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============0938959958== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 12:10:48PM +0100, Ian Pratt wrote: >=20 > Sean, >=20 > Thanks for having a go at this. I've appended a few suggestions in-line. > =20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ---------XM Proposed----------------------------------------------- > > help Print help. > >=20 > > Commands related to consoles: > >=20 > > console Open a console to a domain. > > * console-list Get information about domain consoles. > >=20 > > Commands on domains: > >=20 > > domid Convert a domain name to a domain id. > > domname Convert a domain id to a domain name. > >=20 > > create Create a domain. > > destroy Terminate a domain immediately. > > restore Create a domain from a saved state. > > save Save domain state (and config) to file. > > * shutdown [-w|-a] Shutdown a domain. > > + reboot [-w|-a] Reboot a domain. > >=20 > > list List information about domains. > >=20 > > * mem-max Set domain maximum memory limit. > > * mem-set Set the domain's memory=20 > > dynamically. >=20 > 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? >=20 > > * cpus-set Set which cpus a VCPU can use.=20 >=20 > I'm not sure about this one, but an struggling to think of anything > better.=20 > 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 ? vcpu-set ? > > + cpus-list Get the list of cpus for a VCPU > > * vcpu-enable Disable VCPU in a domain. > > + vcpu-disable Enable VCPU in a domain > > + vcpu-list Get the list of VCPUs for a domain > >=20 > > migrate [options] Migrate a domain to another machine. > >=20 > > sysrq Send a sysrq to a domain. > > pause Pause execution of a domain. > > unpause Unpause a paused domain. >=20 > 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): > >=20 > > dmesg [--clear] Read or clear Xen's message buffer. > > info Get information about the xen host. > > log Print the xend log. > >=20 > > Comands controlling scheduling: > >=20 > > bvt DOM MCUADV WARPBACK WARPVALUE WARPL WARPU Set BVT=20 > > scheduler parameters. > > bvt_ctxallow CTX_ALLOW Set the BVT=20 > > scheduler context switch allowance. > > sedf DOM PERIOD SLICE LATENCY EXTRATIME WEIGHT Set simple=20 > > EDF parameters. >=20 > 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: > >=20 > > * block-create =20 > > [BackDomId] Create a new virtual block device for a domain > > * block-destroy Destroy a domain's virtual=20 > > block device >=20 > add/remove (or add/del) might sound a little less brutal than > create/destroy. Yep, good point. > > * block-list List virtual block devices=20 > > for a domain. > > * block-refresh Refresh a virtual block=20 > > device for a domain > >=20 > > Commands related to virtual network interfaces: > >=20 > > * network-limit Limit the=20 > > transmission rate of a virtual network interface. > > * network-list List virtual network interfaces for=20 > > a domain. >=20 > We should have commands for network-add and network-del. >=20 > In fact, are network and block the right nouns?=20 > 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 --=20 __________________________________________________________________ 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. __________________________________________________________________ --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFC71neSamXem9TdyYRAriDAKCGtul25gxoqQO5R3BJ9EGOy26N1ACfUFxS bEIGT55A2yKp5+Rie78ZQMA= =PvUj -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- --===============0938959958== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0938959958==--