Skip to main content

Veeam IR Mount Instability During OS-Level Changes

Document Type: Known Issue / Troubleshooting Reference Audience: L2 / L3 Last Updated: March 2026 Source Ticket: HALO 1136749 — McLean Family Dentistry


Symptoms

  • A VM running via Veeam Instant Recovery (IR) BSODs during Windows cumulative update installation.
  • A VM running via Veeam IR BSODs during an in-place OS upgrade reboot.
  • After the BSOD, the VM shows "Boot failure. Reboot and Select proper Boot device" — the IR mount may or may not survive.
  • The IR session itself may remain active in Veeam (the mount is not broken), but the guest OS cannot boot due to the failed update/upgrade rollback.

Root Cause

Veeam Instant Recovery serves the VM's VHDXs from the backup repository over the network via a redirect driver. The VM's disk I/O goes through:

VM → Hyper-V → Veeam redirect driver → network → backup repository

During an OS upgrade or cumulative update:

  1. Windows replaces system files, drivers, and kernel components across multiple reboots.
  2. Each reboot requires the boot disk to be accessible and consistent.
  3. If a BSOD occurs during the driver transition phase (e.g., VMBus components being updated), the VM hard-crashes.
  4. The hard crash may or may not sever the Veeam redirect connection depending on how the I/O was interrupted.
  5. Even if the IR mount survives, Windows detects the failed update and attempts rollback — but the rollback itself requires stable disk I/O through the same redirect path.

The fundamental issue: OS-level changes that involve multiple reboots and driver stack transitions are too sensitive for the additional I/O latency and failure modes introduced by the IR redirect path. A local disk has zero dependency on network transport or redirect drivers during reboot.

What Was Tested

On HALO 1136749, the following were attempted on a Veeam IR mount:

Operation Result
Windows cumulative update (KB5078938) via sconfig BSOD: CRITICAL_PROCESS_DIED during update installation
In-place upgrade Server 2016 → 2019 BSOD during upgrade reboot — Windows rolled back
In-place upgrade retry (after fixing PXE boot order) BSOD during second upgrade reboot
Normal VM operation (boot, login, run applications) Stable — no issues
Adding/changing NIC configuration on live VM BSOD (but this was the IC incompatibility, not IR-specific)

Key observation: The IR mount was stable for normal operations. BSODs only occurred during OS-level changes that involved driver stack transitions during reboot.

Rule

Never perform OS-level changes on a Veeam IR mount.

This includes:

  • Windows cumulative updates
  • In-place OS upgrades
  • Driver updates that require reboot
  • Integration Services updates
  • Any operation that modifies boot-critical system files

Correct Procedure

  1. Use IR only for validation — boot the VM, verify applications work, confirm data integrity.
  2. Migrate to Production — Veeam copies the VHDXs from the backup repository to local disk on the Hyper-V host. This eliminates the redirect driver dependency.
  3. After migration completes, the VM runs entirely on local storage. All reboots hit local disk with zero network dependency.
  4. Take a Hyper-V checkpoint on the local VM — instant rollback safety.
  5. Now perform OS-level changes — upgrades, updates, driver changes. If anything BSODs, revert the checkpoint in 30 seconds.

Migration Sequence

IR → Boot → Validate apps/data → Migrate to Production → Local disk
→ Checkpoint → OS upgrade → Validate → Delete checkpoint

Time Expectations

Migrate to Production copies the full VHDX data from the backup repository to local disk. For a typical dental server migration:

Data Size Approximate Time
200 GB 30-45 minutes
500 GB 1-2 hours
845 GB 2-3 hours

The VM remains running during migration (Veeam handles the I/O cutover transparently), but network disruption inside the VM may occur briefly during the final cutover. This is expected — bounce the NIC inside the VM after migration completes if connectivity is lost.

Additional Notes

  • IR mount stability is not the issue. On HALO 1136749, the IR mount survived multiple VM crashes, force stops, and NIC rebuilds without breaking. The Veeam redirect is robust for normal I/O. The issue is specifically driver stack transitions during reboot.
  • Mounting the source VHDX on the old host while an IR is active from the same backup WILL break the IR. Do not simultaneously access backup data from two paths. Stage any file copies before or after the IR, not during.
  • Checkpoint on IR mount is possible but provides limited safety — if the VM BSODs and the IR mount disconnects, the checkpoint is useless because the underlying VHDXs are inaccessible. A checkpoint on local disk is the only reliable rollback mechanism.
  • Server 2016 Integration Services Incompatibility with Server 2025 Hyper-V Host — the IC issue that required OS-level changes
  • Windows Server In-Place OS Upgrade SOP (Page 1067) — upgrade procedure (assumes local disk)
  • Veeam Troubleshooting Playbook (Page 1115) — general Veeam troubleshooting
  • HALO 1136749 — McLean Family Dentistry — source ticket