Azure Local Virtual Machine Storage Lifecycle Operations with Everpure FlashArray

Microsoft Platform Guide
Audience
Public
Source Type
Documentation

Introduction and Prerequisites

This KB article outlines typical administrative tasks for managing Virtual Machines on Azure Local backed by Everpure FlashArray. To ensure a consistent workflow across administrative tasks, the examples in this article primarily utilize either the Azure Portal or PowerShell for execution, supplemented by screenshots.

Prerequisites:

  • Azure Local cluster (version 2604 or later) registered with Azure.

  • Everpure FlashArray connected to the Azure Local Cluster via Fibre Channel.

  • Administrative access to the Azure Subscription and local Cluster nodes.

  • Azure CLI, Az.StackHCI, Az, PureStoragePowerShellSDK2 PowerShell modules installed and imported.

  • The Everpure FlashArray must be fully connected and configured with the Azure Local cluster prior to performing the operations in this guide. For setup instructions, refer to the FlashArray + Azure Local Quickstart Guide.

Creating a Virtual Machine

This section demonstrates the workflow for deploying a Virtual Machine through the Azure Portal interface. The steps below show how to manually specify the storage location for the virtual disks to ensure they are placed on the Everpure FlashArray.

Beyond the specific storage path selections described in this section, there are no additional special requirements or settings needed to deploy a virtual machine. The process follows the standard VM deployment workflow used for any Azure Local instance.

To begin, Login to the Azure Portal and select the Azure Local instance.

Navigate to Resources > Virtual Machines and click Create > New.

The Basics Tab (Storage Placement):

  • Under the Instance details section, locate the Storage Path field.

  • Select Choose Manually (1) and pick the previously configured Everpure FlashArray storage path (2) from the list.

Note for Azure Local Disaggregated Deployments: If you are using Azure Local Disaggregated (rather than Azure Local Hyperconverged), you may only have a single storage path. In this scenario, you can simply use the default Auto selection.

By default, Azure Local round-robins workloads across available storage paths. If you have multiple paths and want to guarantee workload placement on a specific path, select Choose Manually.

  • Select an available Azure Image (3) that has been downloaded to the Azure Local instance.

The Disks Tab:

  • To Create a New Disk: Provide a Name and Size. Under Storage path allocation method, select Choose Manually (1) and select the Everpure FlashArray storage path (2).

Note: Just like the Basics tab, you can select Auto if you are using Azure Local Disaggregated with a single storage path. Use Choose Manually if you have multiple paths and need to override the default round-robin behavior to ensure specific placement.

Attaching Existing Disks: Select Attach existing disk. You must identify the specific .vhdx or .vhd file residing on an Cluster Shared Volume (CSV) that is not currently associated with another VM and verify its name.

Attaching Existing Disks: Select Attach existing disk. You must identify the specific .vhdx or .vhd file residing on an Cluster Shared Volume (CSV) that is not currently associated with another VM and verify its name.

Virtual Disk Management via the Azure Portal

This section outlines the basic process for detaching a data disk from one Azure Local Virtual Machine and attaching it to another using the Azure Portal. These operations are performed at the Azure control plane and do not require direct interaction with the underlying Everpure FlashArray or Azure Local host infrastructure.

Key Considerations

  • Data disks only: The OS disk cannot be detached and reattached to another VM.

  • VM compatibility: Ensure the target VM supports the disk size, drive format and controller type.

  • Same Azure Local instance: The disk must reside in the same Azure Local environment (local datacenter / cluster) as the target VM. Disks cannot be attached across different Azure Local instances via the method outlined in this section.

Note: Cross Azure Local disk movement can be achieved using Everpure FlashArray replication; however, that workflow is outside the scope of this section.

  • Disk ownership: Ensure the disk is fully detached from the source VM before attempting to attach it to another VM. A disk cannot be attached to multiple VMs simultaneously.

  • Data integrity: Detaching while the disk is in use can lead to corruption so plan accordingly.

The Detach Process (Source VM)

  1. Prepare the Guest OS (Recommended)

    • Gracefully stop applications using the disk.

    • Unmount the filesystem (Linux) or take the disk offline (Windows Disk Management).

      1. This step reduces the risk of data corruption.

  2. Power Down the VM (Recommended)

    • While Azure allows hot detach in many cases, a clean shutdown ensures write operations are fully flushed.

    • In the Azure Portal, navigate to the VM and click Stop.

  3. Navigate to the Disk Configuration

    • In the Azure Portal, go to the source VM.

    • Select Disks from the left-hand menu.

  4. Detach the Data Disk

    • Locate the target data disk in the list.

    • Click the Detach option next to the disk.

      • Click Save to apply the configuration change.

  5. Confirm Disk Availability

    • After detachment, the disk remains as a standalone managed disk resource.

    • You can verify this under Disks in the Azure Portal by confirming it is not assigned to a virtual machine.

The Attach Process (Target VM)

  1. Navigate to the Target VM

    • In the Azure Portal, open the target VM that will receive the disk.

    • Select Disks from the left-hand menu.

  2. Attach the Existing Disk

    • Click Attach existing disk.

      • In the disk selection pane:

        • Select the previously detached disk.

  3. Apply Changes

    • Click Save to attach the disk to the VM.

    • The disk will now be presented to the guest OS.

Verification Within the Guest OS

After attachment, validate that the disk is recognized and accessible:

  • Windows VM:

    • Open Disk Management.

    • If the disk appears offline, bring it Online.

    • Assign a drive letter if needed.

    • Confirm data accessibility.

  • Linux VM:

    • Run lsblk or fdisk -l to identify the new device.

    • Mount the disk to the appropriate mount point if not auto-mounted.

    • Verify data integrity and access.

Best Practices

  • Always document the original disk configuration (name, size, storage path).

  • Prefer cold detach/attach for production workloads.

  • Validate application functionality after reattachment.

  • Use consistent naming conventions for disks to simplify identification across VMs.

Clone a VHD/VHDX and Register it as an Azure Resource

This section outlines the process for cloning an existing virtual disk (.vhd or .vhdx) within an Azure Local environment backed by Everpure FlashArray storage, and registering the cloned disk as a usable resource in the Azure Portal. This workflow enables rapid duplication of disks for use cases such as testing/development or data reuse.

Prerequisites

PowerShell module

The Az.StackHCIVM module must be installed and imported on the system where commands are executed.
Install-Module Az.StackHCIVM -Repository PSGallery -Force
Import-Module Az.StackHCIVM

Remote PowerShell access to Azure Local node:

All commands in this section must be executed from an Azure Local node. From your local system, establish a remote PowerShell session: 
Enter-PSSession -ComputerName "<Azure_Local_Node_Name>" -Credential (Get-Credential)

Key Considerations

  • Supported formats: Both .vhd and .vhdx virtual disk formats are supported for cloning and registration.

  • Destination flexibility: The cloned virtual disk can be copied to any valid cluster storage location accessible by the Azure Local node, including another Everpure-backed CSV or local Azure Local hyperconverged storage.

  • ODX offload: ODX offload applies only when the source and destination paths are on compatible storage that supports offloaded copy. For Everpure FlashArray, this requires that both the source and destination reside on the same array. Additionally, ODX is not supported if the volume is located inside a FlashArray Pod. Copies to a different array or to non-FlashArray storage will use a standard host-based copy.

  • Disk state: Ensure the source disk is in a consistent state before cloning. For production workloads, power off the VM or quiesce the application.

  • Size consistency: When registering the cloned disk, the -SizeGb value must match the size of the source disk.

The Cloning Process

Identify the Source Disk Path
  1. On an Azure Local node, run:
    Get-VMHardDiskDrive -VMName "<Source_VM_Name>"
    Note: The full path to the .vhdx file located on the Cluster Shared Volume (e.g., C:\ClusterStorage\Volume1\VMs\disk1.vhdx ).
  2. Execute the copy operation:
    Copy-Item `
  -Path "<Full_Path_To_Source_VHD_or_VHDX>" `
  -Destination "<Full_Path_To_Cloned_VHD_or_VHDX>"

    • If both paths are on Everpure FlashArray-backed CSVs, the operation will be offloaded via ODX.

    • If not, the copy will complete using host resources.

Register the Cloned Disk as an Azure Resource and Associate it with a VM

This step registers the cloned .vhd/.vhdx file with Azure, making it visible and manageable in the Azure Portal as a Virtual Hard Disk resource. This operation requires an authenticated Azure session and does not move or modify the copied file - it creates a reference to the cloned disk that is visible within the Azure Portal.
  1. Add the cloned hard drive to the Azure Local instance and Storagepath.
    New-AzStackHCIVMVirtualHardDisk `
  -ResourceGroupName "<Resource_Group_Name>" `
  -Name "<Cloned_Disk_Name>" `
  -Location "<Azure_Local_Resource_Group_Region>" `
  -CustomerLocationID "<Azure_Local_Custom_Location_Resource_ID>" `
  -StoragePathID "<Azure_Local_Storage_Path_Resource_ID>" `
  -DiskSizeGB <Source_Disk_Size_GB> `
  -Dynamic
    • CustomerLocationID identifies the Azure Local instance (cluster). Use Azure CLI commands to retrieve it.
      /subscriptions/<Subscription_ID>/resourceGroups/<Resource_Group_Name>/providers/Microsoft.ExtendedLocation/customLocations/<Custom_Location_Name>
      Retrieve using:
      az customlocation list --resource-group "<Resource_Group_Name>" --query "[0].id" -o tsv
      • StoragePathID maps to the storage path location (e.g., FlashArray-backed CSV) as defined in Azure
        Example format:
        /subscriptions/<Subscription_ID>/resourceGroups/<Resource_Group_Name>/providers/Microsoft.AzureStackHCI/storagecontainers/<Storage_Path_Name>
        Retrieve using:
        az stack-hci-vm storagepath show --name "<Storage_Path_Name>" --resource-group "<Resource_Group_Name>" --query id -o tsv
        DiskSizeGB must exactly match the source disk size
  2. This step links the registered disk resource to a virtual machine in Azure. It updates the VM's configuration in the Azure portal but does not yet attach the disk at the hypervisor level.
    Add-AzStackHCIVMVirtualMachineDataDisk `
  -ResourceGroupName "<Resource_Group_Name>" `
  -Name "<Target_VM_Name>" `
  -DataDiskName "<Cloned_Disk_Name>"

Attach the Disk at the Azure Local Cluster Level

This step completes the process by attaching the virtual disk to the VM at the Hyper-V / Azure Local cluster level. This makes the disk visible to the guest operating system.
Add-VMHardDiskDrive `
  -VMName "<Target_VM_Name>" `
  -Path "<Full_Path_To_Cloned_VHD_or_VHDX>"
Best Practices

  • Use consistent naming conventions for cloned disks.

  • Validate disk registration in the Azure Portal before attempting VM attachment.

  • Ensure cloned disk size values match the original disk size during registration.

Virtual Disk Recovery via FlashArray Snapshots

This section describes an advanced recovery workflow for restoring or extracting data from a point-in-time snapshot of a volume hosted on Everpure FlashArray. This method allows a previous version of a volume to be mounted alongside the production environment, enabling recovery of .vhd or .vhdx files without impacting the active workload.

This workflow spans:

  • FlashArray (snapshot, host and volume operations)

  • Recovery system (iSCSI-connected VM or FC-attached host for disk preparation and resignaturing)

  • Azure Local cluster (final attachment and data access)

This workflow operates outside of the Azure Portal and is performed directly at the FlashArray storage, VM and Azure Local cluster layers.For the purposes of this section, only the in-guest iSCSI recovery VM workflow is demonstrated. While Fibre Channel (FC) can be used to present the cloned volume to a separate host or Azure Local cluster for resignaturing, that process is similar to existing Fibre Channel-based volume presentation and cluster integration procedures covered within the QuickStart guide.

Key Considerations

  • Recovery system requirement: The FlashArray cloned from snapshot volume must first be presented to a system that does not have the original production volume mounted. This can be a recovery VM using in-guest iSCSI or a separate host / Azure Local cluster using Fibre Channel.

  • Connectivity method:

    • iSCSI: Use an in-guest connection from a recovery VM to access and prepare the disk.

    • Fibre Channel: Present the cloned volume to a separate FC-connected host or cluster that does not have access to the original volume. Do not present the cloned volume directly to the production Azure Local cluster prior to resignaturing.

  • Snapshot copy to Volume: The restored volume is a copy of a volume snapshot and is independent of the production volume.

  • Signature collision: Copies of a volume snapshot will by default have the same disk signature as the source and must be resignatured before being attached to the Azure Local cluster.

Prepare Recovery VM (iSCSI Connectivity)

  1. Enable and Start iSCSI Service

    This starts the Windows iSCSI Initiator service so the recovery VM can discover and connect to FlashArray iSCSI targets and ensures the iSCSI service remains enabled after a reboot.
    Start-Service msiscsi
Set-Service msiscsi -StartupType Automatic
  2. Retrieve iSCSI Initiator IQN
    This returns the IQN that must be registered on the FlashArray as a host initiator.
    (Get-InitiatorPort | Where-Object { $_.ConnectionType -eq 'iSCSI' }).NodeAddress
FlashArray Snapshot Copy to Volume and Host Creation

  1. Connect to FlashArray

    This establishes a PowerShell session to the FlashArray so volume, snapshot, host, and connection operations can be performed. Make certain that the PureStoragePowerShellSDK2 module is installed and imported.
    $Conn = Connect-PFA2Array -Endpoint "<FlashArray_Management_IP>" -Credential (Get-Credential) -IgnoreCertificateError

  2. Create Host Object for Recovery VM

    This creates a FlashArray host entry using the recovery VM’s iSCSI IQN. Use the IQN that was retrieved from step 2 in the previous part above.
    New-Pfa2Host -Name "<Recovery_VM_Name>" -Iqn "<Recovery_VM_IQN>"

  3. Identify Source Volume and Snapshot

    This verifies the production volume that contains the original CSV and displays the available point-in-time snapshots that can be used for recovery.
    Get-Pfa2Volume -Name "<Source_Volume_Name>"
Get-Pfa2VolumeSnapshot -Filter "name='<Source_Volume_Name>.*'"

  4. Clone Volume to New Snapshot

    This creates a new FlashArray volume from the selected snapshot. 
    New-Pfa2Volume -Name "<Recovery_Volume_Name>" -SourceNames "<Snapshot_Name>"

  5. Map Volume to Recovery VM

    This presents the cloned recovery volume to the recovery VM over iSCSI.
    New-Pfa2Connection -HostNames "<Recovery_VM_Name>" -VolumeNames "<Recovery_Volume_Name>"

Connect Recovery VM to FlashArray Volume Clone and Resignature

This phase connects the recovery VM to the FlashArray target, discovers the cloned disk, and assigns it a new disk signature. This is required because the cloned volume has the same disk identity as the original production CSV volume.

  1. Add iSCSI Target Portal

    This tells the Windows iSCSI Initiator where to discover FlashArray iSCSI targets. 
    New-IscsiTargetPortal -TargetPortalAddress "<FlashArray_iSCSI_IP>"

  2. Discover and Connect to Target

    This establishes the iSCSI session and makes the cloned volume visible to Windows and then confirms that the FlashArray target is available on the recovery VM.
    Connect-IscsiTarget -NodeAddress "<FlashArray_Target_IQN>" -IsPersistent $true


Get-IscsiTarget

  3. List Disks on the Recovery VM:

    This identifies the newly presented cloned disk and its disk number. 
    Get-Disk

  4. Bring Disk Online

    This brings the cloned disk online and allows Windows to be able to modify its metadata.
    Set-Disk -Number <Disk_Number> -IsOffline $false
Set-Disk -Number <Disk_Number> -IsReadOnly $false

  5. Resignature the Disk

    This changes the disk identity so the cloned volume no longer conflicts with the original CSV volume.
    Set-Disk -Number <Disk_Number> -UniqueId (New-Guid).Guid
  6. Take the Disk Offline

    This prepares the disk to be disconnected from the recovery VM and safely presented to the Azure Local cluster.
    Set-Disk -Number <Disk_Number> -IsOffline $true
Present Disk to Azure Local Cluster
This phase removes the recovery volume from the recovery VM and presents it to the Azure Local cluster host group. At this point, the disk has a unique signature and can be safely introduced to the cluster.

  1. Disconnect from Recovery VM

    This disconnects the cloned volume from the recovery VM.
    Remove-Pfa2Connection -HostNames "<Recovery_VM_Name>" -VolumeNames "<Recovery_Volume_Name>"

  2. Map Volume to Azure Local Cluster

    This presents the resignatured volume to the Azure Local cluster nodes. 
    New-Pfa2Connection -HostGroupNames "<AzureLocal_HostGroup_Name>" -VolumeNames "<Recovery_Volume_Name>"

Attach Disk to Cluster and Convert to CSV

This phase discovers the newly presented volume on an Azure Local node, adds it to the cluster, converts it to a CSV, and makes the recovered virtual disk files accessible.

  1. Connect to Azure Local Node

    This opens a remote PowerShell session to a cluster node where storage and cluster commands can be executed.
    Enter-PSSession -ComputerName "<AzureLocal_Node_Name>" -Credential (Get-Credential)
  2. Rescan Storage
    This refreshes storage discovery so the newly mapped FlashArray volume appears to the node and identifies the newly presented resignatured recovery disk.
    Update-HostStorageCache
Get-Disk

  3. Add Disk to Cluster

    This adds the disk as available storage in the Windows Failover Cluster. 
    Get-Disk -Number <Disk_Number> | Add-ClusterDisk

  4. Convert to CSV

    This converts the disk into a Cluster Shared Volume so its contents are accessible under C:\ClusterStorage\.
    Add-ClusterSharedVolume -Name "<Cluster_Disk_Name>"
Get-ClusterSharedVolume -Name "<Cluster_Disk_Name>"
    The disk will be accessible under:
    C:\ClusterStorage\<Volume_Name>\
    The recovered .vhd or .vhdx files can now be accessed from the CSV path.

Recover Virtual Disk and Data

This phase restores the selected .vhd or .vhdx file by copying it from the recovered CSV volume back to the production CSV location. This overwrites the existing production virtual disk file with the point-in-time copy from the snapshot.

Before running this step, ensure the VM using the production virtual disk is powered off and that the original .vhd or .vhdx file is not in use. Repeat the below command for as many virtual drives need to be recovered.

Restore the Virtual Disk File 
Copy-Item `
"C:\ClusterStorage\<Recovered_CSV_Volume>\<Path_To_Recovered_VHD_or_VHDX>" `
"C:\ClusterStorage\<Production_CSV_Volume>\<Path_To_Production_VHD_or_VHDX>" `
-Force

CSV Cleanup

  1. Remove the disk from Cluster Shared Volume

    This removes the disk from CSV mode and returns it to standard cluster storage.
    Remove-ClusterSharedVolume -Name "<Cluster_Disk_Name>"

  2. Remove the Disk from the Cluster

    This detaches the disk from cluster management entirely.
    Get-Disk -Number <Disk_Number> | Remove-ClusterDisk

  3. Take the Disk Offline

    At this point, the disk is no longer managed by the cluster and can safely be taken offline.
    Set-Disk -Number <Disk_Number> -IsOffline $true

  4. Remove FlashArray Mapping

    This unmaps the volume from the Azure Local cluster for the FlashArray.
    Remove-Pfa2Connection -HostGroupNames "<AzureLocal_HostGroup_Name>" -VolumeNames "<Recovery_Volume_Name>"

  5. Remove Recovery Volume (optional)

    Delete via FlashArray UI or PowerShell if no longer needed.