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 <[email protected]> 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 [email protected] https://www.redhat.com/mailman/listinfo/virt-tools-list
