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 (email@example.com) (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' [...]
|Resolved||ayounsi||T244585 Upgrade rpki VMs to buster|
|Resolved||akosiaris||T245158 ganeti doesn't change the boot order to network|
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?