[xen-tools] Re: difference between xen-shell and argo

[Steve Kemp]

On Sat, Dec 02, 2006 at 11:50:40PM +0100, Henning Sprang wrote:
> On 12/2/06, Steve Kemp <steve at steve.org.uk> wrote:
> >[...]
> >   a)  Argo is dead.
> 
> Any guess when there will be anything useful rewritten version?

  Certainly not until after I've described and considered how
 the rewrite will work.  Maybe a month or two .. maybe more.
 Really hard to say.

> - xen-shell seems to be unique against other available tools because
> it has this possibility to restrict users to a single (is it really a
> single, or is it all domU's that belong to a user? Do you really
> assume each user has exactly one domU? why?) domU

  Yes a single domu belonging to a user.  Basically their SSH login
 name is the name of the domU they control.

  Why?  Because that was what I needed to offer for myself + people
 for the hosting.

  In terms of implementation I have a lot of code which does:

    system( "xm stop $LOGIN" );

  (Or functional equivilents...)

> , and that it applies
> these restrictions to installation/starting/stopping/console access of
> the domU.

  Right.

> Ah, wait, maybe dtc-xen is a similar tools, but it seems a bit
> difficult to setup for these functions, with the dependency against
> dtc itself. Don't know if it has a console, though.

  A lot of the remote management things seem to lack a way of connecting
 to the console, and those that do seem to cheat and basically exec( "xm
 console ..");

  I'm aware of some kind of networking console support for Xen but
 I've not yet seen if it can be used remotely, securely.  One of the
 thigns I want argo to be able to do somehow..

> - argo seems similar to a lot of other tools: virt-manager,
> xenman/convirt, I'm not sure if SuSE Yast and XenEnterprise also have
> similar functions.

  Right.

> And, I think all of them(the argo-similars) ignore the fact that a lot
> of environments need the thing only xen-shell offers - a big machine
> in a big company that is shared by multiple departments does need
> separate logins and permissions for the admins of the departments -
> they are not trusted by the master admin and nedd to have full control
> over all functions of their domains, but not more.

  I'd guess that argo does offer that, in the sense that it can have
 multiple logins each mapping to a machine or two.  xen-shell doesn't
 unless you had "dept1-instance" and shared the login details amongst
 the relevant people.

> But a GUI for xen-shell would be great, and the mentioned
> functionality for xen-shell - to control all systems one owns, which
> can be more than just one on a single point would be great.

  The hard part is passing the console around.  Or setting up
 the shell so that it didn't allow "shutdown", but "name.shutdown"
 or "name2.shutdown" if the user controlled "name" and "name2".

  (Maybe some other syntax such as:

    login ->
      xen-shell$ control instance.one
      xen-shell$ uptime | boot | shutdown | serial | help ..
    [exit]

> Did you think about to unify/merge argo and xen-shell? It sounds like
> just a little bit more is needed in xen-shell, and argo can be
> forgotten - with the result that you have only one project to
> maintain, and not need to implement similar functions twice.
> (please don't hate me for throwing your projects in the trash out of
> misunderstanding the concepts in case I missed something! :) )

  Not at all.  I think that Ward hit the nail on the head by saying
 that Argo offers the ability to offer services remotely via some
 simple protocol whereas xen-shell is essentially a local-only
 tool which does some command processing and essentially runs "system(
 "xm ..." );" for most of its work.

  That seems key.  If you only need something for a single machine
 then the difference is minimal, and is hidden in the background.
 If you want to code something yourself, perhaps a dedicated client
 then Argo really is the more appropriate tool.

  If it turns out that on looking the other systems already do
 offer useful facilities remotely then I might decide to just
 write off argo completely (although I think it would be a neat
 thing to work on) - but I think that adding multi-user and
 especially multi-dom0 support to xen-shell would probably
 be inappropriate.

Steve
--