[xen-tools] Re: Argo reworking ..

[Neil Wilson]

You may want to look at the implementation of Amazon EC2 tools which
uses Xen as a launch platform for its EC2 machines. EC2 machines are
just domU instances. See
http://developer.amazonwebservices.com/connect/entry.jspa?categoryID=87&externalID=610

Also there is www.aws-console.com which is a graphical launch manager
for starting and monitoring EC2 instances.

It may give you some suggestions as to what others are doing if nothing else.

Rgs

NeilW


On 3/5/07, Steve Kemp <steve at steve.org.uk> wrote:
>
>
>  Over the past few months I've made various comments about Argo
>  being dead, and depreciated pending a redesign/rewrite.
>
>  Now its time to start working upon it in a serious manner.
>  Here are my current thoughts, prior to writing any code.  Here
>  is a good time to:
>
>   - Tell me to use another list.
>   - Help me pick a name.
>   - Offer suggestions, criticisms, or other comments.
>   - Volunteer to write some/all/part of the code.
>
>
>
> Goal
> ----
>
>  The goal of a Xen monitoring and admin solution is for an
>  administrator to be able to gain a global view of a number of
>  Xen hosts (dom0), and manipulate the Xen guests (domU) running
>  upon them.
>
>  The individual guests should allow basic actions to be
>  carried out upon them:
>
>         - starting, stopping, rebooting.
>         - uptime reporting, traffic reporting, disk size reporting.
>
>  More primitives could be added such as "migration", "remote consoles",
>  etc.  However I can live without them initially/indefinitely.
>
>  The key thing is that there should either be a graphical "admin console"
>  or a web interface which may be executed anywhere within the LAN
>  talking to the Xen hosts.
>
>
> Considerations
> --------------
>
>  The system must be able to control multiple dom0  so there must
>  be some form of communication between the control panel and the
>  actual servers.
>
>  There are two ways this could work:
>
>   a)  Each dom0 is contacted individually by the control panel/software.
>       Pros:  Conceptually simple.
>       Cons:  Could be hard to implement.
>
>   b)  Each dom0 broadcasts to a "master server", which
>      is in turn controlled by the control panel/software.
>       Pros:  Each dom0 would be "registered" and lack of "pings" mean it is dead.
>       Pros:  The control panel doesn't have to link to N hosts, just one.
>       Cons:  Additional complexity.
>
>  I think I'm sold on "b".
>
>
> Security
> --------
>
>
>  Previously Argo used plain-text logins and a simple "plaintext"
>  protocol for communication between a single dom0 and a console /
>  GUI / PHP client.
>
>  This was flawed.  Few people commented on implementation, however
>  everybody that did do so complained about plain-text passwords.
>  (I guess some might have been happy with MD5(passwd) but clearly
>  security is important.)
>
>  Since my current plan involves three pieces of software it is
>  good to get the design right.  I see the following components
>  communicating with each other:
>
>   dom0 <-> central-server <-> control panel/software.
>
>  That is:
>
>   - Each dom0 will talk to the central server, giving status
>     information and executing commands.
>
>   - The central server will be the single point of contact for
>     any graphical control applications, or a web GUI.
>
>  I figure that two-way key exchange between the central server and
>  the dom0 agents will be required.
>
>  I also assume that the communication between the central server,
>  and the control GUI will be SSL wrapped.
>
>
> Implementation
> --------------
>
>
>  We require three things:
>
>  1.  A piece of software upon each dom0 which will respond to commands
>     from the central server.  Such as:
>          - start domU foo
>          - list domU
>          - stop all domU
>
>  2.  The central server itself.  This will respond to commands from the
>     control panel such as:
>          - list *all* domU, regardless of host.
>          - list all domU on host bar.
>
>  3.  The control panel / graphical management software.
>          - login to the central server and do things.
>
>  The first two pieces I'm expecting to implement as *tiny* Ruby
>  daemons.  Almost certainly sending and receiving their commands
>  over XML::RPC (+SSL).
>
>  The control panel could be implemented in anything, but my preference
>  would be perl + gtk, or something else "fast" and graphical.  A web
>  control panel might be released as a proof of concept, but I am
>  personally uninterested in its development.
>
>
> Steve
> --
> http://www.steve.org.uk/
>
>
>