Мы можем создать lvm группу объема со связанным устройством?

"Это зависит".

Если Вы находитесь на среде, которой Вы управляете (VMware или kvm или безотносительно), и можете принять свои собственные решения относительно производительности диска QoS, то я рекомендовал бы не использовать LVM в Вашем VMs. Это не покупает Вас много гибкости, что Вы не могли достигнуть уровень гипервизора.

Помните, гипервизор уже эффективно выполняет эти задачи. Если Вы хотите смочь произвольно изменить размер файловых систем (прекрасная идея), просто создайте отдельный виртуальный диск для каждой файловой системы.

Одна вещь, о которой Вы могли бы думать, поскольку Вы идете по этой дороге. Вы не должны даже обязательно помещать разделы на свои виртуальные диски этот путь. Например, можно создать виртуальный диск для /home; это /dev/vdc в Вашем vm. При создании файловой системы просто сделайте что-то как mke2fs -j /dev/vdc вместо того, чтобы указать раздел.

Это - прекрасная идея, но... большинство инструментов (и другие администраторы, которые приезжают после Вас) будет ожидать видеть разделы на каждом диске. Я рекомендовал бы просто поместить единственный раздел на диск и сделан с ним. Это действительно означает еще один шаг при изменении размеров файловой системы, все же. И не забывайте правильно выравнивать свои разделы - запуск первого раздела на уровне 1 МБ является хорошим эмпирическим правилом.

Все, что сказало - Выполнение этого всего на уровне гипервизора, означает, что, вероятно, необходимо перезагрузить VM для изменения размеров разделов. Используя LVM позволил бы, Вы к горячему - добавляете виртуальный диск (предположение, что Ваша комбинация гипервизора/ОС позволяет это), и разверните файловую систему без перезагрузки. Это определенно плюс.

Между тем при использовании облачного поставщика это более тонко.

Я не знаю много о Azure, GCP или любом из плееров меньшего размера, таким образом, я не могу помочь там.

С AWS можно последовать моему совету выше, и Вы часто будете очень хорошо. Можно (теперь) увеличить размер объемов EBS (виртуальные диски) на лету и изменить размер разделов и т.д.

Однако в общем случае, могло бы иметь смысл помещать все на единственный большой объем EBS и использовать LVM (или, я предполагаю, простые разделы). Amazon дает Вам предел IOPS на каждый объем. По умолчанию этот предел масштабируется с размером объема. например, для gp2 объемы Вы получаете 3 IOPS на гибибайт (минимум 100 IOPS). См. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

Для большинства рабочих нагрузок Вы захотите, чтобы весь Ваш доступный IOPS был доступен любой файловой системе, в зависимости от потребности в данный момент. Таким образом, имеет смысл делать один большой объем EBS, получать весь Ваш IOPS в одном блоке и partition/LVM это.

Пример:

3 диска с независимыми файловыми системами/областями подкачки, каждый 100 ГБ в размере. Каждый получает 300 IOPS. Производительность ограничена 300 IOPS на каждом диске.

1 диск, 300 ГБ в размере. Разделы LVM на диске 100 ГБ каждый. Диск получает 900 IOPS. Любой из разделов может использовать все 900 IOPS.