Bottom line: Record the machine type actually assigned to the guest before assessing a destination. Distinguish Ubuntu-specific support from the mere availability of an upstream type, especially in a cross-vendor plan.
\nThe QEMU Machine types documentation is the primary reference.
\nUbuntu’s guide describes a QEMU machine type as the guest’s virtual-hardware definition. The guide connects Ubuntu’s distro-specific machine types with its LTS-to-LTS live-migration support. Ubuntu retains upstream machine types but provides them as-is without further guarantees. The guide says cross-vendor or downstream migration using those upstream types may work but is considered unsupported.
\nThis article classifies a documented support boundary. It does not assert that every libvirt guest stores an unversioned alias, that a host upgrade automatically changes its virtual hardware or that matching machine-type names guarantee migration. Keep CPU compatibility, guest hardware changes and workload recovery under separate procedures.
\nDSE recommends a migration review that begins with the actual guest definition, not the host’s default alias or a remembered creation choice. Record the exact type, relevant host software and the intended destination. Have the virtualization owner classify that type against the appropriate Ubuntu documentation before approving the plan.
\nIf the recorded definition uses an alias, investigate its actual resolution and the deployment’s supported handling before drawing a compatibility conclusion. Do not assume that every guest has this condition or that an ordinary host upgrade performs a guest machine-type change. Preserve the definition as evidence of what is actually being reviewed.
\nFor a cross-vendor proposal, obtain an explicit support decision rather than treating a listed upstream type as assurance. Keep the vendor or distribution boundary visible in the change request. Ask the workload owner to accept an independent recoverable path before an unsupported migration is considered.
\nSeparate any proposal to change the guest’s machine type from the migration itself. Require its own guest-hardware assessment and approved maintenance procedure. Do not alter several compatibility dimensions at once to obtain a successful start that cannot be explained or reproduced.
\nProposed verification: assemble a read-only review record from a designated nonproduction guest and intended destination. Compare the recorded type with the documented Ubuntu-specific and upstream categories, and have a second administrator explain the support classification without relying on a default alias.
\nIf a migration rehearsal is separately authorized, define the recovery point and representative workload checks beforehand. Retain actual host identities, guest definition, support decision and observed outcome. A successful rehearsal should be reported as that bounded observation, not a new support guarantee. Keep an unexplained classification or missing recovery path open instead of changing the guest definition to make the review easier.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Record the machine type actually assigned to the guest before assessing a destination. Distinguish Ubuntu-specific support from the mere availability of an upstream type, especially in a cross-vendor plan.\nSource fact: documented behavior\nThe QEMU Machine types documentation is the primary reference.\nUbuntu’s guide describes a QEMU machine type as the guest’s virtual-hardware definition. The guide connects Ubuntu’s distro-specific machine types with its LTS-to-LTS live-migration support. Ubuntu retains upstream machine types but provides them as-is without further guarantees. The guide says cross-vendor or downstream migration using those upstream types may work but is considered unsupported.\nWhat the source does not establish\nThis article classifies a documented support boundary. It does not assert that every libvirt guest stores an unversioned alias, that a host upgrade automatically changes its virtual hardware or that matching machine-type names guarantee migration. Keep CPU compatibility, guest hardware changes and workload recovery under separate procedures.\nApplicability questions\n\nWhat exact machine type is recorded in the actual guest definition?\nIs it an Ubuntu-specific type or an upstream type?\nWhich source and destination distributions are intended?\nWhat explicit support arrangement and independent recovery route cover the proposed move?\n\nDSE recommendation: separate availability from support\nDSE recommends a migration review that begins with the actual guest definition, not the host’s default alias or a remembered creation choice. Record the exact type, relevant host software and the intended destination. Have the virtualization owner classify that type against the appropriate Ubuntu documentation before approving the plan.\nIf the recorded definition uses an alias, investigate its actual resolution and the deployment’s supported handling before drawing a compatibility conclusion. Do not assume that every guest has this condition or that an ordinary host upgrade performs a guest machine-type change. Preserve the definition as evidence of what is actually being reviewed.\nFor a cross-vendor proposal, obtain an explicit support decision rather than treating a listed upstream type as assurance. Keep the vendor or distribution boundary visible in the change request. Ask the workload owner to accept an independent recoverable path before an unsupported migration is considered.\nSeparate any proposal to change the guest’s machine type from the migration itself. Require its own guest-hardware assessment and approved maintenance procedure. Do not alter several compatibility dimensions at once to obtain a successful start that cannot be explained or reproduced.\nVerification and evidence\nProposed verification: assemble a read-only review record from a designated nonproduction guest and intended destination. Compare the recorded type with the documented Ubuntu-specific and upstream categories, and have a second administrator explain the support classification without relying on a default alias.\nIf a migration rehearsal is separately authorized, define the recovery point and representative workload checks beforehand. Retain actual host identities, guest definition, support decision and observed outcome. A successful rehearsal should be reported as that bounded observation, not a new support guarantee. Keep an unexplained classification or missing recovery path open instead of changing the guest definition to make the review easier.\nOfficial references\n\nQEMU Machine types — Ubuntu Server.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Record the machine type actually assigned to the guest before assessing a destination. Distinguish Ubuntu-specific support from the mere availability of an upstream type, especially in a cross-vendor plan.\n\n## Source fact: documented behavior\n\nThe [QEMU Machine types](https://ubuntu.com/server/docs/explanation/virtualisation/qemu-machine-types/) documentation is the primary reference.\n\nUbuntu’s guide describes a QEMU machine type as the guest’s virtual-hardware definition. The guide connects Ubuntu’s distro-specific machine types with its LTS-to-LTS live-migration support. Ubuntu retains upstream machine types but provides them as-is without further guarantees. The guide says cross-vendor or downstream migration using those upstream types may work but is considered unsupported.\n\n## What the source does not establish\n\nThis article classifies a documented support boundary. It does not assert that every libvirt guest stores an unversioned alias, that a host upgrade automatically changes its virtual hardware or that matching machine-type names guarantee migration. Keep CPU compatibility, guest hardware changes and workload recovery under separate procedures.\n\n## Applicability questions\n\n- What exact machine type is recorded in the actual guest definition?\n\n- Is it an Ubuntu-specific type or an upstream type?\n\n- Which source and destination distributions are intended?\n\n- What explicit support arrangement and independent recovery route cover the proposed move?\n\n## DSE recommendation: separate availability from support\n\nDSE recommends a migration review that begins with the actual guest definition, not the host’s default alias or a remembered creation choice. Record the exact type, relevant host software and the intended destination. Have the virtualization owner classify that type against the appropriate Ubuntu documentation before approving the plan.\n\nIf the recorded definition uses an alias, investigate its actual resolution and the deployment’s supported handling before drawing a compatibility conclusion. Do not assume that every guest has this condition or that an ordinary host upgrade performs a guest machine-type change. Preserve the definition as evidence of what is actually being reviewed.\n\nFor a cross-vendor proposal, obtain an explicit support decision rather than treating a listed upstream type as assurance. Keep the vendor or distribution boundary visible in the change request. Ask the workload owner to accept an independent recoverable path before an unsupported migration is considered.\n\nSeparate any proposal to change the guest’s machine type from the migration itself. Require its own guest-hardware assessment and approved maintenance procedure. Do not alter several compatibility dimensions at once to obtain a successful start that cannot be explained or reproduced.\n\n## Verification and evidence\n\nProposed verification: assemble a read-only review record from a designated nonproduction guest and intended destination. Compare the recorded type with the documented Ubuntu-specific and upstream categories, and have a second administrator explain the support classification without relying on a default alias.\n\nIf a migration rehearsal is separately authorized, define the recovery point and representative workload checks beforehand. Retain actual host identities, guest definition, support decision and observed outcome. A successful rehearsal should be reported as that bounded observation, not a new support guarantee. Keep an unexplained classification or missing recovery path open instead of changing the guest definition to make the review easier.\n\n## Official references\n\n- [QEMU Machine types](https://ubuntu.com/server/docs/explanation/virtualisation/qemu-machine-types/) — Ubuntu Server.\n\nSource review completed October 30, 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-ubuntu-support-scope-for-the-actual-qemu-machine-type/", "url": "https://update.dsesecurity.com/updates/check-ubuntu-support-scope-for-the-actual-qemu-machine-type/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-ubuntu-support-scope-for-the-actual-qemu-machine-type/#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 Ubuntu support scope for the actual QEMU machine type", "item": "https://update.dsesecurity.com/updates/check-ubuntu-support-scope-for-the-actual-qemu-machine-type/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-ubuntu-support-scope-for-the-actual-qemu-machine-type/#article", "identifier": "https://update.dsesecurity.com/updates/check-ubuntu-support-scope-for-the-actual-qemu-machine-type/", "url": "https://update.dsesecurity.com/updates/check-ubuntu-support-scope-for-the-actual-qemu-machine-type/", "headline": "Check Ubuntu support scope for the actual QEMU machine type", "description": "An available upstream QEMU machine type is not the same as an Ubuntu-specific supported type; review the actual guest definition and migration boundary.", "abstract": "An available upstream QEMU machine type is not the same as an Ubuntu-specific supported type; review the actual guest definition and migration boundary.", "articleBody": "Bottom line: Record the machine type actually assigned to the guest before assessing a destination. Distinguish Ubuntu-specific support from the mere availability of an upstream type, especially in a cross-vendor plan.\nSource fact: documented behavior\nThe QEMU Machine types documentation is the primary reference.\nUbuntu’s guide describes a QEMU machine type as the guest’s virtual-hardware definition. The guide connects Ubuntu’s distro-specific machine types with its LTS-to-LTS live-migration support. Ubuntu retains upstream machine types but provides them as-is without further guarantees. The guide says cross-vendor or downstream migration using those upstream types may work but is considered unsupported.\nWhat the source does not establish\nThis article classifies a documented support boundary. It does not assert that every libvirt guest stores an unversioned alias, that a host upgrade automatically changes its virtual hardware or that matching machine-type names guarantee migration. Keep CPU compatibility, guest hardware changes and workload recovery under separate procedures.\nApplicability questions\n\nWhat exact machine type is recorded in the actual guest definition?\nIs it an Ubuntu-specific type or an upstream type?\nWhich source and destination distributions are intended?\nWhat explicit support arrangement and independent recovery route cover the proposed move?\n\nDSE recommendation: separate availability from support\nDSE recommends a migration review that begins with the actual guest definition, not the host’s default alias or a remembered creation choice. Record the exact type, relevant host software and the intended destination. Have the virtualization owner classify that type against the appropriate Ubuntu documentation before approving the plan.\nIf the recorded definition uses an alias, investigate its actual resolution and the deployment’s supported handling before drawing a compatibility conclusion. Do not assume that every guest has this condition or that an ordinary host upgrade performs a guest machine-type change. Preserve the definition as evidence of what is actually being reviewed.\nFor a cross-vendor proposal, obtain an explicit support decision rather than treating a listed upstream type as assurance. Keep the vendor or distribution boundary visible in the change request. Ask the workload owner to accept an independent recoverable path before an unsupported migration is considered.\nSeparate any proposal to change the guest’s machine type from the migration itself. Require its own guest-hardware assessment and approved maintenance procedure. Do not alter several compatibility dimensions at once to obtain a successful start that cannot be explained or reproduced.\nVerification and evidence\nProposed verification: assemble a read-only review record from a designated nonproduction guest and intended destination. Compare the recorded type with the documented Ubuntu-specific and upstream categories, and have a second administrator explain the support classification without relying on a default alias.\nIf a migration rehearsal is separately authorized, define the recovery point and representative workload checks beforehand. Retain actual host identities, guest definition, support decision and observed outcome. A successful rehearsal should be reported as that bounded observation, not a new support guarantee. Keep an unexplained classification or missing recovery path open instead of changing the guest definition to make the review easier.\nOfficial references\n\nQEMU Machine types — Ubuntu Server.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:46:34+00:00", "dateModified": "2026-10-30T06:47:30+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-ubuntu-support-scope-for-the-actual-qemu-machine-type/" }, "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-ubuntu-support-scope-for-the-actual-qemu-machine-type/#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 Ubuntu support scope for the actual QEMU machine type" }, "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": 518, "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": "Ubuntu Server — QEMU Machine types", "url": "https://ubuntu.com/server/docs/explanation/virtualisation/qemu-machine-types/" } } ] } }