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@xxxxxxxxxx> 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
_______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
