[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xendomains init script

  • To: Xen development list <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Chris Bainbridge <chris.bainbridge@xxxxxxxxx>
  • Date: Thu, 27 Oct 2005 15:16:31 +0000
  • Delivery-date: Thu, 27 Oct 2005 15:13:40 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fPyaoz7kO9ZZQmtTLLk+yMwRaCzbVfBs42Oh4jrOW1xKedNNHhq917BZYtiZYbBlmES31O28uvHQ0Q9ZKpXprTfnzvneCuscUEl5VVgtKeX3NbBHHj8S2Bxl9aflzcRhNQOF5JoAi265paJuSrHjjrfnRoQ7yhUGdHJLI7DeJHk=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On 27/10/05, Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx> 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

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

force a run of a logrotate script which rotates the files in

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.