[libvirt-users] 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
On 11/27/2017 05:28 PM, Benjammin2068 wrote:
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
Hmm.. could this somehow be related to the fast startup thing in win10? I mean, if fast startup is disabled, will that help? Just a thought. /tony Tony Albers Systems administrator, IT-development Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark. Tel: +45 2566 2383 / +45 8946 2316
Tony Brian Albers writes:
On 11/27/2017 05:28 PM, Benjammin2068 wrote:
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
Hmm.. could this somehow be related to the fast startup thing in win10? I mean, if fast startup is disabled, will that help?
Just a thought.
Fast startup does not get utilized for reboots, only for regular shutdowns. The actual option in Windows settings reads: "This helps starts your PC faster after shutdown. Restart isn't affected."
On 11/28/2017 12:53 PM, Sam Varshavchik wrote:
Tony Brian Albers writes:
On 11/27/2017 05:28 PM, Benjammin2068 wrote:
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
Hmm.. could this somehow be related to the fast startup thing in win10? I mean, if fast startup is disabled, will that help?
Just a thought.
Fast startup does not get utilized for reboots, only for regular shutdowns. The actual option in Windows settings reads:
"This helps starts your PC faster after shutdown. Restart isn't affected."
Thanks, I wasn't sure about that. So a restart/reboot is closer to a cold-start than a shutdown and power-up is. Makes sense.... Yeah, I know there's a way to disable fast-start end also to avoid it when shutting down. So restart avoids the hibernation-thing that fast start uses, but does it do so to full extent? If it saves just the least bit of info, that could be the reason for the boot issue. Just me thinking.. I haven't really used windows for the last 17 yrs. /tony -- Tony Albers Systems administrator, IT-development Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark. Tel: +45 2566 2383 / +45 8946 2316
Tony Brian Albers writes:
Hmm.. could this somehow be related to the fast startup thing in win10? I mean, if fast startup is disabled, will that help?
Just a thought.
Fast startup does not get utilized for reboots, only for regular shutdowns. The actual option in Windows settings reads:
"This helps starts your PC faster after shutdown. Restart isn't affected."
Thanks, I wasn't sure about that. So a restart/reboot is closer to a cold-start than a shutdown and power-up is. Makes sense....
Yeah, I know there's a way to disable fast-start end also to avoid it when shutting down.
So restart avoids the hibernation-thing that fast start uses, but does it do so to full extent? If it saves just the least bit of info, that could be the reason for the boot issue.
It's also entirely possible that "Restart isn't affected" part refers only to restarts that get initiated after applying system updates, so a manually- initiated restart still hibernates, despite this claim otherwise.
Just me thinking.. I haven't really used windows for the last 17 yrs.
Well, some Googling around found the instructions for disabling fast start up in Windows 10. Then, I took a Windows 10 guest that I successfully nursed through the fall creator's update by manually starting it for every reboot. The host was also updated to Fedora 27 and qemu 2.10 during the same timeframe. I reenabled the reboots in domain XML file, and disabled fast startup in Windows 10. So far, I've succesfully rebooted that VM twice without any issues. I'll probably need to reboot it 3-4 times more, before cautiously marking this as a solved issue; but not quite sure whether the deciding factor is the fall creator's update, qemu 2.10, or disabling fast startup. I have not noticed any marked difference in the actual startup speed. If anything, Windows seems to boot a bit faster, and the CPU utilization seems to settle down pretty quickly, after a reboot. Which kind of makes sense, actually, now that I'm aware of the fast startup "feature", and I find it absolutely hillarious. See: if Windows was really hibernating, then after it boots up the dumb thing obviously wants to immediately kick off every frigging last scheduled task it has, since it probably came due during the time the whole bloody thing was off. I always had a laugh looking at virt-manager showing the guest pegging the CPU at 100% for 10-30 minutes after I start up the VM. That's Windows for you. Well, now, with the fast startup disabled, the virtual CPU settles down pretty quickly. Also the system startup audio chime reliably plays every time now, too. I guess waking up from hibernation doesn't merit the audio chime.
On 2017-11-29 01:28, Sam Varshavchik wrote:
Tony Brian Albers writes:
Hmm.. could this somehow be related to the fast startup thing in win10? I mean, if fast startup is disabled, will that help?
Just a thought.
Fast startup does not get utilized for reboots, only for regular shutdowns. The actual option in Windows settings reads:
"This helps starts your PC faster after shutdown. Restart isn't affected."
Thanks, I wasn't sure about that. So a restart/reboot is closer to a cold-start than a shutdown and power-up is. Makes sense....
Yeah, I know there's a way to disable fast-start end also to avoid it when shutting down.
So restart avoids the hibernation-thing that fast start uses, but does it do so to full extent? If it saves just the least bit of info, that could be the reason for the boot issue.
It's also entirely possible that "Restart isn't affected" part refers only to restarts that get initiated after applying system updates, so a manually-initiated restart still hibernates, despite this claim otherwise.
Just me thinking.. I haven't really used windows for the last 17 yrs.
Well, some Googling around found the instructions for disabling fast start up in Windows 10.
Then, I took a Windows 10 guest that I successfully nursed through the fall creator's update by manually starting it for every reboot. The host was also updated to Fedora 27 and qemu 2.10 during the same timeframe.
I reenabled the reboots in domain XML file, and disabled fast startup in Windows 10. So far, I've succesfully rebooted that VM twice without any issues. I'll probably need to reboot it 3-4 times more, before cautiously marking this as a solved issue; but not quite sure whether the deciding factor is the fall creator's update, qemu 2.10, or disabling fast startup.
I have not noticed any marked difference in the actual startup speed. If anything, Windows seems to boot a bit faster, and the CPU utilization seems to settle down pretty quickly, after a reboot. Which kind of makes sense, actually, now that I'm aware of the fast startup "feature", and I find it absolutely hillarious.
See: if Windows was really hibernating, then after it boots up the dumb thing obviously wants to immediately kick off every frigging last scheduled task it has, since it probably came due during the time the whole bloody thing was off. I always had a laugh looking at virt-manager showing the guest pegging the CPU at 100% for 10-30 minutes after I start up the VM. That's Windows for you. Well, now, with the fast startup disabled, the virtual CPU settles down pretty quickly.
Also the system startup audio chime reliably plays every time now, too. I guess waking up from hibernation doesn't merit the audio chime.
I can't say I'm surprised, but thanks a lot for the info. Saves me the time of testing. -- Tony Albers Systems administrator, IT-development Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark. Tel: +45 2566 2383 / +45 8946 2316
Hey all, This horrid bug seems to be back after the system got all sloggy slow so I logged in via RDP and asked Windows to reboot. It was taking forever for RDC to come back, so I logged into the system and brought up KVM GUI which displayed Windows showing the login backdrop with "Restarting..." and the spinning dots. After about 20min, I gave up and clicked the hardware reset. Now the system is broken with the "Starting automatic repair" and that it can't fix the PC and throws me into the Auto-Repair advanced options. Thoughts? Thanks, -Ben p.s. this is LibVirt 3.2.0-14.el7_4.7
Why do you reckon this is to do with your virtualisation system (presumably qemu/kvm, though you don't say) rather than Windows 10? Peter On 13 Feb 2018 7:06 p.m., "Benjammin2068" <benjammin2068@gmail.com> wrote:
Hey all,
This horrid bug seems to be back after the system got all sloggy slow so I logged in via RDP and asked Windows to reboot.
It was taking forever for RDC to come back, so I logged into the system and brought up KVM GUI which displayed Windows showing the login backdrop with "Restarting..." and the spinning dots.
After about 20min, I gave up and clicked the hardware reset.
Now the system is broken with the "Starting automatic repair" and that it can't fix the PC and throws me into the Auto-Repair advanced options.
Thoughts?
Thanks,
-Ben
p.s. this is LibVirt 3.2.0-14.el7_4.7
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
On 02/13/2018 01:25 PM, Peter Crowther wrote:
Why do you reckon this is to do with your virtualisation system (presumably qemu/kvm, though you don't say) rather than Windows 10?
The past conversation in this thread indicated an interplay issue between Win10 and libvirt. (and yes, it's qemu/kvm. My apologies, this is a continued thread subject hopefully searchable showing this was covered.) While one could say there are plenty of systems out there running Win10 natively without this problem (although from what I've read on MS's forums, may this is arguable)... I figured I'd start here first since the previous discussion did indicate there were some past issues LibVirt could do better to deal with Win10. The folks here are wayyyyyy more competent about the interaction than what I'd be able to find on MS website. Cheers, -Ben
participants (4)
-
Benjammin2068 -
Peter Crowther -
Sam Varshavchik -
Tony Brian Albers