Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
xl or xm for xen ? (and more questions, maybe raidframe related)
I'm confused...
Perhaps not a new state, but at an increased level... I know that xm
is old, and being replaced by xl, but I'm totally confuxed by the setup
as installed by sysutils/xentools42 from pkgsrc (when I'm installing new
stuff, I like to pick what seems to be the latest version, unless there's
a good reason not to, as once picked, I tend to then stay with that version
for a long time...)
I have installed the rc.d scripts from xentools42 - and they seem to
work fine, but when I read various documentation, I have no idea what is
going on, or whether it is really installed and working correctly (I am
yet to actually try installing a domU - this confusion over xm & xl is
largely why, I'm not sure what commands I should be using.) The NetBSD
Dom0 (using a kernel that was from HEAD a couple of months ago - 6.99.23)
looks to be working fine (modulo one minor probably non-problem.)
The xendomains script that is installed in rc.d uses xl to start things.
All the documentation I have read (general, mostly aimed at linux users,
documentation) says that when xl is used, xend should not be, and all python
related stuff should be removed (I'd like that!)
But, the xendomains script has "REQUIRE: xend" in it ??
Can anyone tell me what I should really be doing, what is needed, and what
is not needed? NetBSD specific documentation seems to all still be xm based.
I am a 100% new XEN user, I have no finger memory to maintain, or anything
like that, no existing configurations to be compatible with, so I have no
interest in starting with an old system that's in the process of being
deprecated, I'd like to begin by using something that looks like it might
still be around next year, and the year after - and at the minute that seems
to be xl.
While I am here, my Dom0 kernel is saying ...
evtchn_do_event: handler 0xffffffff801f9c7f didn't lower ipl 8 7
According to a nm of the (amd64) kernel, that address is xen_timer_handler()
and from a quick glance through the code, I suspect that it is saying that
some callout handler is busted...
This kernel runs raidframe, and I don't recall seeing those messages before
I enabled raid, so I'd tend to guess that the broken callout might be
a raidframe function - is there any easy way to work out which it is?
If it helps, these messages come at a moderately high frequency (perhaps
several a second) soon after boot, then the frequency descreases to where
it might be several minutes between messages after a while (I don't think
they ever completely go away.) That also suggests raidframe related to
me, as early after boot raidframe will be verifying its (single for now,
level 1) raid array - then after that, this system isn't doing much yet,
so everything is likely to go fairly quiet...
Lastly, for questions (unrelated I suspect) for this message, and I think
I have seen this reported before, but for kernel interaction (like RB_ASKNAME)
the kernel seems to be totally botching communications with the PS/2
keyboard that is installed (I haven't tried a USB keyboard on this system
yet, but is PS/2 isn't working properly, ...) Everything is fine during
the bootstrap process, and again, after wscons starts (once the kernel
starts talking via /dev/console) - but in the intervening period, the
keyboard is useless - the console logs some message about some error
(sorry, don't have that one available right now) and the keyboard is dead
(and only a reset gets the system back, of course).
And really last - but for once, something to give back, I append some
patches for the sysutils/xentools42 rc.d scripts, to fix a bunch of
typos (it was obvious the "status" rc.d operation wasn't tested...),
and I think, generally improve them a bit. To make reading the patch
easier, note that the position of the xendomains_list() function in the
script was moved, its content was not altered. If this looks useful enough
that it would be worth a pkg category PR, let me know and I will do that.
I know that buiding in /usr/pkg/sbin (setting PATH before starting xend,
otherwise commands it runs aren't found) and the path to the current version
of python (otherwise the pid finding code in rc.subr fails) aren't done
the right way, but I'm sure someone who knows pkgsrc subst and stuff can
fix that so the right things happen "by magic" when the package is built.
Thanks for any help anyone can offer.
kre
--- xend 2013-11-24 22:32:51.000000000 +0700
+++ /etc/rc.d/xend 2013-12-02 02:25:12.000000000 +0700
@@ -29,20 +29,19 @@
{
printf "Starting xendservices: xenbackendd, xend.\n"
XENBACKENDD_ARGS=""
- if [ -n "${XENBACKENDD_DEBUG}" ]; then
+ if [ -n "${XENBACKENDD_DEBUG}" ] && checkyesno XENBACKENDD_DEBUG; then
XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
fi
${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
- XEND_ARGS=""
- if [ -n "${XEND_DEBUG}" ]; then
- XEND_ARGS="${XEND_ARGS} trace_start"
+ if [ -n "${XEND_DEBUG}" ] && checkyesno XEND_DEBUG; then
+ XEND_ARGS="trace_start"
else
- XEND_ARGS="${XEND_ARGS} start"
+ XEND_ARGS="start"
fi
- ${SBINDIR}/xend ${XEND_ARGS}
+ PATH=/usr/pkg/sbin:$PATH ${SBINDIR}/xend ${XEND_ARGS}
}
xen_stop()
@@ -63,19 +62,21 @@
xen_status()
{
+ pids=
+
xenbackendd_pid=$(check_pidfile ${XENBACKENDD_PIDFILE}
${SBINDIR}/xenbackendd)
- if test -n ${xenbackend_pid}; then
- pids="$pids $xenbackend_pid"
+ if test -n "${xenbackendd_pid}"; then
+ pids="$pids $xenbackendd_pid"
fi
- xend_pid=$(check_pidfile ${XEND_PIDFILE} ${SBINDIR}/xend)
- if test -n ${xend_pid}; then
- pids="$pids $xenbackend_pid"
+ xend_pid=$(check_pidfile ${XEND_PIDFILE} ${SBINDIR}/xend
/usr/pkg/bin/python2.7)
+ if test -n "${xend_pid}"; then
+ pids="$pids $xend_pid"
fi
if test -n "$xend_pid" -a -n "$xenbackendd_pid";
then
- echo "xends are running as pids $pids."
+ echo "xends are running as pids$pids."
return 0
fi
if test -z "$xend_pid" -a -z "$xenbackendd_pid";
--- xendomains 2013-11-24 22:32:51.000000000 +0700
+++ /etc/rc.d/xendomains 2013-12-02 02:54:37.000000000 +0700
@@ -35,25 +35,52 @@
extra_commands="list"
required_files="/kern/xen/privcmd"
+__inlist()
+{
+ local t a
+
+ t=$1; shift
+ for a
+ do
+ [ "$t" = "$a" ] && return 0
+ done
+ return 1
+}
+
+xendomains_list() {
+ # Output a whitespace-separated list of live guest domains.
+ ${ctl_command} list | awk '
+ (FNR <= 2) { next }
+ ($5 !~ /s/) { s = s " " $1 }
+ END { sub(" *", "", s); print s }'
+}
+
xendomains_start()
{
[ -n "$xendomains" ] || return
+ livedomains=$(xendomains_list)
+
echo "Starting xen domains."
for domain in $xendomains; do
case "$domain" in
"") continue ;;
esac
+ __inlist "$domain" $livedomains && {
+ echo "Domain $domain already running."
+ continue
+ }
+
# Start off by running the pre-hook script if it's present.
if [ -n "${xendomains_prehook}" ]; then
cmdline=`printf "${xendomains_prehook}" $domain`
cmd="${cmdline%% *}"
if [ -x "$cmd" ]; then
- if ! $cmdline; then
+ $cmdline || {
echo "Pre-hook \`\`$cmdline'' failed...
skipping $domain."
continue
- fi
+ }
fi
fi
@@ -67,14 +94,6 @@
done
}
-xendomains_list() {
- # Output a whitespace-separated list of live guest domains.
- ${ctl_command} list | awk '
- (FNR <= 2) { next }
- ($5 !~ /s/) { s = s " " $1 }
- END { sub(" *", "", s); print s }'
-}
-
xendomains_stop()
{
# Determine an appropriate timeout waiting for all domains to
@@ -110,6 +129,8 @@
case "$domain" in
"") continue ;;
esac
+ __inlist "$domain" $livedomains && continue
+
if [ -n "${xendomains_posthook}" ]; then
cmdline=`printf "${xendomains_posthook}" $domain`
cmd="${cmdline%% *}"
Home |
Main Index |
Thread Index |
Old Index