Re: [RFC] fix for virt-install failure with OVMF?


Aaron Young
 

Hi Lazslo, thanks for the comments.

My apologies - the actual virt-install command our Q/A team is using is this (which has extra args for a kick start file):

virt-install --name guest-31156337 --memory 4096 --vcpus 4 --disk path=/guest-31156337/guest-31156337-kvm.img,size=10,device=disk,bus=virtio,sparse=yes --location /ISO/OracleLinux-R7-U7-Server-x86_64-dvd.iso --nographics --initrd-inject=/guest-31156337/log/guest-31156337-ks.cfg --network bridge=virbr0,model=virtio --os-type linux --os-variant ol7.7 --noreboot --boot=hd,cdrom,loader=//usr/share/OVMF/OVMF_CODE.pure-efi-guest-31156337.fd,loader_ro=yes,loader_type=pflash,loader_secure=no,nvram=/usr/share/OVMF/OVMF_VARS.pure-efi-guest-31156337.fd --extra-args="ks=file:/guest-31156337-ks.cfg ip=dhcp console=tty0 console=ttyS0,115200n8

I had changed the args (below) in an effort to simplify things (i.e. I had removed the --extra-args and --initrd-inject args for the kick start file which I had thought were not germane to the issue).

Per the virt-install docs (which you site below) and the other examples on-line to use virt-install with a kickstart (i.e. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-guest_virtual_machine_installation_overview-creating_guests_with_virt_install), the --location arg seems to be necessary to use a kickstart file (?).

Do you have any further comments/suggestions in light of needing to use a kickstart file and thus the --location arg?

Thanks again in advance,

-Aaron

On 04/22/2020 11:33 AM, Laszlo Ersek wrote:
On 04/22/20 01:12, aaron.young@... wrote:
Hello, we have found what we think is a BUG in OVMF, but wanted to run
it by the rfc list first to confirm.

We have discovered that the following virt-install command causes the
latest OVMF code to fail to boot into the installer ISO.

virt-install --boot uefi --name Guest1 --ram 4096 --vcpus 1 --disk
path=/Disks/Guest1_disk.img --location
/ISO/OracleLinux-R7-U4-Server-x86_64-dvd.iso --network
bridge=virbr0,model=virtio --os-type linux --noreboot
--boot=hd,cdrom,loader=/usr/share/OVMF/OVMF_CODE.pure-efi.fd,loader_ro=yes,loader_type=pflash,loader_secure=no,nvram=/Images/OVMF_VARS.pure-efi.Guest1.fd
--video vga --graphics vnc,port=5999

Instead of booting to the installer ISO, we drop into the kernel shell
like so:
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
explains:

"""
-l LOCATION
--location OPTIONS
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
DIRECTORY
[...]
DIRECTORY
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.

[snip]

For completeness, here is the qemu command that is exec'd by the
virt-install command for reference:
Right, please see the "-kernel" and "-initrd" options on the cmdline:

/usr/bin/qemu-system-x86_64 [...] -kernel
/var/lib/libvirt/boot/virtinst-vmlinuz.jdC2ks -initrd
/var/lib/libvirt/boot/virtinst-initrd.img.aHyTeQ [...]
Those 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.
Instead, use

--disk path=/ISO/OracleLinux-R7-U4-Server-x86_64-dvd.iso,device=cdrom

Further comments I have:

* "--boot uefi" is not needed if you spell out "--boot
loader=/.../OVMF_CODE.fd,loader_ro=yes,loader_type=pflash,nvram_template=/.../OVMF_VARS.fd".

"--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:

virt-install \
--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 \
--graphics vnc,port=5999

Hope this helps,
Laszlo


Join rfc@edk2.groups.io to automatically receive all group messages.