Patrick O'Callaghan writes:
On Tue, 2017-07-11 at 18:08 -0400, Sam Varshavchik wrote: > >> But this is a bald-faced lie. But if I force off, and boot again, Windows 10> comes up like there's nothing wrong. Normal boot. Just tried it and it worked perfectly. Did you shut down your Windows VM before the upgrade?
Yes.
> This continued to happen after a fresh Windows 10 install. If I initiate a > reboot from the Start menu, I don't even see the bios screen flash by. The> stupid thing immediately lands into "Preparing Automatic Repair". But a full> shutdown and a boot is fine. > > In hindsight, post-upgrade, my VM was probably ok, but it led me to believe > that it was bricked, leading me to wipe everything and reinstall. It was > very convincing. I am not amused. What you describe sounds very similar to something I saw a couple of months ago while playing with device configurations under libvirt- manager. I got the BSOD several times and resorted to a reinstall, but on reflection I think the problem was due to a lack of drivers in Windows (virtio-scsi or something, I forget) and the fact that I hadn't mounted a pseudo-ISO driver CD when trying to boot it.
I never needed additional drivers for Windows guests. I always have my disks set up as raw disks, for example. I don't use virtio. Performance of my Windows guests is not critical.
I now have the same results after upgrading another Fedora host to 26, with its own Windows 10 guest.
The first reboot had identical results: it booted to a corrupted screen, with gray vertical bars. Mouse motion resulted in some visible, random noise, so it was alive. Once again I let it run for a few minutes, but this time instead of force rebooting, I googled around, and the keyboard sequence of ALT-F4 then Enter initiates a Windows 10 shutdown. ALT-F4 opens a Windows 10 shutdown dialog with "shutdown" being the default option. I used by reconstructed, now working, Win10 guest to confirm this. This worked, and blindly shut down the second Win10 guest. Its second boot then came up to a completely black screen. In virt-manager I was seeing the usual post-boot Win10 CPU spikes. Once again I let it run, and once again ALT-F4 then Enter successfully shut down the VM.
The third boot once again came up to a black screen. This time I forced off the VM.
On the fourth boot, Windows came up to its cyan "Installing <something or other>" screen, which ended up doing something, and it's now back in business.
With all of these boots, the initial windows logo, and the initial boot spinner came up, and the stupid thing lost its mind afterwards, when it normally initializes the full-resolution video mode. It does appear that my Win10 VMs have problems with video, after qemu got upgraded, that they can't always recover from. Have no idea what it is.
As I mentioned yesterday, the second issue was that restarts/rebootsfirst VM originally had problems with reboots. Initiating a reboot from the start menu inevitably ended up in some kind of a "Preparing Automatic Repair" mode, which claimed that my disk is unsalvageable, and there are not restore points; but at that point force-off-ing the VM, and starting it cold, resulted in a 100% normal Windows 10 book, like nothing happened.
At some point, yesterday, restarts DID work, after I had my first Win10 guest install all updates it could find, and I thought that was solved. Still, I tried to restart it today, and it went into "Automatic Repair" with the same results. So that's still busted.
The second Win10 that I upgraded today has the same problem.Well, I'm all out of Fedora hosts with Win10 guests, that I can upgrade, so that pretty much sticks a fork in me. From this little experiment, I see two separate qemu 2.9 issues: an update screws up the Spice display driver; and a software-initiated reboot is unstable.
Attachment:
pgpJdDIpuZua0.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
