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 (firstname.lastname@example.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' [...]
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.