My Linux (Ubuntu) based VM reboots at specific time without any intervention of any user. VM reboots on its own. How can I troubleshoot this. Vm is on Hyperconverged infrastructure.

Hi Zafar,

Thank you for posting question on Microsoft Windows Forum!

Based on the issue description. well! Since physical host uptime and health are normal, it is reasonable to rule out node-level crash/eviction. To pinpoint the reason of why these Ubuntu VMs are rebooting on your HCI cluster, it is necessary to determine the origin of the reboot command. was it initiated gracefully from inside the guest OS, or was it a hard reset forced by the hypervisor?

The following are some suggestions which are worth checking in an attempt to troubleshoot the issue.

• Try to log into one of the affected Ubuntu VMs and check if the OS actually knew it was going down by running this command last -x | head -n 20 to check the reboot history and shutdown signals. For graceful reboot. If you see a shutdown entry immediately preceding the reboot entry, the OS initiated the restart. On the other hand, for hard reboot. If you see a reboot entry with no preceding shutdown, the hypervisor abruptly reset the VM.
• If the OS initiated the reboot, especially at "specific time intervals," the issue is highly probably an automated task or update policy within Ubuntu. Since Ubuntu has a feature that automatically installs security updates and can reboot the machine if a kernel update requires it. This might happen at specific times (like 06:00 AM). Try to check unattended upgrades. Also, check Cron Jobs and Systemd Timers by reviewing /var/spool/cron/crontabs/root and /etc/crontab for any scheduled reboots. Check timers with systemctl list-timers --all.
• Since the VMs are running on a cluster, check the hypervisor event logs around the exact timestamp of the VM reboot. You can consider to investigate Failover Cluster / Hypervisor Logs by lookinh specifically at FailoverClustering Operational logs. Did the cluster service momentarily lose heartbeat with the VM and attempt to restart it? Also, check the Hyper-V-Worker / VMMS logs for the specific VM's GUID. Look for Event IDs indicating state changes or worker process crashes. If the Cluster Shared Volume holding the VM's VHDX experiences a micro-outage or latency spike (even if the node stays up), the hypervisor will often pause or reset the VM to protect data integrity. Look for I/O timeout warnings in the host's system logs.

Hope the above information is helpful!