{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/",
        "slug": "dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation",
        "url": "https://update.dsesecurity.com/updates/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/"
        },
        "title": "Distinguish Dedicated Host restart from hardware relocation",
        "summary": "Does restarting an Azure Dedicated Host move its VMs to different physical hardware?",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "continuity-recovery",
            "label": "Continuity & recovery",
            "alt": "Paired infrastructure paths converging on a stable recovered service.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "business-continuity",
                "name": "Business Continuity",
                "url": "https://update.dsesecurity.com/topic/business-continuity/"
            },
            {
                "slug": "it",
                "name": "IT",
                "url": "https://update.dsesecurity.com/topic/it/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-09-10T00:31:12+00:00",
        "modified_at": "2026-09-10T00:32:00+00:00",
        "reviewed_on": "2026-09-09",
        "reading_minutes": 2,
        "word_count": 246,
        "potentially_affected": "Azure Dedicated Host operators choosing a troubleshooting action that affects hosted VMs.",
        "dse_recommendation": "Choose the host operation by its intended hardware outcome and account for every hosted workload.",
        "primary_source": {
            "name": "Deploy Azure dedicated hosts - Azure Virtual Machines | Microsoft Learn",
            "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/dedicated-hosts-how-to",
            "published_on": null,
            "authority": "Microsoft Learn"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<h2>Source facts</h2>\n<p>Restarting an Azure Dedicated Host also restarts its underlying VMs, but keeps the same physical hardware, host ID, asset ID and SKU. The documented host-redeploy preview instead moves the host and its associated VMs to a different node of the same SKU, changing the asset ID. Redeployment loses nonpersistent data such as data on ephemeral disks. <a href=\"https://learn.microsoft.com/en-us/azure/virtual-machines/dedicated-hosts-how-to\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn</a>.</p>\n<h2>Applicability</h2>\n<p>Use this distinction after authorized troubleshooting has identified whether the intent is a restart or relocation away from the current node. Treat host-level action as affecting the complete hosted workload set, not just the VM where a symptom was first observed.</p>\n<h2>DSE recommendation</h2>\n<p>Choose the host operation by its intended hardware outcome and account for every hosted workload. Have the platform owner record the host identity, asset identity and hosted VM list before selecting an operation. Coordinate the expected interruption with all workload owners. For a proposed redeployment, review current preview availability and save required work to persistent storage through the application&#8217;s supported process before the action.</p>\n<h2>Verification</h2>\n<p>After an approved restart, compare identities and verify every affected workload; unchanged hardware identity is expected for that operation. For an approved preview redeployment, check the changed asset ID alongside the actual host and VM status. Validate application state independently, including any deliberately rebuilt temporary content. Do not declare a hardware move merely because a restart completed or a VM resumed responding.</p>\n<h2>Official references</h2>\n<p><a href=\"https://learn.microsoft.com/en-us/azure/virtual-machines/dedicated-hosts-how-to\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn: Deploy VMs and scale sets to dedicated hosts</a>. Source reviewed September 9, 2026.</p>",
        "content_text": "Source facts\nRestarting an Azure Dedicated Host also restarts its underlying VMs, but keeps the same physical hardware, host ID, asset ID and SKU. The documented host-redeploy preview instead moves the host and its associated VMs to a different node of the same SKU, changing the asset ID. Redeployment loses nonpersistent data such as data on ephemeral disks. Microsoft Learn.\nApplicability\nUse this distinction after authorized troubleshooting has identified whether the intent is a restart or relocation away from the current node. Treat host-level action as affecting the complete hosted workload set, not just the VM where a symptom was first observed.\nDSE recommendation\nChoose the host operation by its intended hardware outcome and account for every hosted workload. Have the platform owner record the host identity, asset identity and hosted VM list before selecting an operation. Coordinate the expected interruption with all workload owners. For a proposed redeployment, review current preview availability and save required work to persistent storage through the application’s supported process before the action.\nVerification\nAfter an approved restart, compare identities and verify every affected workload; unchanged hardware identity is expected for that operation. For an approved preview redeployment, check the changed asset ID alongside the actual host and VM status. Validate application state independently, including any deliberately rebuilt temporary content. Do not declare a hardware move merely because a restart completed or a VM resumed responding.\nOfficial references\nMicrosoft Learn: Deploy VMs and scale sets to dedicated hosts. Source reviewed September 9, 2026.",
        "content_markdown": "## Source facts\n\nRestarting an Azure Dedicated Host also restarts its underlying VMs, but keeps the same physical hardware, host ID, asset ID and SKU. The documented host-redeploy preview instead moves the host and its associated VMs to a different node of the same SKU, changing the asset ID. Redeployment loses nonpersistent data such as data on ephemeral disks. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/dedicated-hosts-how-to).\n\n## Applicability\n\nUse this distinction after authorized troubleshooting has identified whether the intent is a restart or relocation away from the current node. Treat host-level action as affecting the complete hosted workload set, not just the VM where a symptom was first observed.\n\n## DSE recommendation\n\nChoose the host operation by its intended hardware outcome and account for every hosted workload. Have the platform owner record the host identity, asset identity and hosted VM list before selecting an operation. Coordinate the expected interruption with all workload owners. For a proposed redeployment, review current preview availability and save required work to persistent storage through the application’s supported process before the action.\n\n## Verification\n\nAfter an approved restart, compare identities and verify every affected workload; unchanged hardware identity is expected for that operation. For an approved preview redeployment, check the changed asset ID alongside the actual host and VM status. Validate application state independently, including any deliberately rebuilt temporary content. Do not declare a hardware move merely because a restart completed or a VM resumed responding.\n\n## Official references\n\n[Microsoft Learn: Deploy VMs and scale sets to dedicated hosts](https://learn.microsoft.com/en-us/azure/virtual-machines/dedicated-hosts-how-to). Source reviewed September 9, 2026."
    },
    "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/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/",
                "url": "https://update.dsesecurity.com/updates/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-09-09"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Distinguish Dedicated Host restart from hardware relocation",
                        "item": "https://update.dsesecurity.com/updates/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/#article",
                "identifier": "https://update.dsesecurity.com/updates/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/",
                "url": "https://update.dsesecurity.com/updates/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/",
                "headline": "Distinguish Dedicated Host restart from hardware relocation",
                "description": "Does restarting an Azure Dedicated Host move its VMs to different physical hardware?",
                "abstract": "Does restarting an Azure Dedicated Host move its VMs to different physical hardware?",
                "articleBody": "Source facts\nRestarting an Azure Dedicated Host also restarts its underlying VMs, but keeps the same physical hardware, host ID, asset ID and SKU. The documented host-redeploy preview instead moves the host and its associated VMs to a different node of the same SKU, changing the asset ID. Redeployment loses nonpersistent data such as data on ephemeral disks. Microsoft Learn.\nApplicability\nUse this distinction after authorized troubleshooting has identified whether the intent is a restart or relocation away from the current node. Treat host-level action as affecting the complete hosted workload set, not just the VM where a symptom was first observed.\nDSE recommendation\nChoose the host operation by its intended hardware outcome and account for every hosted workload. Have the platform owner record the host identity, asset identity and hosted VM list before selecting an operation. Coordinate the expected interruption with all workload owners. For a proposed redeployment, review current preview availability and save required work to persistent storage through the application’s supported process before the action.\nVerification\nAfter an approved restart, compare identities and verify every affected workload; unchanged hardware identity is expected for that operation. For an approved preview redeployment, check the changed asset ID alongside the actual host and VM status. Validate application state independently, including any deliberately rebuilt temporary content. Do not declare a hardware move merely because a restart completed or a VM resumed responding.\nOfficial references\nMicrosoft Learn: Deploy VMs and scale sets to dedicated hosts. Source reviewed September 9, 2026.",
                "datePublished": "2026-09-10T00:31:12+00:00",
                "dateModified": "2026-09-10T00:32:00+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/"
                },
                "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/dse-20260909-044-distinguish-dedicated-host-restart-from-hardware-relocation/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Distinguish Dedicated Host restart from hardware relocation"
                },
                "articleSection": [
                    "Business Continuity",
                    "IT"
                ],
                "keywords": [
                    "Business Continuity",
                    "IT",
                    "Guide",
                    "Information priority"
                ],
                "genre": "Guide",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Business Continuity",
                        "url": "https://update.dsesecurity.com/topic/business-continuity/"
                    },
                    {
                        "@type": "Thing",
                        "name": "IT",
                        "url": "https://update.dsesecurity.com/topic/it/"
                    }
                ],
                "wordCount": 246,
                "timeRequired": "PT2M",
                "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": "Deploy Azure dedicated hosts - Azure Virtual Machines | Microsoft Learn",
                    "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/dedicated-hosts-how-to"
                }
            }
        ]
    }
}