A Proxmox VM disk can be a file, a logical volume, a ZFS volume, a Ceph object or part of a backup archive. Finding something named like vm-…-disk-… does not prove which guest owns it, whether it is current, or whether it contains a complete recoverable machine.

Freeze and identify the source

Stop avoidable writes and record cluster/node, Proxmox version, guest configuration, storage definitions and current guest state. Confirm whether the source VM is running and whether snapshots, replication or backup jobs are active.

Map every guest disk, EFI disk, TPM state disk, cloud-init disk and externally mounted data source. Record firmware type (SeaBIOS/OVMF), machine type, controller/bus, boot order, MAC/IP identity and encryption keys.

Use Proxmox storage tools to resolve storage volume IDs to their backend/path. Do not infer from filenames alone, especially on shared or thin-provisioned storage.

If underlying storage is failing, capture/recover it before repeated conversion. Conversion reads the entire source and can accelerate failure.

Prefer a complete supported backup

If a valid vzdump or Proxmox Backup Server recovery point exists, inspect its configuration and use the supported restore workflow. A backup can include guest configuration that a loose disk lacks.

Verify backup integrity and date, external/bind-mounted data exclusions and application-consistency status. A snapshot-mode backup may be crash-consistent unless guest-agent/application coordination was configured.

Use loose-disk import when that is the available trustworthy artefact or an intentional migration—not merely because it seems faster.

Preserve the original

Create a verified independent copy or storage snapshot according to the backend before conversion or repair. Record size, format and checksum where meaningful. Keep the original read-only.

Be careful with qcow2 backing chains and VMware descriptor/flat-file pairs. Copying only the small descriptor or top layer can produce an apparently valid but incomplete image. Resolve and preserve the full dependency chain.

Do not use dd with guessed devices. A reversed source/destination overwrites evidence immediately.

Inspect without booting

Identify image format with a tool that reads metadata rather than trusting the extension. Check virtual size, backing files/snapshots and integrity warnings. Mount or inspect filesystems read-only through an isolated recovery environment when possible; do not let the host auto-repair guest filesystems.

For encrypted guest volumes, use authorised guest recovery keys. Proxmox storage access does not bypass BitLocker, LUKS or application encryption.

Import into the intended storage

Proxmox documents qm disk import for importing/converting an accessible image into a target VM and storage. The imported volume appears as an unused disk until deliberately attached.

Before importing, create or select the correct empty/test VM, verify its VMID and target storage, check capacity and choose a format supported by that backend. File storage may support raw or qcow2; block storage commonly requires raw volumes.

Record the exact source checksum, target volume ID and command/result. Do not delete the source after a successful import message.

Attach the imported unused disk using a controller the guest can boot. A migrated Windows guest may initially need SATA/IDE if VirtIO drivers were not prepared; change to VirtIO only after installing/verifying supported drivers. Linux guests may also need initramfs/controller adjustments.

Match firmware: an OVMF/UEFI guest may need its EFI disk and boot entry; a TPM-backed Windows guest may need TPM state and BitLocker recovery planning. Set boot order explicitly.

Boot in isolation

Disconnect or isolate the virtual NIC before first boot so source and recovered guest cannot share hostname, IP, domain identity, database or scheduled jobs. Keep the original VM off.

Observe firmware, boot loader, storage drivers and filesystem checks. Repair only the identified guest layer. Do not convert image formats repeatedly to fix a missing driver or wrong firmware setting.

Once stable, reconcile guest agent, time, CPU/machine type, NIC model, MAC/IP, DNS, certificates, licences and management/backup agents.

Verify data and workload

Acceptance requires:

  • all expected virtual disks and special state volumes attached;
  • repeated clean boot and shutdown;
  • guest filesystems/data counts and selected hashes consistent;
  • application-native integrity and representative transactions pass;
  • network identity is unique before connection;
  • performance/trim/discard and storage features match the design;
  • Proxmox backup completes from the recovered guest and a sample restore is readable; and
  • original evidence remains available through the rollback period.

If only data is needed, restore or copy it into a controlled new guest rather than making an obsolete or compromised OS live again.

Disk recovery is complete when the right data and workload run under a complete, owned Proxmox configuration—not when a converted volume appears in the Hardware tab.