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/reboots
first 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.