{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/", "slug": "dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares", "url": "https://update.dsesecurity.com/updates/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/" }, "title": "Plan an all-node detachment before increasing a shared disk's maxShares", "summary": "Can an Azure shared disk's attachment ceiling be increased while existing cluster nodes still use it?", "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:30:58+00:00", "modified_at": "2026-09-10T00:35:07+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 258, "potentially_affected": "Clusters using supported Azure shared managed disks and planning a change to their maximum simultaneous attachments.", "dse_recommendation": "Compare the intended node count with maxShares before committing to a cluster expansion window.", "primary_source": { "name": "Share an Azure managed disk across VMs - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/disks-shared", "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": "

Source facts

\n

An Azure shared disk’s maxShares value sets the upper bound on simultaneous sharing nodes. The value can be changed only when the disk is detached from every node, and the supported maximum depends on disk type and, for some types, disk size. Shared disks require a cluster manager to coordinate communication and write locking; they are shared block devices, not a native managed SMB or NFS filesystem. Microsoft Learn.

\n

Applicability

\n

Use this review when adding nodes to an existing cluster could exceed its configured attachment ceiling. Inventory the actual attachments, disk type, and supported maximum instead of assuming that current cluster membership defines the setting.

\n

DSE recommendation

\n

Compare the intended node count with maxShares before committing to a cluster expansion window. Have the cluster and storage owners determine whether the planned nodes fit the existing limit. If the limit must change, prepare an authorized all-node detachment and service-recovery sequence using the application’s supported procedure. Keep the proposed setting within the source’s disk-specific limits and preserve a clear mapping between the shared resource and every consumer.

\n

Verification

\n

After the approved change and reattachment, inspect maxShares and the actual node attachments. Test the intended clustered workload and its ownership behavior before declaring the expansion complete. Record any node that cannot attach or participate as unresolved. Do not use concurrent ordinary filesystem access as a substitute for the required cluster coordination, and do not assume raising an attachment ceiling alone establishes a supported application topology.

\n

Official references

\n

Microsoft Learn: Share an Azure managed disk across VMs. Source reviewed September 9, 2026.

", "content_text": "Source facts\nAn Azure shared disk’s maxShares value sets the upper bound on simultaneous sharing nodes. The value can be changed only when the disk is detached from every node, and the supported maximum depends on disk type and, for some types, disk size. Shared disks require a cluster manager to coordinate communication and write locking; they are shared block devices, not a native managed SMB or NFS filesystem. Microsoft Learn.\nApplicability\nUse this review when adding nodes to an existing cluster could exceed its configured attachment ceiling. Inventory the actual attachments, disk type, and supported maximum instead of assuming that current cluster membership defines the setting.\nDSE recommendation\nCompare the intended node count with maxShares before committing to a cluster expansion window. Have the cluster and storage owners determine whether the planned nodes fit the existing limit. If the limit must change, prepare an authorized all-node detachment and service-recovery sequence using the application’s supported procedure. Keep the proposed setting within the source’s disk-specific limits and preserve a clear mapping between the shared resource and every consumer.\nVerification\nAfter the approved change and reattachment, inspect maxShares and the actual node attachments. Test the intended clustered workload and its ownership behavior before declaring the expansion complete. Record any node that cannot attach or participate as unresolved. Do not use concurrent ordinary filesystem access as a substitute for the required cluster coordination, and do not assume raising an attachment ceiling alone establishes a supported application topology.\nOfficial references\nMicrosoft Learn: Share an Azure managed disk across VMs. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nAn Azure shared disk’s maxShares value sets the upper bound on simultaneous sharing nodes. The value can be changed only when the disk is detached from every node, and the supported maximum depends on disk type and, for some types, disk size. Shared disks require a cluster manager to coordinate communication and write locking; they are shared block devices, not a native managed SMB or NFS filesystem. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-shared).\n\n## Applicability\n\nUse this review when adding nodes to an existing cluster could exceed its configured attachment ceiling. Inventory the actual attachments, disk type, and supported maximum instead of assuming that current cluster membership defines the setting.\n\n## DSE recommendation\n\nCompare the intended node count with maxShares before committing to a cluster expansion window. Have the cluster and storage owners determine whether the planned nodes fit the existing limit. If the limit must change, prepare an authorized all-node detachment and service-recovery sequence using the application’s supported procedure. Keep the proposed setting within the source’s disk-specific limits and preserve a clear mapping between the shared resource and every consumer.\n\n## Verification\n\nAfter the approved change and reattachment, inspect maxShares and the actual node attachments. Test the intended clustered workload and its ownership behavior before declaring the expansion complete. Record any node that cannot attach or participate as unresolved. Do not use concurrent ordinary filesystem access as a substitute for the required cluster coordination, and do not assume raising an attachment ceiling alone establishes a supported application topology.\n\n## Official references\n\n[Microsoft Learn: Share an Azure managed disk across VMs](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-shared). 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-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/", "url": "https://update.dsesecurity.com/updates/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Plan an all-node detachment before increasing a shared disk's maxShares", "item": "https://update.dsesecurity.com/updates/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/", "url": "https://update.dsesecurity.com/updates/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/", "headline": "Plan an all-node detachment before increasing a shared disk's maxShares", "description": "Can an Azure shared disk's attachment ceiling be increased while existing cluster nodes still use it?", "abstract": "Can an Azure shared disk's attachment ceiling be increased while existing cluster nodes still use it?", "articleBody": "Source facts\nAn Azure shared disk’s maxShares value sets the upper bound on simultaneous sharing nodes. The value can be changed only when the disk is detached from every node, and the supported maximum depends on disk type and, for some types, disk size. Shared disks require a cluster manager to coordinate communication and write locking; they are shared block devices, not a native managed SMB or NFS filesystem. Microsoft Learn.\nApplicability\nUse this review when adding nodes to an existing cluster could exceed its configured attachment ceiling. Inventory the actual attachments, disk type, and supported maximum instead of assuming that current cluster membership defines the setting.\nDSE recommendation\nCompare the intended node count with maxShares before committing to a cluster expansion window. Have the cluster and storage owners determine whether the planned nodes fit the existing limit. If the limit must change, prepare an authorized all-node detachment and service-recovery sequence using the application’s supported procedure. Keep the proposed setting within the source’s disk-specific limits and preserve a clear mapping between the shared resource and every consumer.\nVerification\nAfter the approved change and reattachment, inspect maxShares and the actual node attachments. Test the intended clustered workload and its ownership behavior before declaring the expansion complete. Record any node that cannot attach or participate as unresolved. Do not use concurrent ordinary filesystem access as a substitute for the required cluster coordination, and do not assume raising an attachment ceiling alone establishes a supported application topology.\nOfficial references\nMicrosoft Learn: Share an Azure managed disk across VMs. Source reviewed September 9, 2026.", "datePublished": "2026-09-10T00:30:58+00:00", "dateModified": "2026-09-10T00:35:07+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/" }, "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-058-plan-an-all-node-detachment-before-increasing-a-shared-disk-s-maxshares/#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": "Plan an all-node detachment before increasing a shared disk's maxShares" }, "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": 258, "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": "Share an Azure managed disk across VMs - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/disks-shared" } } ] } }