Re: [RFC] fix for virt-install failure with OVMF?
On 04/22/20 01:12, aaron.young@... wrote:
This is by-design. The behavior is expected, and your virt-install
command line is wrong.
The "--location" parameter invokes a direct kernel boot. When you pass a
local ISO image with "--location", that makes no difference in this
regard; it's still a direct kernel boot. The virt-install documentation
Distribution tree installation source. virt-install can
recognize certain distribution trees and fetches a bootable
kernel/initrd pair to launch the install.
--location allows things like --extra-args for kernel
arguments, and using --initrd-inject. If you want to use
those options with CDROM media, you have a few options:
* Run virt-install as root and do --location ISO
* Mount the ISO at a local directory, and do --location
Path to a local directory containing an installable
distribution image. Note that the directory will not be
accessible by the guest after initial boot, so the OS
installer will need another way to access the rest of
the install media.
ISO Mount the ISO and probe the directory. This requires
running virt-install as root, and has the same VM
access caveat as DIRECTORY.
In other words, with your above command line, you are not booting the
ElTorito UEFI boot image that's embedded in the ISO -- you are not
performing a "UEFI CD-ROM boot". Instead, virt-install mounts the ISO
image, locates the kernel (vmlinuz) and initrd files in the directory
tree, and launches a guest with direct (that is, fw_cfg) kernel boot.
For completeness, here is the qemu command that is exec'd by theRight, please see the "-kernel" and "-initrd" options on the cmdline:
/usr/bin/qemu-system-x86_64 [...] -kernelThose are temporary kernel and initrd files; extracted from your ISO.
The way OVMF reacts to these QEMU options is expected.
Remove the "--location" option from your virt-install command line.
Further comments I have:
* "--boot uefi" is not needed if you spell out "--boot
"--boot uefi" is a shorthand for the latter, relying on libvirtd and
its configuration to locate a firmware executable (and a compatible
variable store template) for you.
* "--boot loader_secure=no" is the default, so no need to spell it out.
* Not sure what "--noreboot" is useful for, I never use it.
* Setting the boot order with "--boot=hd,cdrom" is legacy BIOS style;
it's best not to use it with UEFI. Instead, use the "boot_order"
property with the individual "--disk" options.
* "--vcpus 1" is also the default, no need to spell it out.
* The "nvram=..." property for "--boot" does not seem very useful. It
means that you want to reuse a pre-existent variable store file with
the newly installed domain. This is useful only in exceptional cases;
normally you want libvirtd to create the new domain's variable store
from the variable store template given with "nvram_template".
So ultimately I would try:
--name Guest1 \
--ram 4096 \
--disk path=/Disks/Guest1_disk.img,size=10,format=qcow2,boot_order=1 \
--disk path=/ISO/OracleLinux-R7-U4-Server-x86_64-dvd.iso,device=cdrom,readonly,boot_order=2 \
--network bridge=virbr0,model=virtio \
--os-type linux \
--boot loader=/usr/share/OVMF/OVMF_CODE.pure-efi.fd,loader_ro=yes,loader_type=pflash,nvram_template=/usr/share/OVMF/OVMF_VARS.pure-efi.fd \
--video vga \
Hope this helps,