Page MenuHomePhabricator

ganeti doesn't change the boot order to network
Closed, ResolvedPublic

Description

root@ganeti2001:~#  gnt-instance shutdown $FQDN
Waiting for job 803635 for rpki2001.codfw.wmnet ...
root@ganeti2001:~#  gnt-instance modify --hypervisor-parameters=boot_order=network $FQDN
Modified instance rpki2001.codfw.wmnet
 - hv/boot_order -> network
Please don't forget that most parameters take effect only at the next (re)start of the instance initiated by ganeti; restarting from within the instance will not be enough.
Note that changing hypervisor parameters without performing a restart might lead to a crash while performing a live migration. This will be addressed in future Ganeti versions.
root@ganeti2001:~#  gnt-instance start $FQDN && gnt-instance console $FQDN
Waiting for job 803637 for rpki2001.codfw.wmnet ...
 
[...]

Loading Linux 4.9.0-11-amd64 ...Loading Linux 4.9.0-11-amd64 ...

Loading initial ramdisk ...Loading initial ramdisk ...

[    0.000000] Linux version 4.9.0-11-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.189-3+deb9u1 (2019-09-20)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-11-amd64 root=UUID=736b14df-afc8-4867-b218-1119151e9a67 ro console=ttyS0,115200n8 elevator=deadline
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[...]

Related Objects

Event Timeline

ayounsi triaged this task as High priority.Feb 13 2020, 3:06 PM
ayounsi created this task.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 13 2020, 3:06 PM
akosiaris closed this task as Resolved.Feb 13 2020, 3:38 PM
akosiaris claimed this task.

The VM had a kvm_extra: -bios OVMF.fd in its configuration. That meant is used UEFI, not BIOS and hence the usual boot_order: network ganeti functionality wouldn't work as the boot order was stored in the UEFI "firmware" which ganeti doesn't have support for yet. The fix was

$ sudo gnt-instance modify -H kvm_extra=default rpki2001.codfw.wmnet

after which the VM could boot into network just fine.

How did the OVMF come about? Some snowflake setting from ealier tests or something we might run into again?

How did the OVMF come about? Some snowflake setting from ealier tests or something we might run into again?

nvm, saw the discussion in -sre