azure-ephemeral-disk-setup: LVM backend as an alternative to mdadm

Hello,

The release notes for azure-vm-utils v0.7.0 encourage feedback on this experimental feature.

While this is not feedback on the current implementation itself, I would like to suggest an alternative approach to using mdadm.

In our environments, LVM provides flexibility and visibility for administrators. It is also a familiar solution in Azure deployments, especially from the early SAP HANA on Azure recommendations, where LVM striping was commonly used to achieve higher disk performance.
So historically, LVM is already pre-installed on some images, since it has such other use cases as well.

One possible approach would be to create an "ephemeral" volume group containing all available NVMe direct disks.
The service could then create (striped) logical volumes for different purposes, such as:

Swap space
Temporary application data
Dedicated workloads with specific performance requirements

This approach would provide greater flexibility than exposing a single RAID device while still allowing administrators to use the available ephemeral storage efficiently.

At the same time, the current implementation could remain unchanged for the existing resource-disk workflow.

Or one can think of a nvme based ephemeral volume group and one resource group based volume group, and distribute workload to your needs (e.g. swap space on the classic resource group via logical volume and the nvme dedicated to the application, like the LSv3 vm sizes)

Thanks for considering the suggestion.

Start by reviewing the current azure-ephemeral-disk-setup implementation and the v0.7.0 release notes, then compare its mdadm workflow with the proposed LVM volume-group approach. Define how disks, swap, temporary data, workload-specific logical volumes, and existing resource-disk behavior should be handled; done means an agreed implementation scope and acceptance criteria.

Written by the indexing model from the issue text.