All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Bainbridge <chris.bainbridge@gmail.com>
To: Xen development list <xen-devel@lists.xensource.com>
Subject: Re: xendomains init script
Date: Thu, 27 Oct 2005 15:16:31 +0000	[thread overview]
Message-ID: <623652d50510270816o267337cn@mail.gmail.com> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D32E60C@liverpoolst.ad.cl.cam.ac.uk>

On 27/10/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> It would be good if you could write a few notes to describe what the
> runes you use to start screen are, and whether you think it makes sense
> to integrate this with 'xm'?

Ok, this sequence will create a single screen session with a dom0
window, then opens a named window for each domU. The screen is
initially detached (ie. you can't see it), you can attach to it with
screen -r or screen -x. You then see all of your domains as windows
(ctrl-a " for a list).

> > start() {
> >         einfo "Starting ${AUTODIR} Xen domains"
> >         if [[ ${SCREEN} == "yes" ]]; then
> >                 screen -d -m -S xen -t dom0

"-d -m"        start screen session, but do not attach to it
"-S xen"      call the session "xen"
"-t dom0"    sets the title of the initial console - this will be a
normal terminal on dom0.

> >                 screen -r xen -X zombie dr

"-r xen"    name of session
"-X"         send a command
"zombie dr"    the command. By default,  a window closes when it's
process dies. This changes that so windows remain persistent, so you
can see xen domains reboot etc. The d and r keys are shortcuts to
destroy/resurrect the window process, at the time it seemed like a
good idea to be able to hit "r" in the console window and restart the
domain.

> >                 logrotate -f /usr/share/xen/xen-consoles-logrotate

force a run of a logrotate script which rotates the files in
/var/log/xen-consoles/

> >                 screen -r xen -X logfile /var/log/xen-consoles/%t

send a command to session "xen". logfile specifies a generic filename,
%t is replaced with the name of the window for each domainU session.

> >                 screen -r xen -X logfile flush 1

flush the log every second

> >                 screen -r xen -X deflog on

turn on logging by default

> >         fi
> >         # Create all domains with config files in AUTODIR.
> >         for dom in $(ls ${AUTODIR}/* 2>/dev/null); do
> >                 name=$(get_domname ${dom})
> >                 if ! is_running ${name} ; then
> >                         ebegin "  Starting domain ${name}"
> >                         if [[ ${SCREEN} == "yes" ]]; then
> >                                 screen -r xen -X screen -t
> > ${name} xm create ${dom} -c

"screen -r xen"    select screen called "xen"
"-X screen -t name"    run internal screen command "screen -t name"
which creates a window with the given name, and runs "xm create
/etc/xen/auto/dom -c" inside that window

On stop():     screen -r xen -X quit

This closes the screen session called "xen".

Does it make sense to integrate this with xm? I think so, since then
you can have a console screen session for any domain, not just ones
you autostart. Also it multiplexes access to the console - I'm not
sure what happens if two users run "xm console" at the same time? I
don't think it works. The console logs are useful for viewing domain
crashes and other things that don't make it to syslog. And it's nice
to be able to reboot in a window and see the full shutdown and
startup.

Regards,
Chris

  reply	other threads:[~2005-10-27 15:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-27 14:15 xendomains init script Ian Pratt
2005-10-27 15:16 ` Chris Bainbridge [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-10-26 19:05 Ian Pratt
2005-10-26 23:35 ` Chris Bainbridge
2005-10-19  9:44 Kurt Garloff
2005-10-26 17:11 ` Ewan Mellor
2005-10-26 17:27   ` Kurt Garloff
2006-03-30  3:57 ` Florian Kirstein
2006-03-30  4:09 ` Florian Kirstein
2006-03-30 21:21   ` Daniel Veillard
2006-03-31  4:27     ` Florian Kirstein
2007-02-28  5:20       ` Florian Kirstein
2007-02-28 14:51         ` Keir Fraser
2007-02-28 17:26           ` Florian Kirstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=623652d50510270816o267337cn@mail.gmail.com \
    --to=chris.bainbridge@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.