On Wed, 2018-06-06 at 15:04 +0200, Wolfgang Pfeiffer wrote: > On Wed, Jun 06, 2018 at 01:40:59PM +0100, Patrick O'Callaghan wrote: > > On Wed, 2018-06-06 at 14:05 +0200, Wolfgang Pfeiffer wrote: > > > > > > To search for reboots I'd click the "Find" menu, right hand side-bar, > > > if Google images is correct, and then search for "clean" - because > > > that's the word, IIRC, the logs use to announce that some disk is > > > "clean" after a reboot (!). > > > > In fact there's a 'Kernel boot' event which coincides with the last > > time I rebooted the host, so it looks like it is forcing a guest reboot > > either directly or implicitly through a GPU reset. There's also a > > 'Kernel power' event with a comment saying the kernel was rebooted > > unexpectedly, > > If that "unexpectedly" means the system crashed, I'd investigate > ... ;) As I said earlier, my conjecture is that it reboots because a hardware reset has affected the GPU. Recall that my setup is different from most normal users'. I have a second GPU (Nvidia GTX-1050) assigned exclusively to the VM (so not visible to Linux) and used via VFIO, i.e. the Windows drivers access it directly with no emulation. When the host reboots, the host hardware reset will also reset the Nvidia card, but a) Linux won't know about it, and b) Windows, even if frozen and restored by KVM/QEMU, will suddenly find the state of the GPU to have reset under its feet. [Note that even if QEMU explicitly signalled Windows to hibernate, this still wouldn't work because the Windows Nvidia driver doesn't support saving and restoring the state of the GPU. As far as I can see, a physical Windows desktop machine with this configuration would not be able to hibernate and restore, essentially for the same reason.] So (and this is a guess) Windows decides something is wrong and reboots itself to get to a known state. It probably does this after being frozen and restored by KVM/QEMU, but the effect is the same. > Again: there should also be some "health" line (or something like > that) about your client disk in these logs, after reboot - tho I've > heard, IIRC, that NTFS were rather robust when it comes to > crashes. But I never could verify the latter. > > > though curiously this is timestamped 5 seconds *after* > > the reboot event (probably just means the log was committed after > > rebooting). > > Same with Linux journalctl, at times: e.g. the system starting sleep > mode is tagged with times when the machine is actually up and running > again, after sleep-mode ... Sure. Makes sense. poc _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx/message/BFLKQ462ULOT7IYQ3UOIFSQCVAT45DIA/
