run virt-resize for UEFI C7 Image to expand disk Import new image using virt-manager, Begin customize and change boot from BIOS to UEFI, Boot fails with UEFI not finding grubx86efi file. To fix it cd /var/lib/libvirt/qemu/nvram/ cp <OLDVM>__VARS.fd <NewVM>__VARS.fd Looks like during import <VM>_VARS.fs is not created properly. Please note newly install VMs will not have this issue
Exact Error message: Failed to open \EFI\BOOT\grubx64.efi - Not Found Failed to load image \EFI\BOOT\grubx64.efi - Not Found start_image() returned Not Found
Thanks for the report. So you had a working VM, altered the disk image, then imported it into virt-manager and it didn't boot? What distro is VM? If it's fedora, might be suffering from an incarnation of https://bugzilla.redhat.com/show_bug.cgi?id=1196114 which prevents fallback.efi from working when the nvram is lost. The VM clone process will copy nvram content, but import shouldn't do that since it doesn't have any knowledge about whether there was a source VM or not.
Host Fedora 27 Guest CentOS 7 CentOS-7-x86_64-Minimal-1708.iso I use thin LVM volumes as VM storage. lvcreate a new volume shutdown my active VM virt-resize old VM lvm to new VM lvm Create a new VM by importing storage, I agree this will not have any knowledge about old VM but this process has been working for me for at least last 3 Fedora releases. With Fedora 27 it seems to be broken. This same process also works for me on CentOS and RHEL. I can colpy any working NVRAM VARS.fd to new VM VARS.fs and VM start booting. How can I view content of VARS.fd ?
(In reply to Yogesh Sharma from comment #3) > Host Fedora 27 > Guest CentOS 7 CentOS-7-x86_64-Minimal-1708.iso > > I use thin LVM volumes as VM storage. > lvcreate a new volume > shutdown my active VM > virt-resize old VM lvm to new VM lvm > > Create a new VM by importing storage, I agree this will not have any > knowledge about old VM but this process has been working for me for at least > last 3 Fedora releases. With Fedora 27 it seems to be broken. This same > process also works for me on CentOS and RHEL. I can colpy any working NVRAM > VARS.fd to new VM VARS.fs and VM start booting. > Thanks for clarifying. Did the previous process work even if you didn't copy over the VARS file? Or did you always manually copy over the VARS file? Did the previous times that it worked (on older fedora host) also use CentOS-7-x86_64-Minimal-1708.iso ? Im guessing not since that's the very latest centos release. Maybe try the previous centos release or whatever distro worked in the past, this could be an issue in the guest OS (centos bug) > How can I view content of VARS.fd ? No idea
Previously I never had to copy NVRAM for CentOS or RHEL 7 UEFI based VM. This is first time I copied NVRAM as I was not able to boot copied VM. I had older CentOS 7 VM with Fedora 26, where I copied using virt-resize, import and it worked. After upgrade to Fedora 27, this process stopped working for same old VM and that is when I downloaded CentOS-7-x86_64-Minimal-1708.iso and build new VM from scratch and virt-resize process didn't work either. I do have a setup with Fedora 26 will give it a try with CentOS-7-x86_64-Minimal-1708.iso. Yes, VM copy using resize has always for me on Fedora release (at least for last 3 I remember F24-F26). I can not use virt-manager clone as I am use Thin LVM for my VM storage.
Interesting that it worked before with same guest OS on f26, and no nvram copying. I'm trying to think what could be the culprit in f27. Can you give the output of rpm -qa | grep -e edk2 -e libvirt -e qemu | sort
I assume you are looking for this from Fedora 27 edk2-aarch64-20170209git296153c5-5.fc27.noarch edk2-ovmf-20170209git296153c5-5.fc27.noarch ipxe-roms-qemu-20161108-2.gitb991c67.fc26.noarch libvirt-client-3.7.0-2.fc27.x86_64 libvirt-daemon-3.7.0-2.fc27.x86_64 libvirt-daemon-config-network-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-interface-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-network-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-nodedev-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-nwfilter-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-qemu-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-secret-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-storage-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-storage-core-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-storage-disk-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-storage-gluster-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-storage-iscsi-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-storage-logical-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-storage-mpath-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-storage-rbd-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-storage-scsi-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-storage-sheepdog-3.7.0-2.fc27.x86_64 libvirt-daemon-driver-storage-zfs-3.7.0-2.fc27.x86_64 libvirt-daemon-kvm-3.7.0-2.fc27.x86_64 libvirt-glib-1.0.0-2.fc26.x86_64 libvirt-libs-3.7.0-2.fc27.x86_64 python2-libvirt-3.7.0-1.fc27.x86_64 qemu-block-curl-2.10.0-4.fc27.x86_64 qemu-block-dmg-2.10.0-4.fc27.x86_64 qemu-block-gluster-2.10.0-4.fc27.x86_64 qemu-block-iscsi-2.10.0-4.fc27.x86_64 qemu-block-nfs-2.10.0-4.fc27.x86_64 qemu-block-rbd-2.10.0-4.fc27.x86_64 qemu-block-ssh-2.10.0-4.fc27.x86_64 qemu-common-2.10.0-4.fc27.x86_64 qemu-guest-agent-2.10.0-4.fc27.x86_64 qemu-img-2.10.0-4.fc27.x86_64 qemu-kvm-2.10.0-4.fc27.x86_64 qemu-system-aarch64-2.10.0-4.fc27.x86_64 qemu-system-aarch64-core-2.10.0-4.fc27.x86_64 qemu-system-x86-2.10.0-4.fc27.x86_64 qemu-system-x86-core-2.10.0-4.fc27.x86_64 rubygem-fog-libvirt-0.3.0-3.fc27.noarch rubygem-ruby-libvirt-0.7.0-5.fc27.x86_64 vagrant-libvirt-0.0.40-2.fc27.noarch
Can you provide the working VM config of the original VM, and the new VM config after virt-manager import? sudo virsh dumpxml VM-NAME
Created attachment 1342329 [details] working
Created attachment 1342330 [details] non-working working-C7BaseImage.xml and non-working-CopyTest.xml are attached. I am not seeing any differences.
If I use BIOS boot, above process works. With latest update, copying nvram also stopped working.
Further testing show that import of UEFI images is not working, no matter what storage is used, LVM, ThinLVM, qcow2 etc. Only virt-manager clone for qcow2 based images works for UEFI images.
Looks like I hit same bug after moving my images from Fedora 26 to Fedora 27. Maybe there is known workaround for importing images?
Unfortunately only way it works for is to use non UEFI boot.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.