Xen users - Jun 2012 - pygrub: reboot causes on_poweroff instead of on_reboot

Good evening!

I recently switched to using PyGrub to boot my domUs using their own
internal kernel and boot preference. Before I was using manual
"kernel+initd" options in the domu.sxp, both located in the dom0
file-system, I really appreciate this separation of concerns. While
the host boots correctly and I can select the kernel from "xm
console", the behaviour on reboot has changed.

My domu.sxp files contain:
on_poweroff = ''destroy''
on_reboot   = ''restart''
on_crash    = ''restart''

Before I switched to pygrub, "xm reboot domu" or "ssh domu
reboot"
would trigger the on_reboot rule and restart the system. "xm shutdown
domu" or "ssh domu shutdown" would trigger the on_poweroff rule
and
destroy the domu, ready to be "xm create"d with a new sxp.

After I switched to pygrub, "xm reboot domu", "ssh domu
reboot", "xm
shutdown domu", and "ssh domu shutdown" all trigger the
on_poweroff
condition. Since the administrators for the domu systems need to be
able to reboot their machines without access to the dom0, this
presents a problem---they can''t "xm create" the host to
restart them.

As a work-around, I have set on_poweroff = ''restart''. However,
that is
not ideal either, because when I change a domu.sxp file, I used to be
able to "xm shutdown" and "xm create" to load the changes.
Now, I must
"xm shutdown" and carefully time a "xm destroy" after the
system
finishing quiting.

I am running:
Debian squeeze
dom0 kernel 3.2.0-0.bpo.2-amd64
domU kernel 2.6.32-5-xen-amd64
xen-hypervisor + xen-utils 4.0.1-4
xen-tools 4.2-1
... my pygrub comes from the xen-utils debian package, version 4.0.1-4.

Is this a known bug? Is there a good work around?

Thanks for the help!
Please CC me in your replies.

> Good evening!
>
> I recently switched to using PyGrub to boot my domUs using their own
> internal kernel and boot preference. Before I was using manual
> "kernel+initd" options in the domu.sxp, both located in the dom0
> file-system, I really appreciate this separation of concerns. While
> the host boots correctly and I can select the kernel from "xm
> console", the behaviour on reboot has changed.
>
> My domu.sxp files contain:
> on_poweroff = ''destroy''
> on_reboot   = ''restart''
> on_crash    = ''restart''
>
> Before I switched to pygrub, "xm reboot domu" or "ssh domu
reboot"
> would trigger the on_reboot rule and restart the system. "xm shutdown
> domu" or "ssh domu shutdown" would trigger the on_poweroff
rule and
> destroy the domu, ready to be "xm create"d with a new sxp.
>
> After I switched to pygrub, "xm reboot domu", "ssh domu
reboot", "xm
> shutdown domu", and "ssh domu shutdown" all trigger the
on_poweroff
> condition. Since the administrators for the domu systems need to be
> able to reboot their machines without access to the dom0, this
> presents a problem---they can''t "xm create" the host to
restart them.
>
> As a work-around, I have set on_poweroff = ''restart''.
However, that is
> not ideal either, because when I change a domu.sxp file, I used to be
> able to "xm shutdown" and "xm create" to load the
changes. Now, I must
> "xm shutdown" and carefully time a "xm destroy" after
the system
> finishing quiting.
>
> I am running:
> Debian squeeze
> dom0 kernel 3.2.0-0.bpo.2-amd64
> domU kernel 2.6.32-5-xen-amd64
> xen-hypervisor + xen-utils 4.0.1-4
> xen-tools 4.2-1
> ... my pygrub comes from the xen-utils debian package, version 4.0.1-4.
>
> Is this a known bug? Is there a good work around?
>
> Thanks for the help!
> Please CC me in your replies.
>
The same on Debian Wheezy
Linux 3.2.0-3-amd64
xen-hypervisor-4.1-amd64 4.1.3-2
Pygrub

Logs when "reboot" is executed from inside of domU;
Domain X is dead
Action for shutdown reason code 1 is restart
Domain X needs to be cleaned up: destroying the domain
Done. Rebooting now
failed to run bootloader: -3

This bug is described here:
http://lists.xen.org/archives/html/xen-users/2012-05/msg00285.html

Is it going to be resolved in 4.1 ?
Installing packages from Debian experimental(xen-hypervisor-4.2-amd64)
resolves this issue.

Best Regards,
T

On Wed, 2012-10-17 at 11:41 +0100, T wrote:
> This bug is described here:
> http://lists.xen.org/archives/html/xen-users/2012-05/msg00285.html
> 
> Is it going to be resolved in 4.1 ?
I''m afraid not (IIRC the fix was quite intrusive).

If xl doesn''t work for your use cases in4.1 then I recommend continuing
to use xend with 4.1 and only switching to xl with 4.2.
> Installing packages from Debian experimental(xen-hypervisor-4.2-amd64)
> resolves this issue.
Good!

Ian.