I think when you create a Linux VM in Azure there are some important things you need to know. Although most of information are written by Microsoft I feel the repetion and collection is a very good opportunity for everybody to find the related information.
In this short article I would like to share with you two important facts regarding Azure Linux VMs.
VM with datadisks
An interesting question: “Can you tell me what partition is good for?”
I meet this question almost every day where somebody asks me whether the /dev/sdb or /dev/sdc is the first datadisk in Linux in Azure. The short answer is: /dev/sdc
Nevertheless the most important question is: WHEN?
After you create a VM in Azure the following is the key:
/dev/sda – OSDISK
/dev/sdb – DATA DISK
/dev/sdc – TEMP DISK (managed by Azure)
Please take care! If in this situation you create the adequate partitions then make the automatic mount in fstab you will be facing some serious issues after the next reboot (worst case your VM won’t be available anymore)
What should you do? Short answer: Reboot your machine before you want to create the partitions and mountings
After the rebout you can see the followings:
/dev/sda – OSDISK
/dev/sdb – TEMP DISK (managed by Azure)
/dev/sdc – DATA DISK
Yes! This is we wanted to achieve and after all reboots this will be the final picture regarding disks. From now you can create your partitions and you can do the automatic mounts in fstab (with UUID).
Same UUID for OSDISK
There is a pain point regardint Linux VMs in Azure: There is not console during boot.
So something happens with our Linux machine during boot we cannot fix the issue via ssh console. 🙁
Good news and everyone relized that we can mount the fixable VM’s OsDisk to another VM and we can fix the most of issues. 🙂
This is a fairy tale until this point then you will be in trouble when try to mount the harmed VHD to a working VM because you will get an error message to “can’t mount…”.
I must say this is normal and required because in Azure when you create a VM from basic Azure image the OS Disk UUIDs’ will be same regarding your all VMs. Therefore you cannot mount the other VM’s Os Disk. In this case you have to use the -o nouuid option in mount command. Example: mount -o nouuid /dev/sdd1 /data/external
It works and you can fix the harmed OS Disk then the life is go on – and your VM as well.
I hope this helps. 🙂