libvirt users - Feb 2018 - Re: kvm/libvirt on CentOS7 w/Windows 10 Pro guest

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
>