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

Bug #1748280 reported by Steve Langasek
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Confirmed
Medium
Unassigned
nova (Ubuntu)
Confirmed
Medium
Unassigned
systemd (Ubuntu)
Invalid
Undecided
Unassigned

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.

Tags: libvirt
Revision history for this message
Balint Reczey (rbalint) wrote :

This looks like breaking autopkgtest, at least for unattended-upgrades:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/u/unattended-upgrades/20180213_054128_4e1c0@/log.gz
...
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
...

Revision history for this message
Balint Reczey (rbalint) wrote :

Maybe not using the --nova-reboot until it is fixed could make the test bed work for u-u and other packages.

See: https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/tree/ssh-setup/nova

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nova (Ubuntu):
status: New → Confirmed
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

This affects systemd-fsckd autopkgtest

melanie witt (melwitt)
tags: added: libvirt
Revision history for this message
melanie witt (melwitt) wrote :

On the surface, it seems like this is something we could check for in the libvirt driver and skip the soft reboot timeout cycle if ARM64. The question I have is, which architecture fields does "ARM64" map to in nova? ARMV6 or ARMV7 or ARMV7B or AARCH64 or all of them? Or one that I missed? [1]

[1] https://github.com/openstack/nova/blob/da1669/nova/objects/fields.py#L108-L112

Changed in nova:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Steve Langasek (vorlon) wrote :

arm64 maps to AARCH64.

Changed in nova (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Nick Rosbrook (enr0n) wrote :

I do not see anything actionable for systemd at this time. Please re-open if I am mistaken.

Changed in systemd (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.