# Check Proxmox physical address bits before CPU-model migration > Review host-inherited physical address bits against intended migration targets before selecting a custom Proxmox CPU model. - Canonical URL: https://update.dsesecurity.com/updates/check-proxmox-physical-address-bits-before-cpu-model-migration/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T17:41:01+00:00 - Modified: 2026-10-29T17:41:38+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Review host-inherited physical address bits against intended migration targets before selecting a custom Proxmox CPU model. ## Potentially affected Proxmox VE administrators defining custom VM CPU models and live-migration destinations. ## DSE recommendation Compare the physical-address-bit choice across intended hosts and rehearse the named migration path without promising universal compatibility. ## Article 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](https://pve.proxmox.com/pve-docs/cpu-models.conf.5.html) 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)](https://pve.proxmox.com/pve-docs/cpu-models.conf.5.html) — 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. ## Primary reference - Name: Proxmox — cpu-models.conf(5) - Authority: pve.proxmox.com - URL: https://pve.proxmox.com/pve-docs/cpu-models.conf.5.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check Proxmox physical address bits before CPU-model migration,” DSE Security, https://update.dsesecurity.com/updates/check-proxmox-physical-address-bits-before-cpu-model-migration/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.