[virt-tools-list] virt-install: boot from the 2nd hard disk via UEFI if the first one is "empty"

[Cole Robinson]

On 01/22/2019 07:40 AM, Attila Vangel wrote:
> Hi,
> 
> I am new to virt-install and just a regular user of UEFI, so forgive me
> if I ask something stupid.
> 
> I am trying to create and start a VM with virt-install so that
> - it needs to boot with UEFI,
> - if the first disk is "empty" (just created, not partitioned), then the
> system should boot from the second HDD, which contains an installer image,
> - otherwise if an UEFI bootable system is found in the first HDD, then
> it should boot from that.
> (it is also OK if I could change the boot order after the VM is booted
> (during installation it gets rebooted)
> - it should happen without manual intervention (e.g. interactive boot
> menu), fully scripted.
> 
> So far I put together a command line something like this:
> 
> INSTALLER_IMAGE_PATH=/path/to/installer-image.qcow2
> 
> virt-install --name my-vm --network default --connect qemu:///system
> --memory=4096 --cpu=host --vcpus=2 --os-type=linux --os-variant=generic
> --noautoconsole --events on_poweroff=preserve --disk
> pool=default,size=30 --disk $INSTALLER_IMAGE_PATH --boot
> loader=/usr/share/ovmf/x64/OVMF_CODE.fd,loader_ro=yes,loader_type=pflash,nvram_template=/usr/share/ovmf/x64/OVMF_VARS.fd,loader_secure=no
> 

A couple small things for starters: --network default and
--os-type=linux are redundant here, they are the default settings
(unless you have a bridge device manually configured on your host, then
virt-install will use that). Similarly --os-variant=generic is the
default too, if you want a better performing guest using virtio specify
a modern linux version in there like --os-variant=fedora28

> The "--boot
> loader=/usr/share/ovmf/x64/OVMF_CODE.fd,loader_ro=yes,loader_type=pflash,nvram_template=/usr/share/ovmf/x64/OVMF_VARS.fd,loader_secure=no"
> magic I googled from somewhere, as the "--boot uefi" option did not work
> (gave "ERROR    Error: --boot uefi: Did not find any UEFI binary path
> for arch 'x86_64'").
> The OVMF file paths are based on the Arch linux ovmf package.
> 

That --boot string looks correct although loader_secure=no is redundant
I think. '--boot uefi' requires getting those paths from libvirt
domcapabilities output, which only knows where to look if libvirt is
built with an appropriate --with-loader-nvram option pointing to the
distros nvram paths. You should file a bug with arch libvirt maintainers
to investigate using that build option, then --boot uefi will work fine.

Anyways I'm surprised this doesn't work. The default boot=hd setting I
thought would try each hd in sequence and boot the first bootable one.
You can try adding explicit --disk ...,bootorder=1 --disk
...,bootorder=2 attributes, maybe it will make a difference. You can use
that to make usb booting too with --hostdev ...,bootorder=X

That said, I just tried that bootorder= with seabios booting, and it
didn't work either for your use case. Seems like for hd booting, seabios
will just bail out on the first hd failure, like it isn't smart enough
to continue on if there's no boot entry in the first hd it hits. That
surprises me. Maybe UEFI doesn't have the same issue though

- Cole