[Bug 1748280] Re: 'nova reboot' on arm64 is just 'nova reboot --hard' but slower

Balint Reczey balint.reczey at canonical.com
Wed Feb 14 08:31:40 UTC 2018

This looks like breaking autopkgtest, at least for unattended-upgrades:
autopkgtest [05:40:32]: test test-systemd.py: [-----------------------
bash: line 1:  5110 Killed                  /tmp/autopkgtest.wwbI8q/build.hcW/src/debian/tests/test-systemd.py 2> >(tee -a /tmp/autopkgtest.wwbI8q/test-systemd.py-stderr >&2) > >(tee -a /tmp/autopkgtest.wwbI8q/test-systemd.py-stdout)
autopkgtest [05:40:32]: test process requested reboot with marker InstallOnShutdown
autopkgtest-virt-ssh: WARNING: ssh connection failed. Retrying in 3 seconds...
File missing : /var/log/unattended-upgrades/unattended-upgrades.log
InstallOnShutdown did not run
autopkgtest [05:41:03]: test test-systemd.py: -----------------------]
autopkgtest [05:41:04]: test test-systemd.py:  - - - - - - - - - - results - - - - - - - - - -
test-systemd.py      FAIL non-zero exit status 1

You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to nova in Ubuntu.

  'nova reboot' on arm64 is just 'nova reboot --hard' but slower

Status in nova package in Ubuntu:

Bug description:
  Within Canonical's multi-architecture compute cloud, I observed that
  arm64 instances were taking an unreasonable amount of time to return
  from a 'nova reboot' (2 minutes +, vs. ~16s for POWER in the same
  cloud region).

  Digging into this, I find that a nova soft reboot request is doing
  nothing at all on arm64 (no events visible within the qemu guest, and
  no reboot is triggered within the guest), and then after some sort of
  timeout (~2m), 'nova reboot' falls back to a hard reset of the guest.

  Since this is entirely predictable on the arm64 platform (because
  there's no implementation of ACPI plumbed through), 'nova reboot' on
  arm64 should just skip straight to the hard reboot and save everyone
  some clock time.

To manage notifications about this bug go to:

More information about the Ubuntu-openstack-bugs mailing list