Xen devel - Jun 2007 - RFC: making the xen startup integrate better with distros

What follows below is an outline of what we''re changing in Xen startup
for Fedora 8. I know historically when getting into initscripts you tend
to hit distro specific issues. So I''m posting this to see if
there''s any
interest from others in having these changes integrated upstream. I''d
like to thing that with a few minor tweaks this is general enough to be 
useful to other Linux distros at least - the init script is basically
making use of LSB defined functions...


The way xen init scripts currently work is that they basically call out
to /usr/bin/xend which re-implements ideas already provided to all init
scripts via /etc/init.d/functions. Only the re-implementation is in python
and is slower & doesn''t integrate well with standard distro
configuration
procedure. eg we''ve no way to config stuff in /etc/sysconfig/xend to
give
users flexibility. The plan is thus:

 * The auto-restart angel process should go since it merely serves to
   fork-bomb Xend when something goes wrong during startup. We''ve never
   seen XenD crash anyway so its not really buying us much except more
   complexity. Its also not monitoring the other Xen related daemons
   which have have seen crash! No other system daemons typically have
   auto crash restart built it - there are plenty of monitoring tools
   which add this system wide.

 * The individual daemons should each be started from the init scripts
   directly. User can see exactly what''s started & what''s
running. We
   can then easily pass custom command line args to each one.

 * Drop a file in /etc/sysconfig/xen allowing user to customize the
   startup options for individual daemons.

 * Drop a file in /etc/sysconfig/modules/xen.modules to trigger loading
   of the backend driver modules.


So we have a config file  in /etc/sysconfig/modules containing user config
options

  [root@celery console]# cat /etc/sysconfig/xend
  #XENSTORED_PID="/var/run/xenstore.pid"
  #XENSTORED_ARGS
  # Log all hypervisor messages (cf xm dmesg)
  #XENCONSOLED_LOG_HYPERVISOR=yes

  # Log all guest console output (cf xm console)
  #XENCONSOLED_LOG_GUESTS=yes

  # Location to store guest & hypervisor logs
  #XENCONSOLED_LOG_DIR=/var/log/xen/console

  #XENCONSOLED_ARGS
  #BLKTAPCTRL_ARGS
(This would be /etc/default/xend instead on Debian I believe)

When starting, we run all four currently provided Xen daemon processes,
list out all daemons being started along the way...

  [root@celery console]# service xend start
  Starting xen daemons: xenstored blktapctrl xenconsoled xend[  OK  ]

And you can see they''re each now running

  [root@celery console]# service xend status
  xenstored (pid 2924) is running...
  blktapctrl (pid 2934) is running...
  xenconsoled (pid 32595) is running...
  xend (pid  32599) is running...
                                                           [  OK  ]

See the processes running and that they picked up config from settings
the user provided in /etc/sysconfig/xend

root      2924  1.0  0.0   8412   988 ?        S    May24 105:31 xenstored
--pid-file /var/run/xenstore.pid
root     32595  0.0  0.0  20516   632 ?        Sl   18:11   0:00
/usr/sbin/xenconsoled --log=all --log-dir=/var/log/xen/console
root     32599  4.9  0.3 346952 13732 ?        Sl   18:11   0:09 python
/usr/sbin/xend


We can also trigger a reload by directly sending each reloadable daemon
a SIGHUP. This makes xend re-read its config file, and make xenconsoled 
re-open its logfiles

  [root@celery console]# service xend reload
  Reloading xen daemons: xenconsoled xend                    [  OK  ]

Both Xend & XenConsoleD are capable of being stopped & restarted. It
isn''t
safe to stop blktapctrl or xenstored though. So init script only stops
the former two processes. eg:

  [root@celery console]# service xend stop
  Stopping xen daemons: xenconsoled xend                     [  OK  ]
 
Looking again at status of individual daemons, notice how we only stopped
xend & xenconsoled:
 
  [root@celery console]# service xend status
  xenstored (pid 2924) is running...
  blktapctrl (pid 2934) is running...
  xenconsoled is stopped
  xend is stopped
                                                           [FAILED]
 

The attached patch shows the changes to the init script to do this, as well
as killing off most of tools/misc/xend (what becomes /usr/sbin/xend). It
could probably go a bit further a kill off alot of stuff in the python
class tools/python/xen/xend/server/SrvDaemon.py since much of that
isn''t
needed now that its leveraging standard LSB init functions to do most of
the PID file handling for shutdown, reload, status commands.

   Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 1 Jun 2007, Daniel P. Berrange wrote:
> What follows below is an outline of what we''re changing in Xen
startup
> for Fedora 8. I know historically when getting into initscripts you tend 
> to hit distro specific issues. So I''m posting this to see if
there''s any
> interest from others in having these changes integrated upstream.
I''d
> like to thing that with a few minor tweaks this is general enough to be 
> useful to other Linux distros at least - the init script is basically 
> making use of LSB defined functions...
Sounds like an excellent idea. Debian and Ubuntu don''t ship with a 
''functions'' file, but I think this could easily be made to
work on both.
> * The individual daemons should each be started from the init scripts
>   directly. User can see exactly what''s started &
what''s running. We
>   can then easily pass custom command line args to each one.
Agreed. The other advantage of this is that it would be easy to launch 
said programs from a daemon monitoring app (ie, daemontools, etc).
> * Drop a file in /etc/sysconfig/xen allowing user to customize the
>   startup options for individual daemons.
Like you said, also /etc/default/xen on Debian. Debian does already have 
an /etc/default/xendomains which control the way that domains are 
started/stopped.
> We can also trigger a reload by directly sending each reloadable daemon 
> a SIGHUP. This makes xend re-read its config file, and make xenconsoled 
> re-open its logfiles
Beautiful!
> The attached patch shows the changes to the init script to do this, as 
> well as killing off most of tools/misc/xend (what becomes 
> /usr/sbin/xend). It could probably go a bit further a kill off alot of 
> stuff in the python class tools/python/xen/xend/server/SrvDaemon.py 
> since much of that isn''t needed now that its leveraging standard
LSB
> init functions to do most of the PID file handling for shutdown, reload, 
> status commands.
The Debian packaging for Xen also includes a pile of patches to allow 
python paths and such to be more configurable - this is because Debian 
allows you to have multiple versions of the tools and hypervisor 
installed. It''d be really nice to see these integrated upstream; they
are
the primary thing that takes awhile to patch up with each new Xen release 
to get Debian packages built. If you''re interested in seeing what they 
are, I can post them, or convince one of the regular Deb developers to 
upload them.  :)

------------------------------------------------------------------------
| nate carlson | natecars@natecarlson.com | http://www.natecarlson.com |
|       depriving some poor village of its idiot since 1981            |
------------------------------------------------------------------------

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel