Have an Azure SQL machine with Premium SSD v2 with NVME . I am unable to determine which drive is which.

Question

Have an Azure SQL machine with Premium SSD v2 with NVME . I am unable to determine which drive is which.

MCarr 0

I have an Azure Imaged SQL machine that has a number of drives. I need to just increase one of the Data Disks that does not have enough space for the new database. All the PowerShell I have tried are not able to determine which Azure External Lun is the one i need to increase. All of the PowerShell return SCSIBus & SCSITargetId of Zero. This is preventing us from adding another database to the server.

Single Drive PowerShell

$driveLetter = "F"   # change to your drive letter
$partition = Get-Partition | Where-Object { $_.DriveLetter -eq $driveLetter }
$disk = Get-Disk -Number $partition.DiskNumber

# SCSITargetId on the disk's location corresponds to the LUN Azure assigned
$diskDrive = Get-WmiObject Win32_DiskDrive | Where-Object { $_.Index -eq $disk.Number }

[PSCustomObject]@{
    DriveLetter   = $driveLetter
    DiskNumber    = $disk.Number
    FriendlyName  = $disk.FriendlyName
    SerialNumber  = $disk.SerialNumber
    SCSIBus       = $diskDrive.SCSIBus
    SCSITargetId  = $diskDrive.SCSITargetId   # <-- this is the Azure LUN
    SCSILogicalUnit = $diskDrive.SCSILogicalUnit
}

Just looking at all the drive

MCarr 0 Reputation points

2026-07-13T16:57:36.6333333+00:00

Forgot to mention. I checked and it has no Storage Pools or Virtual Disk so that type of disk expansion by adding another drive to it is not a solution.
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-13T21:27:04.0133333+00:00
Hi @MCarr ,

Thanks for the clear repro. What you are hitting is expected behavior, not a

PowerShell bug and not a Premium SSD v2 issue - it is because your VM is on

the NVMe disk controller, not SCSI.

Root cause

Premium SSD v2 only attaches to modern VM sizes (Ebsv5 and later - v6, v7),

and those VM sizes use the "remote NVMe" disk controller instead of SCSI.

On NVMe, all disks (OS + data) sit on a single virtual controller named

"MSFT NVMe Accelerator v1.0". Because there is no SCSI bus, Win32_DiskDrive

cannot expose SCSIBus / SCSITargetId / SCSILogicalUnit for these disks -

they will always return 0. That is by design; those fields only mean

something for SCSI-attached disks.

So your script is not broken. It is asking for SCSI addressing on an NVMe

device.

How the LUN actually maps on Azure NVMe

On the "MSFT NVMe Accelerator v1.0" controller the Azure data-disk LUN is

carried in the NVMe Namespace ID (NSID), with this fixed mapping:

NSID 1 -> OS disk

NSID 2 -> data disk at LUN 0

NSID 3 -> data disk at LUN 1

NSID (n + 2) -> data disk at LUN n

That is the same formula Microsoft's own azure-vm-utils / udev rule uses

to build /dev/disk/azure/data/by-lun on Linux (nsid - 2 = LUN). It applies

to Windows too, because the mapping is set by the controller, not by the OS.

Correct way to identify each drive on Windows (NVMe VM)

Use Get-PhysicalDisk / Get-Disk (which read Storage WMI), not Win32_DiskDrive.

On NVMe, Get-PhysicalDisk shows BusType = NVMe and gives you the NVMe

serial/UniqueId, and Get-Disk.SerialNumber contains the disk identifier

that Azure stamps into the namespace. Match that against the disk list from

the portal / ARM.

Run this in an elevated PowerShell on the VM. It walks every drive letter,

resolves the physical disk, and prints the NVMe namespace ID plus the

computed Azure LUN:

Get-Partition | Where-Object DriveLetter | ForEach-Object {

$p = $_

$disk = Get-Disk -Number $p.DiskNumber

$phys = Get-PhysicalDisk | Where-Object DeviceId -eq $disk.Number

NVMe namespace id: last integer in the disk's Location / UniqueId

$nsid = $null

if ($disk.Location -match 'NSID\s*[:=]?\s*(\d+)') { $nsid = [int]$Matches[1] }

elseif ($disk.Path -match 'NSID_(\d+)') { $nsid = [int]$Matches[1] }

[pscustomobject]@{

DriveLetter = $p.DriveLetter

DiskNumber = $disk.Number

SizeGB = [math]::Round($disk.Size/1GB,0)

BusType = $phys.BusType # should say NVMe

FriendlyName = $disk.FriendlyName # "MSFT NVMe Accelerator v1.0"

SerialNumber = $disk.SerialNumber # unique per Azure disk

NvmeNSID = $nsid

AzureLUN = if ($nsid) { $nsid - 2 } else { 'n/a' }

}

} | Format-Table -AutoSize

Two quick cross-checks so you know you picked the right one before resizing:

Match by size. From the Azure portal / CLI:

az vm show -g <rg> -n <vm> --query "storageProfile.dataDisks[].{lun:lun,name:name,sizeGb:diskSizeGb}" -o table

If your data disks are all different sizes, that alone is enough - the

SizeGB column above will map 1:1 to the "sizeGb" column from ARM.

Match by AzureLUN column from the script above to the "lun" column in

the ARM output. That is the number Azure uses when you resize / detach.

Why your original script returned zeros for everything

Win32_DiskDrive.SCSIBus / SCSITargetId / SCSILogicalUnit are populated

only for SCSI-attached disks. NVMe disks report 0 for all three because

the property is not applicable on this bus.

On NVMe VMs the equivalent identifier is the Namespace ID (NSID), which

you have to read from Get-Disk.Location / Get-Disk.Path or via nvme.exe,

not from the SCSI WMI properties.

Once you know the AzureLUN of the data disk that needs more space, just

resize that specific managed disk from the portal (VM > Disks > select the

disk with that LUN > Size + performance) or:

az disk update -g <rg> -n <disk-name> --size-gb <new-size>

Then extend the volume inside Windows:

"list disk" / "select disk N" / "rescan" in diskpart, then

Get-Partition -DiskNumber N | Resize-Partition -Size (Get-PartitionSupportedSize -DiskNumber N -PartitionNumber <p>).SizeMax

No downtime is required to grow a Premium SSD v2 attached to a running VM.

If you can share the "az vm show ... storageProfile.dataDisks" output and

the script output above side by side, I can point at the exact LUN to

resize.
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-18T00:11:55.86+00:00
Hi @MCarr ,

Quick recap so this is complete in one place and easy to follow when you get to the resize step.

Why the SCSI script returned zeros

Your VM (Ebsv5 / v6 / v7 with Premium SSD v2) uses the NVMe disk controller ("MSFT NVMe Accelerator v1.0"). Every disk (OS + data) sits on that single virtual controller, so Win32_DiskDrive.SCSIBus / SCSITargetId / SCSILogicalUnit are not applicable and always come back as 0. The script is fine; it's just asking for SCSI fields on an NVMe bus.

On Azure NVMe, the data-disk LUN is carried in the NVMe Namespace ID (NSID) with a fixed mapping:

NSID 1 -> OS disk

NSID 2 -> data disk at LUN 0

NSID 3 -> data disk at LUN 1

NSID (n+2) -> data disk at LUN n

Correct way to identify each drive on Windows (elevated PowerShell)

Get-Partition | Where-Object DriveLetter | ForEach-Object {

$p = $_ $disk = Get-Disk -Number $p.DiskNumber $phys = Get-PhysicalDisk | Where-Object DeviceId -eq $disk.Number $nsid = $null if ($disk.Location -match 'NSID\s*[:=]?\s*(\d+)') { $nsid = [int]$Matches[1] } elseif ($disk.Path -match 'NSID_(\d+)') { $nsid = [int]$Matches[1] } [pscustomobject]@{ DriveLetter = $p.DriveLetter DiskNumber = $disk.Number SizeGB = :Round($disk.Size/1GB,0) BusType = $phys.BusType # should say NVMe FriendlyName = $disk.FriendlyName # "MSFT NVMe Accelerator v1.0" SerialNumber = $disk.SerialNumber # unique per Azure disk NvmeNSID = $nsid AzureLUN = if ($nsid) { $nsid - 2 } else { 'n/a' } }

} | Format-Table -AutoSize

Cross-check against ARM before you touch anything

az vm show -g <rg> -n <vm> `

--query "storageProfile.dataDisks[].{lun:lun,name:name,sizeGb:diskSizeGb}" -o table

Match:

SizeGB (script) <-> sizeGb (ARM), and

AzureLUN (script) <-> lun (ARM)

Once both columns line up for the drive you want to grow, you have the right disk.

Resize the identified disk (no downtime on Premium SSD v2 attached to a running VM)

Grow the managed disk in Azure: Portal: VM > Disks > select the disk with the matching LUN > Size + performance > raise the size. or CLI: az disk update -g <rg> -n <disk-name> --size-gb <new-size>

Extend the volume inside Windows: In diskpart: list disk / select disk N / rescan Then in PowerShell: $n = <DiskNumber> $p = (Get-Partition -DiskNumber $n | Where-Object DriveLetter).PartitionNumber Resize-Partition -DiskNumber $n -PartitionNumber $p ` -Size (Get-PartitionSupportedSize -DiskNumber $n -PartitionNumber $p).SizeMax

That gives you the extra space for the new database without any restart or detach.

summary

SCSI script wasn't wrong, just wrong bus.

On NVMe VMs use Get-Disk / Get-PhysicalDisk + NSID; AzureLUN = NSID - 2.

Confirm by matching size + LUN with "az vm show" output, then resize that disk and extend the partition online.

2 answers

Your answer

MCarr 0 Reputation points

2026-07-13T16:57:36.6333333+00:00

Forgot to mention. I checked and it has no Storage Pools or Virtual Disk so that type of disk expansion by adding another drive to it is not a solution.

Answer 1

Hi,

Because this VM is using NVMe, the SCSI Bus/Target values showing as 0 is expected and is not the best field to use.

For Azure remote NVMe disks on Windows, use SCSILogicalUnit. Microsoft documentation notes that for NVMe disks, the guest SCSILogicalUnit value is the Azure portal LUN value plus 1.

So the mapping is:

Azure LUN = SCSILogicalUnit - 1

You can try this from inside the VM:

$driveLetter = "F"

$partition = Get-Partition | Where-Object DriveLetter -eq $driveLetter
$guestDisk = Get-Disk -Number $partition.DiskNumber
$wmiDisk = Get-CimInstance Win32_DiskDrive | Where-Object { $_.Index -eq $guestDisk.Number }

[PSCustomObject]@{
    DriveLetter      = $driveLetter
    WindowsDiskNo    = $guestDisk.Number
    Model            = $wmiDisk.Model
    SerialNumber     = $wmiDisk.SerialNumber
    SCSILogicalUnit  = $wmiDisk.SCSILogicalUnit
    AzureLun         = $wmiDisk.SCSILogicalUnit - 1
}

Then from Azure PowerShell, match that LUN to the attached managed disk:

$vm = Get-AzVM -ResourceGroupName "<rg-name>" -Name "<vm-name>"

$vm.StorageProfile.DataDisks |
    Select-Object Name, Lun, DiskSizeGB, @{n="ManagedDiskId";e={$_.ManagedDisk.Id}} |
    Sort-Object Lun

After you identify the correct Azure disk, take a snapshot/backup first, then increase that managed disk size in Azure. After resizing, rescan disks in Windows Disk Management and extend the partition/volume for the drive letter.

If this drive is part of Storage Spaces or a spanned volume, do not resize based only on the drive letter. In that case, map the physical disks in the storage pool first, because one Windows volume may be backed by multiple Azure data disks.

Answer 2

Hi, the zero SCSI values are expected on an NVMe-controller VM, so do not use SCSITargetId to choose the Azure disk. Map it using the NVMe namespace/serial information exposed by Windows and compare that with the managed disk properties in Azure. Before resizing, build a table of drive letter -> Windows disk number -> disk unique/serial identifier -> Azure managed-disk name/ID, and verify it twice. Take a database-aware backup/snapshot first. After increasing the managed disk size in Azure, rescan disks in Windows, extend the correct partition/volume, and confirm SQL Server sees the new space. Never resize based only on the order shown in Disk Management, because enumeration order can change after reboot.

Have an Azure SQL machine with Premium SSD v2 with NVME . I am unable to determine which drive is which.

NVMe namespace id: last integer in the disk's Location / UniqueId

2 answers

Your answer