Virt Manager vms not starting

No one of my vms starts up correctly, i use virt-manager to manage it, when i start a vm, the screen show “Guest has not initialized the display (yet)”. Is the same behavior with all the vms, the last time i ran it was working well, i have no clue whats going wrong? Some advices?
I dont know how to debug it, i cant find a way to start the vm from command line

I never used virt-manager before, but maybe you can try if it works with virtualbox, to maybe isolate the issue to virt-manager

Is this a recent phenomenon, or did it just start? Has virt-manager ever worked? I use it all day with a wide mixture of VMs and it’s never failed like what you’re describing.

How did you create your VMs? How did you install qemu?

I’ve been using virt-manager for several years and never had a problem, now none of my vm’s start, I’ve tried creating a new vm and the new one works but the old ones don’t. I hadn’t used vm for a few weeks so I don’t know exactly when they stopped working. But it always worked fine before.

I have installed qemu from pacman, classic procedure

I ran into a similar problem with my VMs that use GPU pass-through after the edk2-armvirt and edk2-ovmf packages were upgraded to version 202208-3. Downgrading to 202208-1 fixed it. If your VMs are using UEFI, then this might be your problem.

I already tried with edk2-ovmf downgrade, but didn’t restart the host, I tried but nothing changed, I don’t use any passtrough anyway

I had downgraded with version 202208-3 and not 202208-1, now it works. I was close to the solution but I was just wrong. Thank you

I would try rebooting, just to see if the downgrade required it. If that doesn’t help, try starting a VM with virsh then monitor the libvirtd and virtlogd services to see what’s failing.

Now works fine, but what is wrong with ovmf?

That I can’t tell you; downgrading the aforementioned packages was just a lucky guess on my part. I haven’t see any info related to this.

Was the first thing i thought about, and i was not wrong, but the version bugged started from 202208-3

1 Like

I was able to fix the problem using the latest version of edk2-ovmf
Check this issue on the github repo of the project

The original post from github

Hey guys,
I stumbled over this also in September and for Fedora this is what worked for me:

  1. in your VM XML you will find the and sections
  2. create backup of everything, but at least /var/lib/libvirt/qemu/nvram/win11_VARS.fd filename depends on the VM you want to alter.
    This includes BitLocker Recovery Key.
  3. cp /usr/share/edk2/ovmf-4m/OVMF_VARS.fd /var/lib/libvirt/qemu/nvram/win11_VARS.fd again filename depends on the VM file.
  4. alter the XML to below values:
<loader readonly="yes" secure="yes" type="pflash">/usr/share/edk2/ovmf-4m/OVMF_CODE.secboot.fd</loader>
  1. VM should now boot properly and the Windows Update should disappear.

Thanks to @BentHaase for finding out!

I’m confused as to what you actually fixed. The link mentioned is for a 6-year-old issue, the 2nd post is about Windows 11.

FWIW, there was a huge QEMU update today, which I tried but it failed again, this time on all of my VMs, not just the GPU-pass-through ones. The only package that needed to be downgraded was edk2-ovmf (version 202211-3 to 202208-1). Interestingly enough, this latest version that failed is 7 revisions ahead of the one that still works.

I ended up removing all the old *.fd files from /var/lib/libvirt/qemu/nvram and let QEMU rebuild them. What I found was that most of my systems would figure out the old GRUB EFI boot entries for systems with standard partitioning schemes (like /boot/efi or Windows 10), but systems like openSUSE (with its complicated BTRFS subvolume setup) or my Arch-based systems (using /boot instead of /boot/efi) required a re-running of grub-install.

Thankfully this is over…

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.