It was official on April 24th with Azure Local build 2604.

You now have 3 options with Azure Local:

• Add supported FC HBAs to an existing Azure Local cluster and create an external NTFS Cluster Shared Volume (CSV) for user workloads.
• Deploy a new HCI Azure Local cluster that has FC HBAs and is connected to external storage.
• Deploy a new disaggregated Azure Local cluster that only has external storage with a 30 and 300G CSV for infrastructure resources

In this post I am going to focus on disaggregated deployments, which Microsoft documents here. Disaggregated is really a blessing in a couple of ways. First, not having to buy 2-4 devices per node, when you intend for all user workloads to be placed on an Everpure FlashArray, is meaningful. A year ago maybe a couple of thousand dollars were at stake, but today (May 2026), including a PCIe card with 2 M.2 slots and two 1TB M.2 SSDs can set you back $5000 per server, plus many months of lead time. 100 of those servers is a half million dollar cost, you no longer have to spend. Microsoft is looking out for their customer’s current investment. If you have significant local storage, utilize both!

I have been working with Nutanix for a couple of years, and the integrations with Everpure went GA in December of 2025. The public excitement has been building, first at Nutanix.Next in May 2025 when it was first announced, and then last week at .Next in Chicago. We had a real opportunity to take a look at what works well on other hypervisor platforms and really design the integration from a blank piece of paper.

I have been working on Azure Local (formerly Azure Stack HCI) for almost five years, and we are now less than 1 month from GA for Fibre Channel external storage. For the initial support in April 2026, there is no OS code change, so you should deploy Azure Local with a Windows Server 2025 certified Fibre Channel card that your server OEM supports in that server model. Connecting to the Everpure FlashArray is done after the deployment from the Azure Portal.

TLDR: Newer versions of Windows will free blocks on a Cluster Shared Volume.

I work on a lot of Failover Clusters and about once a year it would come up that a customer had a situation with disk space. Usually it was older, out of support, versions of Windows and the scenario was that recently a bunch of VMs were moved from 1 Cluster Shared Volume (CSV) to another. The CSV volume on the FlashArray was not releasing the blocks. That left a customer with a handful of choices:

There are many different strategies for backing up a production Hyper-V environment. In this blog post I will focus on a hardware Volume Shadow-Copy Service (VSS) snapshot of a Cluster Shared Volume (CSV). VSS creates an application consistent snapshot where all of the VMs are in a good state so that if you restore the volume, or clone the snapshot and mount it outside of the Failover Cluster, the VMs will boot without issue. Keep in mind that this is a hypervisor driven snapshot, which is different from an application snapshot inside of a virtual machine. An Exchange Server or SQL Server database will not show that a ‘backup’ has been taken. Some third party backup applications (VSS Requestors), can handle this, but that is because the backup application is performing additional work inside of the VMs.

My name is Robert Quimbey though I’m often called Q since I’m commonly one of many Rob’s, Bob’s, and Robert’s on an extended team. I work for Pure Storage as a Field Solutions Architect (FSA). I get to spend most of my time helping customers migrate to Microsoft Solutions, and for existing customers, develop more value out of their existing Pure Storage infrastructure.

I have spent the past couple of decades working with Microsoft Software, and even spent almost 9 years in the Exchange team in Redmond at Microsoft! I focus on automation with PowerShell, databases, storage technologies, Windows (and Linux :), Failover Clustering, and even Azure.