Check Proxmox physical address bits before CPU-model migration

Bottom line: Review physical address bits as an explicit migration constraint rather than accepting a custom-model example unchanged. Keep the chosen value, intended destinations and guest requirements together before approving the CPU definition.

Source fact: what the authority says

The Proxmox CPU-model manual says phys-bits controls the physical memory address bits reported to the guest and should not exceed the host value. Setting phys-bits to host uses the host CPU value and breaks live migration to CPUs with different values. Custom model names omit the custom- prefix in the definition file but require that prefix in the VM configuration. The manual distinguishes additional custom-model CPU flags from the restricted set permitted as VM-specific flags.

What the source does not establish

These are documented CPU-definition rules, not proof that any chosen value makes two hosts migration-compatible. This article does not qualify all guest CPU features, QEMU versions, devices or storage paths involved in a move.

Applicability questions

• Which exact hosts are intended migration destinations for this VM?
• What physical-address-bit values do those hosts expose through approved inspection?
• Does the custom definition inherit host or state an explicit value?
• Which guest requirements and other migration constraints need separate review?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a host comparison sheet with the current source and every approved destination listed separately. Record the observed CPU information and the proposed model value without inventing a universal minimum. Ask the virtualization owner to resolve inconsistent observations before selecting the definition.

Keep the model-definition name and VM selection string in the same review. Check the required custom- reference against the actual file entry so a naming mistake is not confused with a CPU capability problem. Preserve the previous model and guest configuration before changing either.

Review additional flags independently from the physical-address-bit setting. Do not copy a sample flag set solely because the guest starts on one host. Have the workload owner identify required guest behavior and choose a representative disposable or expressly approved VM for the trial.

Define the permitted source and destination directions before the migration rehearsal. Keep authentication, network, storage and device checks in their own parts of the plan. An unexplained failure should remain a finding rather than prompting several simultaneous CPU and infrastructure changes.

Verification and evidence

Proposed verification: inspect the effective guest CPU selection and compare it with the reviewed model definition. Rehearse the named migration path under the approved conditions, recording both hosts, the configured physical-address-bit choice and the actual result.

After the move, run the agreed guest workload check and preserve any reported CPU or application error. If return migration is required, include it explicitly instead of assuming the forward result covers it. Accept only the tested host relationship and reopen the review when the permitted host population or CPU definition changes.

Official references

• Proxmox — cpu-models.conf(5) — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.