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