Not clear how the user can identify the disk they would like to mount

[yangsiyu007]

It'd be helpful to explain how the user can identify which disk displayed in the result of the command dmesg | grep SCSI is the one of interest.

"Here, sdc is the disk that we want" is not helpful.

I found out by reading https://chrismckee.co.uk/creating-mounting-new-drives-in-ubuntu-azure/ where it showed the command sudo lshw -C disk, from where I identified the disk by looking at its size and noting down its bus info, from which I can correlate it back to the results of dmesg | grep SCSI. I'm sure you have a better way to do this.

It would also be good to explain why we are grepping SCSI in the command - to note that it is always the case if they just attached a data disk to the VM on Azure Portal.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 6fde1939-787d-2aa5-4b29-d303f8ed49cb
• Version Independent ID: c2838cb5-c34c-e0ff-b280-b86f29453cad
• Content: Attach a data disk to a Linux VM
• Content Source: articles/virtual-machines/linux/attach-disk-portal.md
• Service: virtual-machines-linux
• GitHub Login: @cynthn
• Microsoft Alias: cynthn

[mimckitt]

Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

[marcelo-salvatori]

Hi, Yang.

This is pretty much a linux thing.

In Azure the OS disk is "sda", while "sdb" is the temporary disk reserved for Azure (like the D:\ drive in windows server).

"sdc" is the only available option, because it is the only option left. But explaining you a little bit about the name of this disk:

• sd stands for SCSI
• c is the order of the disk ( a is first disk, b second and so on)
• sdc means that this is the third SCSI disk in the server

I know this is not the perfect answer, but I hope it helps you.

[yangsiyu007]

Thanks @marcelo-salvatori, this is helpful but I think it'd be good to accommodate Linux newcomers in the document itself. It's not clear from this document alone that the OS disk and the temp disk are sda and sdb respectively (could add a link to where this is explained). Also, what if there are already data disks attached or if the user attached more than one on the Portal before logging into the VM - how then do you identify one particular one?

[marcelo-salvatori]

Your concern is a real thing @yangsiyu007. I also got a little confused with this article.
Aditional tips to help identifying disks:

• To find out disk's size you can use "fdisk -l". This command will list all yout disks, their sizes and existing partitions
• To find out if a disk is SSD or HDD use "cat /sys/block/sda/queue/rotational", replacing sda with the disk you want to check. You should get 1 for hard disks and 0 for a SSD.

To be honest, in Azure we seem to have a problem, that all disk seems to be indentified by VMs as HDDs. I've seen this behaviour both in Windows and Linux Server.
As for Windows this can be changed using the "Set-PhysicalDisk" command I haven't found a way to do the same in Linux. Maybe with PowerShell in linux you can be able to do it, but I haven't tried this myself.

The way to identify it, therefore, would be jurassic. You gotta add one disk at a time and identify it, add another and identify it and so on. It is lame, I know. But it is the only work around I have found. I hope Azure fix this soon enough.

References:
https://docs.microsoft.com/en-us/azure/virtual-machines/linux/about-disks-and-vhds#temporary-disk
https://unix.stackexchange.com/questions/65595/how-to-know-if-a-disk-is-an-ssd-or-an-hdd

[jpalo]

cat /sys/block/[DRIVE]/queue/rotational or lsblk -d -o name,rota doesn't work in Azure. It says 1 for sda/sdb/sdc, although sda is Premium SSD, sdb is Temp SSD, and sdc is Standard HDD.

Also fdisk -l doesn't return anything.

Testing on Ubuntu.

[szarkos]

It is not always assured that sda and sdb will be the OS and ephemeral disk respectively. The best way to identify a particular data disk is via LUN. You can actually specify the LUN when you attach a disk via CLI/Powershell, or by default the numbering will start at 0 and increment by 1 for each newly attached disk.

On a lot of standard Linux images on Azure there is a udev rule that creates friendly/persistent symlinks for each disk, so you don't need to worry about the sda/sdb/etc. naming. After you attach a data disk you should see a new symlink created in /dev/disk/azure/scsi1/* that identifies each disk (and its partitions) by LUN.

See also:
https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/troubleshoot-device-names-problems

[mimckitt]

Thank you all for the discussion on this. We have continued to discuss this internally and at this time do not plan on updating the doc with any additional steps. @szarkos last response is precise and a good comment to close on. This issue will remain on the doc and if other users continue to comment on this we can always reopen the discussion.

[pflickin]

It is frustrating that one needs to read though all of the closed feedback to get this info. If the last post is indeed helpful, it should be included in the above doc.

[hugo-paredes]

I've to agree with @pflickin. There should be an easier way to get to this information. It would be very helpful if you want to automate this.

[weltkante]

Thank you all for the discussion on this. We have continued to discuss this internally and at this time do not plan on updating the doc with any additional steps.

WTF? Its still impossible to figure out the right drive names following the current docs. I recently had selected an additional drive because the ones that came with the VMs normally are not large enough and it took me several hours to figure out how to mount it. (It did not come across this thread while searching for it, so having a solution here is not discoverable.)

Thats not acceptable for something people are paying for.

For what its worth, you can use sudo fdisk -l to get drive sizes and mount -l and df -h to figure out existing mounts and their sizes, so as long as you don't try adding multiple drives with the same size at the same time it works out by cross-comparing these outputs.

Its not really user friendly though and having to search several hours for those commands is not acceptable either, and even then, given that you can add multiple drives of the same size at VM creation time without being given any warning or guidance is awful user experience.

[cynthn]

Yes, this doc needs an update. I'm also going to drop these links in here in the meantime, in case they are helpful:

https://github.com/canonical/cloud-init/blob/master/udev/66-azure-ephemeral.rules
https://github.com/Azure/WALinuxAgent/blob/master/config/66-azure-storage.rules

[cynthn]

For anyone else interested in how to determine which disk is the correct one, I've updated the doc to use lsblk -o NAME,HCTL,SIZE,MOUNTPOINT | grep -i "sd" which shows all of the disk, mounts etc with the LUN number and size. If you compare that to the Azure portal > VM > Disks, you should be able to find the disk by LUN number if all of the disks are the same or similar size. Hope this help!

[Davidsv]

@cynthn
The lsblk -o NAME,HCTL,SIZE,MOUNTPOINT | grep -i "sd" command gives this output as indicated in the article:

sda     0:0:0:0      30G
├─sda1             29.9G /
├─sda14               4M
└─sda15             106M /boot/efi
sdb     1:0:1:0      14G
└─sdb1               14G /mnt
sdc     3:0:0:0       4G

However as a linux newcomer I do not know which of these numbers indicate that sdc is LUN 0. Is it supposed to be one of the zeroes in 3:0:0:0? If so, sda also has zeroes in those places. So where does it say that sdc is unequivocally LUN 0?