Azure Disk Encryption with EncryptFormatAll feature for Data disks on Linux IaaS VM

In this blog, we will introduce you to the new Azure disk encryption feature parameter EncryptFormatAll. It is a new feature parameter to reduce encryption times for Storage backed data disks on Linux VMs . The EncryptFormatAll support is available starting with Azure PS SDK release 5.0.0 and Azure CLI 2.0.17 releases. When the Linux Disk Encryption extension is deployed with the EncryptFormatAll parameter, it will go through all the partitions and encrypt format each partition which:

  • Is not a root/OS/boot partition
  • Is not already encrypted
  • Is not a resource disk/BEK volume, and
  • Is mounted

The partition will be formatted with its current file system and will be remounted back to where it was before EncryptFormatAll was executed. If there is a data disk that you don’twant formatted and it happens to satisfy all the conditions above, you can exclude it from EncryptFormatAll by unmounting it. If you’re setting this option while updating encryption settings, it might lead to a reboot before the actual encryption. In this case, you will also want to remove the disk you don’t want formatted from the fstab file. Similarly, you should add the partition you want encrypt-formatted to the fstab file before initiating the encryption operation.

NOTE: You should first try out the EncryptFormatAll first on a test VM, understand the feature parameter and its implication before trying it on the production VM. The EncryptFormatAll option formats the data disk and all the data on it will be lost.



Q. How do I test the EncryptFormatAll feature parameter using ARM template
A. To test the EncryptFormatAll option, you may take any pre-existing ARM template that encrypts a Linux VM and change the following fields for the AzureDiskEncryption resource:

  • Change “EncryptionOperation” from “EnableEncryption” to “EnableEncryptionFormatAll”

Here is an example template that can be used to encrypt-format-all a running Linux VM:

Q. How do I test the EncryptFormatAll feature parameter using Azure disk encryption PS cmdlet ?
A. You can use the Azure disk encryption 'Set-AzureRmVMDiskEncryptionExtension' cmdlet [see the Azure PS SDK release link above] with the ‘-EncryptFormatAll’ parameter to encrypt the data disk using the ‘-EncryptFormatAll’ parameter.

Q. I have multiple data disks. How do I Encrypt-Format only some of them?
A. EncryptFormatAll will skip all disks which are:

- OS or boot partitions
- LVM/RAID disks
- Already encrypted disks
- Currently unmounted disks

You can unmount the disks you don’t want to encrypt-format during encryption. Note that the encryption process involves rebooting the VM, so you must also temporarily remove the disk from /etc/fstab.

If you want to encrypt these disks without formatting them, you can run the encryption command again without the ‘-EncryptFormatAll’ switch.

Q. How do I use EncryptFormatAll with LVM?
A. We recommend an LVM-on-crypt setup. This can be done as follows:

- Add the data disks that will compose to the VM
- Format, mount and add these disks to the fstab file

# For all the following examples replace the device-path and mountpoints with whatever suits your use-case.

# Format the newly added disk. Note that we use symlinks generated by azure here
mkfs -t ext4 /dev/disk/azure/scsi1/lun0*

* The reason for doing this is to avoid problems related to device names changing. Please see this link for details -  /en-us/azure/virtual-machines/linux/troubleshoot-device-names-problems

# Mount the disks
mount /dev/disk/azure/scsi1/lun0 /mnt/mountpoint

# Add to fstab
echo "/dev/disk/azure/scsi1/lun0 /mnt/mountpoint ext4 defaults,nofail 1 2" >> /etc/fstab

- Run the cmdlet with ‘-EncryptFormatAll’ to encrypt these disks
# Enable encryption on the VM with ‘-EncryptFormatAll’
Set-AzureRmVMDiskEncryptionExtension -ResouceGroupName "myresourceGroup" -VMName "myVMName" -DiskEncryptionKeyVaultUrl "" -EncryptFormatAll

- Set up LVM on top of these new disks
Note that currently, the encrypted drives are unlocked after the VM has finished booting. So, the LVM mounting will also have to be subsequently delayed.