Field note: bringing a virtual server back after its storage died

A storage array on a small Hyper-V host failed. After the dust settled, one important virtual server wouldn’t start, and restore attempts kept throwing errors. The business ran its core application on that server, so the pressure was on.

What was wrong

The virtual machine’s configuration still pointed at a saved state (a snapshot of its memory, like a paused laptop) that had lived on the failed array. That saved state was corrupt and unreachable, and Hyper-V kept trying to resume from it.

But the virtual machine’s actual disk file (the VHDX) was stored on a different, healthy drive, and it was intact.

The fix

Rather than fighting the broken saved state, we re-registered the virtual machine from its existing VHDX on the healthy drive: a clean VM definition pointing at the good disk, with no saved state. It booted normally.

Before calling it done:

1. Have a real user confirm the application works, not just that the server is up.
2. Check every other VM’s storage paths to make sure nothing else still points at the dead array.
3. Stagger VM startup on the host with automatic start delays, so the next host reboot doesn’t start everything at once.

What I took away from it

• Separate the VM’s disk from its configuration and saved state when troubleshooting. The data may be fine even when the VM won’t start.
• Saved states are fragile. For servers, a clean shutdown is safer than saving state during host maintenance.
• Know where every VM’s files actually live, before a failure forces you to find out.
• “It’s up” isn’t “it works.” Confirm with the people who use it.