Tom Horsley writes:
I have a windows 10 qemu/kvm virtual machine hosted on fedora 26. Every time I leave it alone to apply updates (which takes forever), I come back later and find the console saying "Aaugh, there is no boot device!". I go into virt-manager, force a reset, and it boots fine, but now it is only 30% through applying updates, so I have to wait forever again. Is windows 10 incapable of rebooting itself, or is qemu busted somehow so that windows 10 attempt to reboot doesn't work? This always seems to fail (but only with updates - if I select reboot from the taskbar menu, it always reboots just fine). Anyone have a clue? Does this happen to anyone else?
I have experienced a similar problem. I use virt-manager to manage QEMU VMs running Windows 10. The problems started six months ago after I upgraded to Fedora 26 and qemu 2.9. There was nothing immediately wrong, at first. I booted Win10 and shut it down a few times. Everything seems to be in order.
I do not remember if I initiated the reboot for some reason, or if it was a Win10-initiated reboot. But the reboot went into some kind of a recovery mode I have not seen before, in Windows. Instead of booting Windows 10, it was some kind of recovery menu, giving me a few options to try. I do not immediately recall which options tjeu were, but the the conclusion was the same, no matter which recovery option I picked: an adamant claim that my "hard drive" is fried.
I had some data on that Win10 VM that was lost, but nothing catastophical, so I resigned to wiping and reinstalling Win10 on that VM. Only to discover, after a successful install, that the problem persisted: about 10% of the time Windows10 was able to reboot without any issues; but about 90% of the time I was immediately dumped into that recovery shell. It was only then when I realized that this was a qemu problem, and not Windows just being Windows. I obviously wiped a perfectly healthy Windows 10 install. I confirmed it with a different host that had another Windows 10 VM. After updating that one to Fedora 26, and qemu 2.9, that 2nd Windows 10 guest also started having a cow rebooting itself. After Windows 10 dropped into that recovery menu, if I just force power-off the VM and restart it, Windows 10 boots fine.
But I found that major updates to Windows 10 were not dropping into the recovery shell at all, but instead they rebooted a 2nd time, with the OS coming up that time, but with the updater believing that the update has failed, and the updater then rolling the whole thing back. I watched as that 2nd VM downloaded the entire anniversary update, and rebooted once to start the update. The 2nd reboot apparently failed, but instead of ending up in recovery mode it rebooted again, and rolled back the entire anniversary update. It was awesome to watch.
Scouring virt-manager's documentation, I found an apparent setting that I could supposedly add to the domain XML file that would result in the VM powering off instead of rebooting, for a VM-initiated reboot. That seems to be exactly the workaround I was looking for, but the option did not work, and after some chatter on libvirt-users, it was established that the documented option wasn't actually implemented. While that was getting squared away, I managed to tracked down a different way to pass-through the right voodoo to qemu to have it power-off the VM for a guest-initiated reboot.
That did the trick. Now, the VM powered off instead of rebooting, and I just had to manually start the VM again, and everything was peachy. Using that temporary workaround I successfully nursed that VM through the anniversary update. I just had to manully start the VM again, each time it went down for the reboot.
In the meantime, the missing libvirt pieces got patched in, and the update got pushed to Fedora 26. Basically, if you go to /etc/libvirt/qemu, and use
virsh edit <domainfile>.xml Then shove the following XML in there: <on_reboot>destroy</on_reboot>(and remove any existing <on_reboot> in there on the chance there is one), then that VM will shut down instead of rebooting.
Now, the libvirt GUI hasn't quite wrapped its brain entirely around this option, and after the VM goes down the libvirt GUI will still think it's running, and be quite confused. You just have to shut down the libvirt- manager application and start it again, and you'll be able to start the VM just fine.
I don't quite know yet what's the story with qemu 2.10 in Fedora 27. I still have that manual <on_reboot> setting in there. I don't know if qemu 2.10 fixed whatever the underlying bug is, and whether I can remove that setting now. When I have time, I'll need to do some further testing. But I can confirm that, in the meantime, that setting still does the trick. One of my Windows 10 VMs happened to have successfully updated itself to the creator's edition, today, under my watching eye, of course; with me just manually killing libvirt-manager then starting it up again, then using it to manually start the VM after it came down for an alleged reboot.
Attachment:
pgp_W_nGn3APR.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
