I have a Server 2022 VM configured which is being shut down after what appears to be an arbitrary length of time.

 

This appears in the logs:

 

2021-09-10T21:36:41.927876Z qemu-system-x86_64: terminating on signal 15 from pid 4371 (/usr/sbin/libvirtd)
2021-09-10 21:36:42.157+0000: shutting down, reason=shutdown

 

I've had a search and can't find anything obvious relating to this problem.  The closest I could find was someone who's VMs were pausing and it was due to a full cache drive.  Mine is 500GB and only 25% full.  I tried a BTRFS balance for fun and it hasn't made any difference.

 

Any ideas?

 

Edited September 11, 20214 yr by CodeThief

Discovered there's a /var/log/libvirt/libvirtd.log and it has this entry for the same time:

 

2021-09-10 21:36:41.956+0000: 4648: error : qemuMonitorIO:578 : internal error: End of file from qemu monitor
 

2021-09-10 21:36:41.956+0000: 4648: error : qemuMonitorIO:578 : internal error: End of file from qemu monitor

 

Interestingly there's an entry in syslog at exactly the same time for a Docker container starting:

 

Sep 10 21:36:40 Server kernel: eth0: renamed from vethd78ed5c
Sep 10 21:36:40 Server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth0fea234: link becomes ready
Sep 10 21:36:40 Server kernel: docker0: port 6(veth0fea234) entered blocking state
Sep 10 21:36:40 Server kernel: docker0: port 6(veth0fea234) entered forwarding state
Sep 10 21:36:41 Server rc.docker: Komga: started succesfully!
Sep 10 21:36:41 Server kernel: docker0: port 7(veth28dce0c) entered blocking state
Sep 10 21:36:41 Server kernel: docker0: port 7(veth28dce0c) entered disabled state
Sep 10 21:36:41 Server kernel: device veth28dce0c entered promiscuous mode
Sep 10 21:36:41 Server kernel: docker0: port 7(veth28dce0c) entered blocking state
Sep 10 21:36:41 Server kernel: docker0: port 7(veth28dce0c) entered forwarding state
Sep 10 21:36:41 Server kernel: docker0: port 7(veth28dce0c) entered disabled state

 

Could be a coincidence?

Edited September 11, 20214 yr by CodeThief

It's just shut down again with no corresponding entry in syslog this time, so must have been a coincidence

OK, false alert, I had a look in the system log of the server and it's the Windows licensing management service that's shutting the machine down, not the VM host!