TopicGems: Why VMs Suddenly Restart

03:12:07. That was the last line in the log.

The next line was stamped 03:14:51, and it was a fresh boot message.

Nothing in between. No error, no shutdown notice, no warning. A VM in my home lab had vanished for two and a half minutes and come back like nothing happened. It did this four times in one week, always at some hour when I wasn't looking.

I did what most people do. I opened the VM's own logs and stared at them for two hours. That was the mistake. I was searching for a confession from a machine that never got the chance to say anything.

If you're dealing with a VM that keeps restarting on its own, the fastest way to save yourself that wasted time is one simple question.

The Goodbye Test

Before you check anything else, look at the last few lines before the restart and ask: did the VM say goodbye?

Almost every restart falls into one of three buckets:

It said goodbye. The logs show a clean shutdown sequence. Something asked the VM to restart, and it complied.
It screamed on the way out. The logs show a crash, a panic, or a bug check. The VM broke, then restarted itself.
Sudden silence. The logs just stop mid-sentence. The VM didn't choose anything. Something outside it pulled the plug.

Each bucket sends you to a different place to investigate, which is why this one question matters more than any tool.

Here's how to run the test:

On Windows guests, open Event Viewer → Windows Logs → System and look around the restart time for these:

Event ID 1074 means a process or user requested a planned restart. Goodbye.
Event ID 1001 (BugCheck) means a crash, and it records the stop code. Scream.
Event ID 41 (Kernel-Power) and 6008 ("the previous shutdown was unexpected") mean Windows came back up without a clean shutdown. Silence.

On Linux guests, run these:

last -x shutdown reboot
journalctl --list-boots
journalctl -b -1 -e

The last command shows the end of the previous boot, which is exactly the part you want. If --list-boots only shows one boot, your journal isn't persistent. Fix that with sudo mkdir -p /var/log/journal and sudo systemctl restart systemd-journald, so the next restart leaves evidence behind.

Bucket One: Somebody Asked It To Restart

These are the least dramatic causes, and the most embarrassing when you find them.

Automatic updates. Windows Update restarting outside your active hours is the classic one. On Ubuntu and Debian, check /etc/apt/apt.conf.d/50unattended-upgrades for Unattended-Upgrade::Automatic-Reboot "true". If it's on, the VM will reboot itself at whatever time is set next to it. It's a great feature on a server you're not watching, and a confusing one on a lab VM you forgot about.

Evaluation licenses expiring. This one caught me completely off guard. I had a Windows Server evaluation VM in the lab that started shutting itself down roughly every hour. No crash, no error, just a tidy shutdown and restart on repeat. The evaluation period had ended, and Windows was politely making the VM unusable until someone activated it. If a test VM is restarting on a suspiciously regular schedule, check the license status before anything else.

Automation you forgot you wrote. A cron job with shutdown -r, a scheduled task, an Ansible playbook, a monitoring tool with an "auto-remediate" setting. If the restart happens at the same minute every day, this is your first suspect. A regular pattern almost always means a human or a script set it up.

Bucket Two: The VM Crashed and Restarted Itself

Here the guest OS hit a fatal error, then rebooted because it was configured to.

On Windows, that's a blue screen, except you often never see it, because "Automatically restart" is ticked by default. The VM crashes, reboots, and all you notice is the uptime resetting. To catch the stop code, go to System Properties → Advanced → Startup and Recovery → Settings and untick Automatically restart. Alternatively, look in C:\Windows\Minidump after the next crash. Turn auto-restart back on afterwards if it's a production machine.

On Linux, the equivalent is a kernel panic. Check cat /proc/sys/kernel/panic. If it's a number above zero, the kernel waits that many seconds after a panic and then reboots. A value of zero means it just hangs, which is honestly easier to debug.

Typical culprits in this bucket are a bad driver, a mismatched virtual hardware version, a memory-hungry process exhausting the guest's RAM, or a corrupted filesystem. If the crash started right after you changed something (a kernel update, a new driver, a hypervisor upgrade), you've probably found your answer.

There's also a sneaky variant. If a VM has a watchdog device configured (Proxmox and libvirt both support this), the hypervisor will reset it whenever the guest stops responding, even if the guest is only badly overloaded. It looks like a random reboot, but it's the safety net doing its job.

Bucket Three: Sudden Silence

This is the scary one, and it was mine. The logs just stop. The guest didn't crash, didn't shut down, and didn't do anything wrong. Something below it ended the VM.

Here are the usual suspects:

The host ran out of memory. If you give VMs more RAM in total than the host really has, the host's Linux kernel may start killing processes to survive, and a running VM is just a big process. It picks one and kills it. Your VM dies instantly with no goodbye. If it's set to auto-start or is part of an HA setup, it comes right back, which makes the whole thing look like a mysterious reboot.

The host itself restarted. Patching, a power blip, a crash, a thermal shutdown. Mini PCs and old desktops used as lab hosts overheat more often than people admit.

High availability did its job. In VMware, vSphere HA restarts VMs when a host fails, and its VM Monitoring feature can also reset a VM if it stops sending heartbeats and I/O. Proxmox HA and Hyper-V clusters can do similar things. You'll see "restarted by HA" in the event log, but only if you look at the host side.

The storage filled up or hiccuped. When a datastore runs out of space, VMs typically freeze or pause. Hyper-V calls this state "Paused-Critical." Someone or something then hits reset, and it gets recorded as a restart. Snapshot chains that grow forever are a classic cause of this. I covered how that happens in How VM Snapshots Work.

Cloud maintenance and interruptions. On AWS, Azure, or Google Cloud, the provider may reboot the underlying host for maintenance. Spot and preemptible instances can be reclaimed with very little notice. A failed status check with an auto-recovery alarm attached will also restart an instance for you.

Triple faults. This one is rare but real. If the guest CPU hits an error so bad it can't even handle the error handler, the virtual CPU resets. Hypervisors often just reboot the VM, and the guest sees an instant restart with zero log entries. If the silence is total and the host looks perfectly healthy, suspect this or a hardware fault.

So What Was My 3 AM Mystery?

The host ran out of RAM.

I had an 8 GB Ubuntu VM running a SIEM test setup, plus two other VMs, on a lab host with 16 GB of physical memory. Add ballooning and the host's own overhead, and I'd promised more memory than I owned. Around 3 AM, a scheduled indexing job made the big VM actually use what I'd given it, and the host panicked.

I only found it because I finally stopped reading the VM's logs and ran this on the host:

dmesg -T | grep -i "out of memory"

There it was: a line saying the kernel had killed the kvm process for that VM. HA brought it back two and a half minutes later, which explained the gap between the two timestamps.

The fix was boring. I trimmed the VM's RAM, stopped overcommitting, and put the indexing job on a schedule that didn't collide with everything else. It hasn't restarted since.

The lesson was bigger than the fix, though. When a VM's logs go quiet right before a restart, the answer is not in the VM.

Also Read: What Happens When Cloud Resources Are Fully Used

Where to Look, Platform by Platform

Once the Goodbye Test tells you which side of the fence you're on, here's where the evidence usually lives:

VMware Workstation / ESXi: vmware.log sits in the VM's own folder. In vCenter, check the VM's Events tab for HA or monitoring entries.
VirtualBox: the VBox.log file inside the VM's Logs folder. Look at how the log ends.
Hyper-V: Event Viewer → Applications and Services Logs → Microsoft → Windows → Hyper-V-Worker and Hyper-V-VMMS. Failover Cluster events matter if you run a cluster.
Proxmox: the task log in the web UI, plus journalctl -k | grep -i oom and the HA status page on the host.
AWS: EC2 → Instance → Status checks and Scheduled events, plus the instance's system log from the Actions menu.
Azure and Google Cloud: the Activity Log or Logs Explorer for host maintenance, auto-restart, and preemption events on that VM.

The Order I Check Things Now

This is the routine I run every time now, in this order, because each step rules out the cheapest explanations first:

Note the exact restart time, then check whether it repeats on a schedule. Regular patterns point at updates, cron jobs, or license expiry.
Run the Goodbye Test in the guest logs to sort it into goodbye, scream, or silence.
If it said goodbye, look for the thing that asked: Windows Update, unattended-upgrades, scheduled tasks, or automation.
If it screamed, capture the stop code or panic message. Temporarily disable auto-restart if you need to see it on screen.
If it went silent, leave the guest and check the host: memory pressure, host reboots, thermal logs, HA events, and datastore free space.
In the cloud, check the provider's event log and status checks before assuming your VM is at fault.
Fix the visibility problem too. Make journal logs persistent, keep a few weeks of host logs, and set an alert for host memory and disk. The next restart shouldn't be a mystery.

Fixes That Wasted My Time

I tried these before finding the real cause, so you don't have to:

Reinstalling VMware Tools or guest additions. They weren't the problem, and it added a variable.
Giving the VM even more RAM. It made things worse. The host was the one running out.
Rebuilding the VM from scratch. Two hours of setup to discover the fresh VM restarted at 3 AM too.
Blaming the last update. It was convenient, but the timing was a coincidence.

Restarts feel random, but they almost never are. Something always made the decision, and the trick is figuring out whether it was the VM or someone above it. Start with the goodbye, follow the silence, and check the host sooner than feels natural.