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

[Attila Vangel]

Hi,

Thank you very much for the quick response!
Actually setting the explicit boot order for the '--disk'-s worked like a
charm! Just needed to correct the 'bootorder' to 'boot_order' (got:
"ERROR    Unknown options ['bootorder']"), see also virt-install
'--disk=?'. Just I was not aware to search for the options of the --disk.

Thanks for the general improvement comments as well, I will apply them! I
based my command on an existing script, and did not check all the options.

As for libvirt, I can live with these options, I will try to find some
downloadable package which contains these files (also, ultimately I will
run the virt-install command in an ubuntu 18.04 VM and there in the ovmf
package the ovmf files are somehow not separated like this, I also found a
debian bug report about it).

Regards,
Attila

On Tue, Jan 22, 2019 at 4:26 PM Cole Robinson <crobinso at redhat.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20190122/1ee6054f/attachment.htm>