[libvirt-users] kvm/libvirt on CentOS7 w/Windows 10 Pro guest

[Tony Brian Albers]

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