libvirt users - Nov 2017 - kvm/libvirt on CentOS7 w/Windows 10 Pro guest

Hey all,

New to list, so I apologize if this has been asked a bunch already...

 Is there something I'm missing with Windows 10 as a guest that keeps
Windows Updates from nuking the boot process?

I just did an orderly shutdown and windows updated itself <I forgot to
disable in time> only to reboot to the diagnostics screen which couldn't
repair.

going to command prompt and doing the usual "bootrec /fixmbr, /fixboot and
/RebuildBcd" didn't help.

This has happened a few times. I can't believe how fragile Win10pro is while
running in a VM.

(and it's happened on a couple machines I've been experimenting with --
both running same OS, but different hardware.)

I just saw the FAQ about the libvirt repo for the virtio drivers for windows....
I need to go read more on it...

but in the meantime, is there any other smoking gun I'm not aware of? (after
lots of google searching)


Thanks,


 -Ben

Benjammin2068 writes:
> Hey all,
>
> New to list, so I apologize if this has been asked a bunch already...
>
>  Is there something I'm missing with Windows 10 as a guest that keeps  
> Windows Updates from nuking the boot process?
>
> I just did an orderly shutdown and windows updated itself <I forgot to  
> disable in time> only to reboot to the diagnostics screen which
couldn't
> repair.
>
> going to command prompt and doing the usual "bootrec /fixmbr, /fixboot
and
> /RebuildBcd" didn't help.
>
> This has happened a few times. I can't believe how fragile Win10pro is
while
> running in a VM.
>
> (and it's happened on a couple machines I've been experimenting
with -- both
> running same OS, but different hardware.)
>
> I just saw the FAQ about the libvirt repo for the virtio drivers for  
> windows.... I need to go read more on it...
>
> but in the meantime, is there any other smoking gun I'm not aware of?
(after
> lots of google searching)
I don't use virtio drivers. My Windows 10 guest setup is as plain as it can
be.

Starting with qemu 2.9, there is some kind of a problem that prevents  
Windows 10 from rebooting itself properly. I've also read about others  
reporting this issue as well. It's possible that the problem started before
2.9. Fedora 25, with qemu 2.4, was ok. Fedora 26, with qemu 2.9, was broken.

About 90% of the reboots end up in rescue mode, with Windows 10's rescue  
tool claiming, no what you do, that the system is not recoverable. Without  
really explaining why. Obviously, since it booted into rescue mode, the  
virtual disk is working, but the rescue tool does not see it. Note, that I  
do not use virtio, so this is not a factor.

However if you force off the VM, and do a fresh boot, nothing's wrong.
It'll
boot up like nothing happened. Your updates do not really mess up the boot  
process. It just looks this way.

Use "virsh edit" to edit your domain XML file in /etc/libvirt/qemu.
Replace
the existing <on_reboot> setting in there with:

<on_reboot>destroy</on_reboot>

Now, when Windows 10 updates reboot now, the virtual machine will turn off  
instead. After manually starting it again, it should boot fine.

If you're using virt-manager, it goes a bit wonky, when the VM shuts down  
with this setting in place, and virt-manager will get very confused. You'll
just need to close and restart virt-manager, to turn on the VM again.

On 11/25/2017 07:25 AM, Sam Varshavchik wrote:
>
> I don't use virtio drivers. My Windows 10 guest setup is as plain as it
can be.
>
> Starting with qemu 2.9, there is some kind of a problem that prevents
Windows 10 from rebooting itself properly. I've also read about others
reporting this issue as well. It's possible that the problem started before
2.9. Fedora 25, with qemu 2.4, was ok. Fedora 26, with qemu 2.9, was broken.
>
> About 90% of the reboots end up in rescue mode, with Windows 10's
rescue tool claiming, no what you do, that the system is not recoverable.
Without really explaining why. Obviously, since it booted into rescue mode, the
virtual disk is working, but the rescue tool does not see it. Note, that I do
not use virtio, so this is not a factor.
>
> However if you force off the VM, and do a fresh boot, nothing's wrong.
It'll boot up like nothing happened. Your updates do not really mess up the
boot process. It just looks this way.
>
> Use "virsh edit" to edit your domain XML file in
/etc/libvirt/qemu. Replace the existing <on_reboot> setting in there with:
>
> <on_reboot>destroy</on_reboot>
>
> Now, when Windows 10 updates reboot now, the virtual machine will turn off
instead. After manually starting it again, it should boot fine.
>
> If you're using virt-manager, it goes a bit wonky, when the VM shuts
down with this setting in place, and virt-manager will get very confused.
You'll just need to close and restart virt-manager, to turn on the VM again.
>
Thanks for the reply.

IIRC, I've even rebooted the system (host as well) with no success... but
maybe not. I'll try your suggestions again if I have an issue.

I really thought it was updates. I also don't use any VirtIO stuff either.
As plain and stock a setup as I can get.

Hopefully this glitch gets fixed soon. What a way to freak admins out. :P

Thanks,

 -Ben