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.
\nThe 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.
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.
\nhost or state an explicit value?The following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nKeep 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.
\nDefine 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.
\nProposed 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.
\nAfter 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThese 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.\nApplicability questions\n\nWhich exact hosts are intended migration destinations for this VM?\nWhat physical-address-bit values do those hosts expose through approved inspection?\nDoes the custom definition inherit host or state an explicit value?\nWhich guest requirements and other migration constraints need separate review?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nKeep 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.\nReview 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.\nDefine 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.\nVerification and evidence\nProposed 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.\nAfter 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.\nOfficial references\n\nProxmox — cpu-models.conf(5) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [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.\n\n## What the source does not establish\n\nThese 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.\n\n## Applicability questions\n\n- Which exact hosts are intended migration destinations for this VM?\n\n- What physical-address-bit values do those hosts expose through approved inspection?\n\n- Does the custom definition inherit host or state an explicit value?\n\n- Which guest requirements and other migration constraints need separate review?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nKeep 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.\n\nReview 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.\n\nDefine 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.\n\n## Verification and evidence\n\nProposed 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.\n\nAfter 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.\n\n## Official references\n\n- [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.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/check-proxmox-physical-address-bits-before-cpu-model-migration/", "url": "https://update.dsesecurity.com/updates/check-proxmox-physical-address-bits-before-cpu-model-migration/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-proxmox-physical-address-bits-before-cpu-model-migration/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Business Continuity", "item": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "ListItem", "position": 3, "name": "Check Proxmox physical address bits before CPU-model migration", "item": "https://update.dsesecurity.com/updates/check-proxmox-physical-address-bits-before-cpu-model-migration/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-proxmox-physical-address-bits-before-cpu-model-migration/#article", "identifier": "https://update.dsesecurity.com/updates/check-proxmox-physical-address-bits-before-cpu-model-migration/", "url": "https://update.dsesecurity.com/updates/check-proxmox-physical-address-bits-before-cpu-model-migration/", "headline": "Check Proxmox physical address bits before CPU-model migration", "description": "Review host-inherited physical address bits against intended migration targets before selecting a custom Proxmox CPU model.", "abstract": "Review host-inherited physical address bits against intended migration targets before selecting a custom Proxmox CPU model.", "articleBody": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThese 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.\nApplicability questions\n\nWhich exact hosts are intended migration destinations for this VM?\nWhat physical-address-bit values do those hosts expose through approved inspection?\nDoes the custom definition inherit host or state an explicit value?\nWhich guest requirements and other migration constraints need separate review?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nKeep 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.\nReview 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.\nDefine 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.\nVerification and evidence\nProposed 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.\nAfter 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.\nOfficial references\n\nProxmox — cpu-models.conf(5) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T17:41:01+00:00", "dateModified": "2026-10-29T17:41:38+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-proxmox-physical-address-bits-before-cpu-model-migration/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/check-proxmox-physical-address-bits-before-cpu-model-migration/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Check Proxmox physical address bits before CPU-model migration" }, "articleSection": [ "Business Continuity", "Networks & Infrastructure" ], "keywords": [ "Business Continuity", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 504, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Proxmox — cpu-models.conf(5)", "url": "https://pve.proxmox.com/pve-docs/cpu-models.conf.5.html" } } ] } }