thr3ads.net - Pkg xen devel - [Pkg-xen-devel] Bug#770456: Bug#770456: Please start a qemu process in domain 0. [Nov 2014]

If this information is useful, please help other people find it:
Share via:

Ian Campbell

2014-Nov-27 11:18 UTC

[Pkg-xen-devel] Bug#770456: Bug#770456: Please start a qemu process in domain 0.

On Thu, 2014-11-27 at 11:02 +0100, Stefan Bader wrote:> On 21.11.2014 13:50, Ian Campbell wrote:
> > Package: xen-utils-common
> > Version: 4.4.0-1
> > Severity: important
> > Tags: patch
> > 
> > Under some circumstances the xl toolstack needs to create a loopback
> > mount of a guest disk in dom0 (e.g. in order to run pygrub). Depending
> > on the nature of the guest disk (e.g. qcow2 or raw file image based)
> > this can require a qemu instance in dom0.
> > 
> > The upstream xencommons starts such a qemu on boot. The following
patch
> > adds this to the Debian packages init script as well.
> > 
> > Once I have a bug number for this I will add it to debian/changelog
and
> > push the result to feature/bugNNNN as usual.
> > 
> > Thanks,
> > Ian.
> > 
> > commit 26cce2a65c77f731e23a1395f1fe4a5da47287a4
> > Author: Ian Campbell <ijc at debian.org>
> > Date:   Fri Nov 21 11:27:45 2014 +0000
> > 
> >     Start a qemu process in dom0 to service the toolstacks loopback
disk attaches.
> >     
> >     This is used to e.g. run pygrub on a VM with a qcow2 disk image.
> >     
> >     Also, remove correct pidfile when stopping xenconsoled.
> > 
> > diff --git a/debian/changelog b/debian/changelog
> > index 484583f..ff48d6a 100644
> > --- a/debian/changelog
> > +++ b/debian/changelog
> > @@ -1,3 +1,12 @@
> > +xen (4.4.1-4) UNRELEASED; urgency=medium
> > +
> > +  [ Ian Campbell ]
> > +  * Start a qemu process in dom0 to service the toolstacks loopback
disk
> > +    attaches.
> > +  * Remove correct pidfile when stopping xenconsoled.
> > +
> > + -- Ian Campbell <ijc at debian.org>  Fri, 21 Nov 2014 11:26:40
+0000
> > +
> >  xen (4.4.1-3) unstable; urgency=medium
> >  
> >    [ Bastian Blank ]
> > diff --git a/debian/xen-utils-common.xen.init
b/debian/xen-utils-common.xen.init
> ...
> > +
> > +qemu_start_real()
> > +{
> > +	start-stop-daemon --start --quiet --pidfile
"$QEMU_PIDFILE" --exec "$QEMU" --test > /dev/null \
> > +		|| return 1
> > +	start-stop-daemon --start --quiet --pidfile
"$QEMU_PIDFILE" --exec "$QEMU" -- \
> > +		$QEMU_ARGS -pidfile "$QEMU_PIDFILE" \
> > +		|| return 2
> > +}
> > +
> > +qemu_stop_real()
> > +{
> > +	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile
"$QEMU_PIDFILE" --name xenconsoled
> > +	RETVAL="$?"
> > +	[ "$RETVAL" = 2 ] && return 2
> > +	start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec
"$QEMU"
> > +	[ "$?" = 2 ] && return 2
> > +	rm -f $QEMU_PIDFILE
> > +	return "$RETVAL"
> > +}
> > +
> > +
> 
> Not sure this already was handled but the --name argument of qemu_stop_real
> seems a copy-and-paste bug.
Yes it is, whoops!
>  Playing with it right now, --exec instead of --name
> also works out better since qemu-system-i386 is just about too long.
So it is, so this is probably a good idea.

Will you send an updated patch once you've finished testing?

Ian.

Stefan Bader

2014-Nov-27 11:41 UTC

head link

[Pkg-xen-devel] Bug#770456: Bug#770456: Please start a qemu process in domain 0.

On 27.11.2014 12:18, Ian Campbell wrote:> On Thu, 2014-11-27 at 11:02 +0100, Stefan Bader wrote:
>> On 21.11.2014 13:50, Ian Campbell wrote:
>>> Package: xen-utils-common
>>> Version: 4.4.0-1
>>> Severity: important
>>> Tags: patch
>>>
>>> Under some circumstances the xl toolstack needs to create a
loopback
>>> mount of a guest disk in dom0 (e.g. in order to run pygrub).
Depending
>>> on the nature of the guest disk (e.g. qcow2 or raw file image
based)
>>> this can require a qemu instance in dom0.
>>>
>>> The upstream xencommons starts such a qemu on boot. The following
patch
>>> adds this to the Debian packages init script as well.
>>>
>>> Once I have a bug number for this I will add it to debian/changelog
and
>>> push the result to feature/bugNNNN as usual.
>>>
>>> Thanks,
>>> Ian.
>>>
>>> commit 26cce2a65c77f731e23a1395f1fe4a5da47287a4
>>> Author: Ian Campbell <ijc at debian.org>
>>> Date:   Fri Nov 21 11:27:45 2014 +0000
>>>
>>>     Start a qemu process in dom0 to service the toolstacks loopback
disk attaches.
>>>     
>>>     This is used to e.g. run pygrub on a VM with a qcow2 disk
image.
>>>     
>>>     Also, remove correct pidfile when stopping xenconsoled.
>>>
>>> diff --git a/debian/changelog b/debian/changelog
>>> index 484583f..ff48d6a 100644
>>> --- a/debian/changelog
>>> +++ b/debian/changelog
>>> @@ -1,3 +1,12 @@
>>> +xen (4.4.1-4) UNRELEASED; urgency=medium
>>> +
>>> +  [ Ian Campbell ]
>>> +  * Start a qemu process in dom0 to service the toolstacks
loopback disk
>>> +    attaches.
>>> +  * Remove correct pidfile when stopping xenconsoled.
>>> +
>>> + -- Ian Campbell <ijc at debian.org>  Fri, 21 Nov 2014
11:26:40 +0000
>>> +
>>>  xen (4.4.1-3) unstable; urgency=medium
>>>  
>>>    [ Bastian Blank ]
>>> diff --git a/debian/xen-utils-common.xen.init
b/debian/xen-utils-common.xen.init
>> ...
>>> +
>>> +qemu_start_real()
>>> +{
>>> +	start-stop-daemon --start --quiet --pidfile
"$QEMU_PIDFILE" --exec "$QEMU" --test > /dev/null \
>>> +		|| return 1
>>> +	start-stop-daemon --start --quiet --pidfile
"$QEMU_PIDFILE" --exec "$QEMU" -- \
>>> +		$QEMU_ARGS -pidfile "$QEMU_PIDFILE" \
>>> +		|| return 2
>>> +}
>>> +
>>> +qemu_stop_real()
>>> +{
>>> +	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile
"$QEMU_PIDFILE" --name xenconsoled
>>> +	RETVAL="$?"
>>> +	[ "$RETVAL" = 2 ] && return 2
>>> +	start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5
--exec "$QEMU"
>>> +	[ "$?" = 2 ] && return 2
>>> +	rm -f $QEMU_PIDFILE
>>> +	return "$RETVAL"
>>> +}
>>> +
>>> +
>>
>> Not sure this already was handled but the --name argument of
qemu_stop_real
>> seems a copy-and-paste bug.
> 
> Yes it is, whoops!
> 
>>  Playing with it right now, --exec instead of --name
>> also works out better since qemu-system-i386 is just about too long.
> 
> So it is, so this is probably a good idea.
> 
> Will you send an updated patch once you've finished testing?
Yes, sure, I can do that.

Stefan> 
> Ian.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20141127/6b7b1e46/attachment-0001.sig>

Stefan Bader

2014-Nov-27 16:41 UTC

head link

[Pkg-xen-devel] Bug#770456: Bug#770456: Please start a qemu process in domain 0.

On 27.11.2014 12:18, Ian Campbell wrote:> On Thu, 2014-11-27 at 11:02 +0100, Stefan Bader wrote:
>> On 21.11.2014 13:50, Ian Campbell wrote:
>>> Package: xen-utils-common
>>> Version: 4.4.0-1
>>> Severity: important
>>> Tags: patch
>>>
>>> Under some circumstances the xl toolstack needs to create a
loopback
>>> mount of a guest disk in dom0 (e.g. in order to run pygrub).
Depending
>>> on the nature of the guest disk (e.g. qcow2 or raw file image
based)
>>> this can require a qemu instance in dom0.
>>>
>>> The upstream xencommons starts such a qemu on boot. The following
patch
>>> adds this to the Debian packages init script as well.
>>>
>>> Once I have a bug number for this I will add it to debian/changelog
and
>>> push the result to feature/bugNNNN as usual.
>>>
>>> Thanks,
>>> Ian.
>>>
>><old path removed>
>> Not sure this already was handled but the --name argument of
qemu_stop_real
>> seems a copy-and-paste bug.
> 
> Yes it is, whoops!
> 
>>  Playing with it right now, --exec instead of --name
>> also works out better since qemu-system-i386 is just about too long.
> 
> So it is, so this is probably a good idea.
> 
> Will you send an updated patch once you've finished testing?
> 
So not sure whether the bug processor can handle attachments but Thunderbird
tends to mess things up otherwise. Also I yet have to figure out the location of
the repo to make proper patches (sorry about that).

Anyway attaching the diff between the current init script and the updated one.
There is one thing which I did not include there. That is a work around some
kernel bug (which should be fixed in Debian by now). Just for here I want to
avoid stepping into the case where the new package is installed with the broken
kernel because in that situation the dpkg starts a qemu which cannot attach
properly and in the end both hang and qemu has to be killed hard(er). All a bit
ugly. So this is likely nothing you need but just in case:

(see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763831)

-Stefan

 xenstored_start()
 {
        log_progress_msg "xenstored"
+       #
+       # Work-around kernel regression where short name links of
+       # /proc/$$/exe get replaced on rename unconditionally. This
+       # should be fixed in the kernel but hitting a bad kernel is
+       # fatal with starting qemu in dom0 (dpkg/qemu hangs).
+       #
+       if [ -f $XENSTORED_PIDFILE ]; then
+               XSPID="$(cat $XENSTORED_PIDFILE)"
+               XSBIN="$(ls -la /proc/$XSPID/exe 2>/dev/null)"
+               XSBIN="${XSBIN#*-> }"
+               XSBIN="${XSBIN% (deleted)}"
+               if [ "$XSBIN" != "" ]; then
+                       if [ "$(basename $XSBIN)" =
"xenstored.dpkg-new" ]; then
+                               return 1
+                       fi
+               fi
+       fi
        start-stop-daemon --start --quiet --pidfile
"$XENSTORED_PIDFILE" --exec
"$XENSTORED" --test > /dev/null \


-------------- next part --------------
--- debian/xen-utils-common.xen.init.orig	2014-11-27 17:25:04.378851403 +0100
+++ debian/xen-utils-common.xen.init	2014-11-27 17:27:32.238849961 +0100
@@ -37,6 +37,9 @@ XENCONSOLED="$ROOT"/bin/xenconsoled
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
 XENSTORED="$ROOT"/bin/xenstored
 XENSTORED_PIDFILE="/var/run/xenstore.pid"
+QEMU=/usr/bin/qemu-system-i386
+QEMU_PIDFILE="/var/run/qemu-dom0.pid"
+QEMU_ARGS="-xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv
-daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null"
 
 modules_setup()
 {
@@ -179,10 +182,65 @@ xenconsoled_stop_real()
 	[ "$RETVAL" = 2 ] && return 2
 	start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec
"$XENCONSOLED"
 	[ "$?" = 2 ] && return 2
-	rm -f $PIDFILE
+	rm -f $XENCONSOLED_PIDFILE
 	return "$RETVAL"
 }
 
+qemu_start()
+{
+	[ -x $QEMU ] || return 0
+	log_progress_msg "qemu"
+	qemu_start_real
+	return $?
+}
+
+qemu_stop()
+{
+	[ -x $QEMU ] || return 0
+	log_progress_msg "qemu"
+	qemu_stop_real
+	return $?
+}
+
+qemu_restart()
+{
+	[ -x $QEMU ] || return 0
+	log_progress_msg "qemu"
+	qemu_stop_real
+	case "$?" in
+		0|1)
+		qemu_start_real
+		case "$?" in
+			0) ;;
+			*) return 2 ;;
+		esac
+		;;
+		*) return 2 ;;
+	esac
+	return 0
+}
+
+qemu_start_real()
+{
+	start-stop-daemon --start --quiet --pidfile "$QEMU_PIDFILE" --exec
"$QEMU" --test > /dev/null \
+		|| return 1
+	start-stop-daemon --start --quiet --pidfile "$QEMU_PIDFILE" --exec
"$QEMU" -- \
+		$QEMU_ARGS -pidfile "$QEMU_PIDFILE" \
+		|| return 2
+}
+
+qemu_stop_real()
+{
+	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile
"$QEMU_PIDFILE" --exec "$QEMU"
+	RETVAL="$?"
+	[ "$RETVAL" = 2 ] && return 2
+	start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec
"$QEMU"
+	[ "$?" = 2 ] && return 2
+	rm -f $QEMU_PIDFILE
+	return "$RETVAL"
+}
+
+
 xenstored_start()
 {
 	log_progress_msg "xenstored"
@@ -227,6 +285,11 @@ case "$1" in
 		0|1) ;;
 		*) log_end_msg 1; exit ;;
 	esac
+	qemu_start
+	case "$?" in
+		0|1) ;;
+		*) log_end_msg 1; exit ;;
+	esac
 	log_end_msg 0
 	;;
   stop)
@@ -237,6 +300,11 @@ case "$1" in
 	esac
 	log_daemon_msg "Stopping $DESC"
 	ret=0
+	qemu_stop
+	case "$?" in
+		0|1) ;;
+		*) ret=1 ;;
+	esac
 	xend_stop
 	case "$?" in
 		0|1) ;;
@@ -257,6 +325,11 @@ case "$1" in
 	esac
 	log_daemon_msg "Restarting $DESC"
 	ret=0
+	qemu_restart
+	case "$?" in
+		0|1) ;;
+		*) ret=1 ;;
+	esac
 	xend_restart
 	case "$?" in
 		0|1) ;;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20141127/f1c933d8/attachment.sig>

Ian Campbell

2014-Dec-01 11:35 UTC

head link

[Pkg-xen-devel] Bug#770456: Bug#770456: Bug#770456: Please start a qemu process in domain 0.

On Thu, 2014-11-27 at 17:41 +0100, Stefan Bader wrote:> On 27.11.2014 12:18, Ian Campbell wrote:
> > On Thu, 2014-11-27 at 11:02 +0100, Stefan Bader wrote:
> >> On 21.11.2014 13:50, Ian Campbell wrote:
> >>> Package: xen-utils-common
> >>> Version: 4.4.0-1
> >>> Severity: important
> >>> Tags: patch
> >>>
> >>> Under some circumstances the xl toolstack needs to create a
loopback
> >>> mount of a guest disk in dom0 (e.g. in order to run pygrub).
Depending
> >>> on the nature of the guest disk (e.g. qcow2 or raw file image
based)
> >>> this can require a qemu instance in dom0.
> >>>
> >>> The upstream xencommons starts such a qemu on boot. The
following patch
> >>> adds this to the Debian packages init script as well.
> >>>
> >>> Once I have a bug number for this I will add it to
debian/changelog and
> >>> push the result to feature/bugNNNN as usual.
> >>>
> >>> Thanks,
> >>> Ian.
> >>>
> >>
> <old path removed>
> 
> >> Not sure this already was handled but the --name argument of
qemu_stop_real
> >> seems a copy-and-paste bug.
> > 
> > Yes it is, whoops!
> > 
> >>  Playing with it right now, --exec instead of --name
> >> also works out better since qemu-system-i386 is just about too
long.
> > 
> > So it is, so this is probably a good idea.
> > 
> > Will you send an updated patch once you've finished testing?
> > 
> 
> So not sure whether the bug processor can handle attachments but
Thunderbird
> tends to mess things up otherwise. Also I yet have to figure out the
location of
> the repo to make proper patches (sorry about that).
http://anonscm.debian.org/cgit/pkg-xen/xen.git
> Anyway attaching the diff between the current init script and the updated
one.
> There is one thing which I did not include there. That is a work around
some
> kernel bug (which should be fixed in Debian by now). Just for here I want
to
> avoid stepping into the case where the new package is installed with the
broken
> kernel because in that situation the dpkg starts a qemu which cannot attach
> properly and in the end both hang and qemu has to be killed hard(er). All a
bit
> ugly. So this is likely nothing you need but just in case:
> 
> (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763831)
Urk. I wonder if this explains some of the bugs about the initscript
hanging we had around earlier.

Anyway, your diff seems to only add some code to xenstored_start, I was
expecting a change to qemu_start -- did you find that code was OK in the
end? Or did you end up switching to --exec?

Thanks,
Ian.
> -Stefan
> 
>  xenstored_start()
>  {
>         log_progress_msg "xenstored"
> +       #
> +       # Work-around kernel regression where short name links of
> +       # /proc/$$/exe get replaced on rename unconditionally. This
> +       # should be fixed in the kernel but hitting a bad kernel is
> +       # fatal with starting qemu in dom0 (dpkg/qemu hangs).
> +       #
> +       if [ -f $XENSTORED_PIDFILE ]; then
> +               XSPID="$(cat $XENSTORED_PIDFILE)"
> +               XSBIN="$(ls -la /proc/$XSPID/exe 2>/dev/null)"
> +               XSBIN="${XSBIN#*-> }"
> +               XSBIN="${XSBIN% (deleted)}"
> +               if [ "$XSBIN" != "" ]; then
> +                       if [ "$(basename $XSBIN)" =
"xenstored.dpkg-new" ]; then
> +                               return 1
> +                       fi
> +               fi
> +       fi
>         start-stop-daemon --start --quiet --pidfile
"$XENSTORED_PIDFILE" --exec
> "$XENSTORED" --test > /dev/null \
> 
> 
> _______________________________________________
> Pkg-xen-devel mailing list
> Pkg-xen-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel

Possibly Parallel Threads

Search for more reasonably related threads

Pkg xen devel - Nov 2014 - Bug#770456: Bug#770456: Please start a qemu process in domain 0.

[Pkg-xen-devel] Bug#770456: Bug#770456: Please start a qemu process in domain 0.

[Pkg-xen-devel] Bug#770456: Bug#770456: Please start a qemu process in domain 0.

[Pkg-xen-devel] Bug#770456: Bug#770456: Please start a qemu process in domain 0.

[Pkg-xen-devel] Bug#770456: Bug#770456: Bug#770456: Please start a qemu process in domain 0.

Possibly Parallel Threads