Pkg xen devel - Jan 2015 - Ubuntu delta against 4.5.0-1 in experimental for disussion

Hi,

I just finished preparing the Xen-4.5 merge from experimental into our next
release (Vivid/15.04). And something I actually should have done since the 4.4
times is to report back the delta I have in case there are things Debian might
want to pick up as well.

So below is the commented debdiff between the 4.5.0-1 in experimental and the
Ubuntu version I prepared so far (only compile tested on x86 at the time of
writing this).

Regards,
Stefan

[Excluding changelog and the maintainer change in control]

First hunk in the following diff is just for the sake of completeness. OCAML was
dropped when xend support was taken out, so setting the destination directory
sounds useless. On the other hand it does not break anything.
The second hunk may or may not be useful for Debian. I add this (and the
d/xen-hypervisor-4.5.xen.cfg file) so update-grub will automatically create a
config that boots into Xen by default. Files in /etc/default/grub.d are appended
to /etc/default/grub, so one does not have to fiddle around with the main file).

diff -Nru xen-4.5.0/debian/rules.real xen-4.5.0/debian/rules.real
--- xen-4.5.0/debian/rules.real	2015-01-20 19:29:03.000000000 +0100
+++ xen-4.5.0/debian/rules.real	2015-01-22 11:44:54.000000000 +0100
@@ -95,7 +95,6 @@
 		EXTRA_CFLAGS_XEN_TOOLS="$(CFLAGS)" \
 		APPEND_CPPFLAGS="$(CPPFLAGS)" \
 		APPEND_LDFLAGS="$(LDFLAGS)" \
-		OCAMLDESTDIR=$(CURDIR)/$(BUILD_DIR)/install-utils_$(ARCH)/$(OCAML_STDLIB_DIR)
\
 		PYTHON=$(shell pyversions -r)

 $(STAMPS_DIR)/build-utils_$(ARCH): DIR=$(BUILD_DIR)/build-utils_$(ARCH)
@@ -152,6 +151,9 @@
 	dh_testroot
 	dh_prep
 	dh_installdirs boot
+	dh_installdirs etc/default/grub.d
+	install -D -m644 debian/xen-hypervisor-$(VERSION).xen.cfg \
+		debian/$(PACKAGE_NAME)/etc/default/grub.d/xen.cfg
 	cp $(DIR)/xen/xen$(IMAGE_SUFFIX)
debian/$(PACKAGE_NAME)/boot/xen-$(VERSION)-$(FLAVOUR)$(IMAGE_SUFFIX)
 ifeq ($(ARCH),amd64)
 	cp $(DIR)/xen/xen.efi
debian/$(PACKAGE_NAME)/boot/xen-$(VERSION)-$(FLAVOUR).efi

That one modifies xen-init-list to look at domains managed by the xl namespace.
This additionally works around a bug in xl which will report a syntax error when
"xl list -l" is called while domains in a different namespace exist.
Which is
the case when libvirt is used to start them.

diff -Nru xen-4.5.0/debian/scripts/xen-init-list
xen-4.5.0/debian/scripts/xen-init-list
--- xen-4.5.0/debian/scripts/xen-init-list	2015-01-20 19:29:03.000000000 +0100
+++ xen-4.5.0/debian/scripts/xen-init-list	2015-01-22 11:53:40.000000000 +0100
@@ -2,6 +2,7 @@

 import json
 import re
+import os
 import sys
 import subprocess

@@ -64,10 +65,23 @@
                     pass


+def UserdataWalker(domid_list, dirname, fnames):
+    for fname in fnames:
+        if fname.startswith("userdata"):
+            wh, domid, uuid_string, userdata_userid =
fname.split(".")
+            if userdata_userid == "xl":
+                domid_list.append(domid)
+
+
 if __name__ == '__main__':
-    p = subprocess.check_output(('xen', 'list', '-l'))
-    if p[0] == '(':
-        d = DataSXP(p)
-    else:
-        d = DataJSON(p)
-    d(sys.stdout)
+    domid_list = []
+
+    os.path.walk("/var/lib/xen", UserdataWalker, domid_list)
+    for domid in domid_list:
+        p = subprocess.check_output(('xen', 'list',
'-l', domid))
+        if p[0] == '(':
+            d = DataSXP(p)
+        else:
+            d = DataJSON(p)
+        d(sys.stdout)
+

Ok, that one is only due to personal anal behaviour. Just that /me likes a bit
of text more than the three dots...

diff -Nru
xen-4.5.0/debian/tree/xen-utils-common/usr/share/xen-utils-common/default.xen
xen-4.5.0/debian/tree/xen-utils-common/usr/share/xen-utils-common/default.xen
---
xen-4.5.0/debian/tree/xen-utils-common/usr/share/xen-utils-common/default.xen
2015-01-20 19:29:03.000000000 +0100
+++
xen-4.5.0/debian/tree/xen-utils-common/usr/share/xen-utils-common/default.xen
2015-01-22 11:57:20.000000000 +0100
@@ -2,6 +2,8 @@
 # ----------------------------

 # There exists several tool stacks to configure a Xen system.
-# ?
+# xl: This is the new toolstack using libxenlight/libxl (default)
+# xm: Was the old toolstack (xend) which is no longer supported!
+#
 # Attention: You need to reboot after changing this!
 TOOLSTACK
Here is the second part of the update-grub magic:

diff -Nru xen-4.5.0/debian/xen-hypervisor-4.5.xen.cfg
xen-4.5.0/debian/xen-hypervisor-4.5.xen.cfg
--- xen-4.5.0/debian/xen-hypervisor-4.5.xen.cfg	1970-01-01 01:00:00.000000000
+0100
+++ xen-4.5.0/debian/xen-hypervisor-4.5.xen.cfg	2015-01-22 11:59:18.000000000
+0100
@@ -0,0 +1,54 @@
+#
+# Uncomment the following variable and set to 0 or 1 to avoid warning.
+#
+#XEN_OVERRIDE_GRUB_DEFAULT=0
+
+echo "Including Xen overrides from /etc/default/grub.d/xen.cfg"
+
+#
+# When running update-grub with the Xen hypervisor installed, there are
+# some additional variables that can be used to pass options to the
+# hypervisor or the dom0 kernel.
+
+# The following two are used to generate arguments for the hypervisor:
+#
+#GRUB_CMDLINE_XEN_DEFAULT=""
+#GRUB_CMDLINE_XEN=""
+#
+# For example:
+#
+# dom0_mem=<size>[M]:max=<size>[M]
+#   Sets the amount of memory dom0 uses (max prevents balloning for more)
+# com[12]=<speed>,<data bits><parity><stopbits>
+#   Initialize a serial console from in the hypervisor (eg. 115200,8n1)
+#   Note that com1 would be ttyS0 in Linux.
+# console=<dev>[,<dev> ...]
+#   Redirects Xen hypervisor console (eg. com1,vga)
+
+#
+# The next two lines are used for creating kernel arguments for the dom0
+# kernel. This allows to have different options for the same kernel used
+# natively or as dom0 kernel.
+#
+#GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT"
+#GRUB_CMDLINE_LINUX_XEN_REPLACE="$GRUB_CMDLINE_LINUX"
+#
+# For example:
+#
+# earlyprintk=xenboot
+#   Allows to send early printk messages to the Xen hypervisor console
+# console=hvc0
+#   Redirects the Linux console to the hypervisor console
+
+#
+# Make booting into Xen the default if not changed above. Finding the
+# current string for it always has been a problem.
+#
+if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "" ]; then
+	echo "WARNING: GRUB_DEFAULT changed to boot into Xen by default!"
+	echo "         Edit /etc/default/grub.d/xen.cfg to avoid this
warning."
+	XEN_OVERRIDE_GRUB_DEFAULT=1
+fi
+if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "1" ]; then
+	GRUB_DEFAULT="Ubuntu GNU/Linux, with Xen hypervisor"
+fi

The next two are done because we did not have a xen-common alternative set for
longer than any supported direct upgrade path. So at some review we did we
decided to remove the update-alternatives calls.

diff -Nru xen-4.5.0/debian/xen-utils-4.5.postinst
xen-4.5.0/debian/xen-utils-4.5.postinst
--- xen-4.5.0/debian/xen-utils-4.5.postinst	2015-01-21 20:22:46.000000000 +0100
+++ xen-4.5.0/debian/xen-utils-4.5.postinst	2015-01-22 12:00:29.000000000 +0100
@@ -4,7 +4,6 @@

 case "$1" in
     configure)
-        update-alternatives --remove xen-default /usr/lib/xen-4.5
         if [ -x "/etc/init.d/xen" ]; then
 	    invoke-rc.d xen start || exit $?
         fi
diff -Nru xen-4.5.0/debian/xen-utils-4.5.prerm
xen-4.5.0/debian/xen-utils-4.5.prerm
--- xen-4.5.0/debian/xen-utils-4.5.prerm	2015-01-21 20:22:46.000000000 +0100
+++ xen-4.5.0/debian/xen-utils-4.5.prerm	2015-01-22 12:00:36.000000000 +0100
@@ -4,7 +4,6 @@

 case "$1" in
     remove|upgrade)
-        update-alternatives --remove xen-default /usr/lib/xen-4.5
         if [ -x "/etc/init.d/xen" ]; then
             invoke-rc.d xen stop || exit $?
         fi

The last one actually looks like a mistake. Even if the qemu part is no longer
wanted, the variable for the pid file in case of stopping xenconsoled is wrong.
But I suspect it might just be a case of accidentally dropping when moving
forward.

diff -Nru xen-4.5.0/debian/xen-utils-common.xen.init
xen-4.5.0/debian/xen-utils-common.xen.init
--- xen-4.5.0/debian/xen-utils-common.xen.init	2015-01-20 19:29:03.000000000
+0100
+++ xen-4.5.0/debian/xen-utils-common.xen.init	2015-01-22 12:16:25.000000000
+0100
@@ -37,6 +37,9 @@
 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,13 +182,84 @@
 	[ "$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"
+	#
+	# 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 \
 		|| return 1
 	[ -d "$XENSTORED_DIR" ] || mkdir -p "$XENSTORED_DIR"
@@ -227,6 +301,11 @@
 		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 +316,11 @@
 	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 +341,11 @@
 	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/20150122/1b711583/attachment.sig>

On 22.01.2015 13:02, Stefan Bader wrote:
> Hi,
> 
> I just finished preparing the Xen-4.5 merge from experimental into our next
> release (Vivid/15.04). And something I actually should have done since the
4.4
> times is to report back the delta I have in case there are things Debian
might
> want to pick up as well.
> 
> So below is the commented debdiff between the 4.5.0-1 in experimental and
the
> Ubuntu version I prepared so far (only compile tested on x86 at the time of
> writing this).
> 
> Regards,
> Stefan
> 
> [Excluding changelog and the maintainer change in control]
> 
> First hunk in the following diff is just for the sake of completeness.
OCAML was
> dropped when xend support was taken out, so setting the destination
directory
> sounds useless. On the other hand it does not break anything.
> The second hunk may or may not be useful for Debian. I add this (and the
> d/xen-hypervisor-4.5.xen.cfg file) so update-grub will automatically create
a
> config that boots into Xen by default. Files in /etc/default/grub.d are
appended
> to /etc/default/grub, so one does not have to fiddle around with the main
file).
For completeness... at least the implementation of where I added the update-grub
config and how seems less than ideal in the light of moving from one version to
the next. So clearly nothing that anyone wants to do at least in that form.

Will have to ponder how to get out of this and still offer a simple way to get a
Xen host up.

-Stefan
> 
> diff -Nru xen-4.5.0/debian/rules.real xen-4.5.0/debian/rules.real
> --- xen-4.5.0/debian/rules.real	2015-01-20 19:29:03.000000000 +0100
> +++ xen-4.5.0/debian/rules.real	2015-01-22 11:44:54.000000000 +0100
> @@ -95,7 +95,6 @@
>  		EXTRA_CFLAGS_XEN_TOOLS="$(CFLAGS)" \
>  		APPEND_CPPFLAGS="$(CPPFLAGS)" \
>  		APPEND_LDFLAGS="$(LDFLAGS)" \
> -	
OCAMLDESTDIR=$(CURDIR)/$(BUILD_DIR)/install-utils_$(ARCH)/$(OCAML_STDLIB_DIR) \
>  		PYTHON=$(shell pyversions -r)
> 
>  $(STAMPS_DIR)/build-utils_$(ARCH): DIR=$(BUILD_DIR)/build-utils_$(ARCH)
> @@ -152,6 +151,9 @@
>  	dh_testroot
>  	dh_prep
>  	dh_installdirs boot
> +	dh_installdirs etc/default/grub.d
> +	install -D -m644 debian/xen-hypervisor-$(VERSION).xen.cfg \
> +		debian/$(PACKAGE_NAME)/etc/default/grub.d/xen.cfg
>  	cp $(DIR)/xen/xen$(IMAGE_SUFFIX)
> debian/$(PACKAGE_NAME)/boot/xen-$(VERSION)-$(FLAVOUR)$(IMAGE_SUFFIX)
>  ifeq ($(ARCH),amd64)
>  	cp $(DIR)/xen/xen.efi
debian/$(PACKAGE_NAME)/boot/xen-$(VERSION)-$(FLAVOUR).efi
> 
...
> Here is the second part of the update-grub magic:
> 
> diff -Nru xen-4.5.0/debian/xen-hypervisor-4.5.xen.cfg
> xen-4.5.0/debian/xen-hypervisor-4.5.xen.cfg
> --- xen-4.5.0/debian/xen-hypervisor-4.5.xen.cfg	1970-01-01
01:00:00.000000000 +0100
> +++ xen-4.5.0/debian/xen-hypervisor-4.5.xen.cfg	2015-01-22
11:59:18.000000000 +0100
> @@ -0,0 +1,54 @@
> +#
> +# Uncomment the following variable and set to 0 or 1 to avoid warning.
> +#
> +#XEN_OVERRIDE_GRUB_DEFAULT=0
> +
> +echo "Including Xen overrides from /etc/default/grub.d/xen.cfg"
> +
> +#
> +# When running update-grub with the Xen hypervisor installed, there are
> +# some additional variables that can be used to pass options to the
> +# hypervisor or the dom0 kernel.
> +
> +# The following two are used to generate arguments for the hypervisor:
> +#
> +#GRUB_CMDLINE_XEN_DEFAULT=""
> +#GRUB_CMDLINE_XEN=""
> +#
> +# For example:
> +#
> +# dom0_mem=<size>[M]:max=<size>[M]
> +#   Sets the amount of memory dom0 uses (max prevents balloning for more)
> +# com[12]=<speed>,<data bits><parity><stopbits>
> +#   Initialize a serial console from in the hypervisor (eg. 115200,8n1)
> +#   Note that com1 would be ttyS0 in Linux.
> +# console=<dev>[,<dev> ...]

-------------- 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/20150122/2b9a5d9a/attachment.sig>

On Thu, 2015-01-22 at 16:08 +0100, Stefan Bader wrote:
> On 22.01.2015 13:02, Stefan Bader wrote:
> > Hi,
> > 
> > I just finished preparing the Xen-4.5 merge from experimental into our
next
> > release (Vivid/15.04). And something I actually should have done since
the 4.4
> > times is to report back the delta I have in case there are things
Debian might
> > want to pick up as well.
> > 
> > So below is the commented debdiff between the 4.5.0-1 in experimental
and the
> > Ubuntu version I prepared so far (only compile tested on x86 at the
time of
> > writing this).
> > 
> > Regards,
> > Stefan
> > 
> > [Excluding changelog and the maintainer change in control]
> > 
> > First hunk in the following diff is just for the sake of completeness.
OCAML was
> > dropped when xend support was taken out, so setting the destination
directory
> > sounds useless. On the other hand it does not break anything.
> > The second hunk may or may not be useful for Debian. I add this (and
the
> > d/xen-hypervisor-4.5.xen.cfg file) so update-grub will automatically
create a
> > config that boots into Xen by default. Files in /etc/default/grub.d
are appended
> > to /etc/default/grub, so one does not have to fiddle around with the
main file).
> 
> For completeness... at least the implementation of where I added the
update-grub
> config and how seems less than ideal in the light of moving from one
version to
> the next. So clearly nothing that anyone wants to do at least in that form.
Relying on the entry ordering and being able to reference by number is a
bit fragile with the more complex menu structure used these days.

https://wiki.debian.org/Xen#Prioritise_Booting_Xen_Over_Native
recommends:
        dpkg-divert --divert /etc/grub.d/08_linux_xen --rename
/etc/grub.d/20_linux_xen
        
TBH I think the correct answer is to upstream a patch to grub renaming
20_linux_xen to 08_linux_xen (or before 10_linux in any case), on the
principal that if you bother to install Xen then you most likely want to
boot it by default. I just never got round to it.

Ian.

On Thu, 2015-01-22 at 13:02 +0100, Stefan Bader wrote:
> That one modifies xen-init-list to look at domains managed by the xl
namespace.
> This additionally works around a bug in xl which will report a syntax error
when
> "xl list -l" is called while domains in a different namespace
exist. Which is
> the case when libvirt is used to start them.
FWIW in 4.5 xl is supposed to be more tolerant of domains started by
another toolstack (so long as they are using the libxl framework). In
particular I think "xl list -l" is supposed to cope with libvirt
domains
now.
> diff -Nru xen-4.5.0/debian/xen-utils-common.xen.init
> xen-4.5.0/debian/xen-utils-common.xen.init
> --- xen-4.5.0/debian/xen-utils-common.xen.init	2015-01-20
19:29:03.000000000 +0100
> +++ xen-4.5.0/debian/xen-utils-common.xen.init	2015-01-22
12:16:25.000000000 +0100
> @@ -37,6 +37,9 @@
>  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"
I think all this is #770456, feature/bug770456 branch in the packaging
xen.git. TBH I think this really ought to be fixed for Jessie.

Ian.

On 22.01.2015 17:02, Ian Campbell wrote:
> On Thu, 2015-01-22 at 13:02 +0100, Stefan Bader wrote:
>> That one modifies xen-init-list to look at domains managed by the xl
namespace.
>> This additionally works around a bug in xl which will report a syntax
error when
>> "xl list -l" is called while domains in a different namespace
exist. Which is
>> the case when libvirt is used to start them.
> 
> FWIW in 4.5 xl is supposed to be more tolerant of domains started by
> another toolstack (so long as they are using the libxl framework). In
> particular I think "xl list -l" is supposed to cope with libvirt
domains
> now.
> 
>> diff -Nru xen-4.5.0/debian/xen-utils-common.xen.init
>> xen-4.5.0/debian/xen-utils-common.xen.init
>> --- xen-4.5.0/debian/xen-utils-common.xen.init	2015-01-20
19:29:03.000000000 +0100
>> +++ xen-4.5.0/debian/xen-utils-common.xen.init	2015-01-22
12:16:25.000000000 +0100
>> @@ -37,6 +37,9 @@
>>  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"
> 
> I think all this is #770456, feature/bug770456 branch in the packaging
> xen.git. TBH I think this really ought to be fixed for Jessie.
I actually thought you had added it already. But I probably just was confused
because I added that while you were working on the feature/bug. There had been
some uploads in between which I skipped and so I just looked at it again with
the 4.5 upload. Sorry for 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/20150122/c36066e9/attachment.sig>

On 22.01.2015 17:02, Ian Campbell wrote:
> On Thu, 2015-01-22 at 13:02 +0100, Stefan Bader wrote:
>> That one modifies xen-init-list to look at domains managed by the xl
namespace.
>> This additionally works around a bug in xl which will report a syntax
error when
>> "xl list -l" is called while domains in a different namespace
exist. Which is
>> the case when libvirt is used to start them.
> 
> FWIW in 4.5 xl is supposed to be more tolerant of domains started by
> another toolstack (so long as they are using the libxl framework). In
> particular I think "xl list -l" is supposed to cope with libvirt
domains
> now.
Did some more hands-on testing now and it looks like the old problem is indeed
fixed. Though there is now a

libxl: error: libxl.c:6571:libxl_retrieve_domain_configuration: fail to get
domain configuration for domain 0

But that does not look to be causing problems. Something to think about here is
more subtle and rather a question of policy. So the output of xen-init-list is,
either solely or also, used to act on running domains when the host is shut
down.

For libvirt there is a similar aproach in its init script. By default (did not
dig deep enough there to know whether that is only our or upstream) this
connects via qemu and lxc uris and shuts down guests. Adding the xen uri sounds
logical as this covers all cases of guests managed via libvirt then.

But then "xl list -l" does not appear to make a difference between
domains
started by itself or other toolstacks now. So xendomains would act on all of
them. May or may not be a problem right now. But at least could lead to
unexpected behaviour. Which could become worse when init scripts are handled
more in parallel.

This is not only a problem in Debian or Ubuntu. We should probably discuss this
more widely. Just brought it up here as the change to xen-init-list not only
works around the bug (which is no longer present) but also causes it to only
print details of domains started by xl (and so leaving libvirt started domains
to be handled by libvirt).

-Stefan
> 
>> diff -Nru xen-4.5.0/debian/xen-utils-common.xen.init
>> xen-4.5.0/debian/xen-utils-common.xen.init
>> --- xen-4.5.0/debian/xen-utils-common.xen.init	2015-01-20
19:29:03.000000000 +0100
>> +++ xen-4.5.0/debian/xen-utils-common.xen.init	2015-01-22
12:16:25.000000000 +0100
>> @@ -37,6 +37,9 @@
>>  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"
> 
> I think all this is #770456, feature/bug770456 branch in the packaging
> xen.git. TBH I think this really ought to be fixed for Jessie.
> 
> 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/20150123/e34b7af5/attachment.sig>