Which method yields a repeatable CI environment: Hyper‑V checkpoints or clean VHDX clones?

Goal

Establish a development environment that can be reliably reproduced across CI pipeline runs, minimizing drift caused by host‑level changes.

Constraints

• Hyper‑V hosts may receive OS patches or be upgraded to newer Windows Server releases.
• Checkpoints capture the entire VM state, but the Hyper‑V API does not guarantee deterministic consistency after a host upgrade.
• Cloning a fresh VHDX image provides a known baseline but increases storage usage and pipeline transfer time.
• Dynamic memory and nested virtualization settings can affect restore behavior.

Unresolved Behavior

When a Hyper‑V host is upgraded, restoring a checkpoint can lead to silent corruption of virtual disk metadata or loss of network configuration, yet the exact failure modes are not fully documented. It is unclear whether cloning a clean VHDX image shields the environment from these inconsistencies or merely masks subtle drift that checkpoints would expose.

Questions

How does Hyper‑V handle checkpoint consistency after a host OS upgrade, and can checkpoints be relied upon for deterministic CI builds?

What impact do dynamic memory settings and nested virtualization drivers have on the stability of checkpoint restores across host upgrades?

Does cloning a clean VHDX image guarantee a reproducible baseline in CI pipelines, or does it conceal host‑level changes that checkpoints would otherwise expose?