Следует ли использовать разделы LVM в образах виртуальных машин?

Следует ли использовать LVM для разделов при создании образов виртуальных машин (например, образов KVM)? Кажется, что это добавляет сложности, если вы хотите, скажем, смонтировать образ qcow2 на хосте, если образ имеет разделы LVM.

С другой стороны, кажется, что преимущества разделов LVM не столь значительны для образа виртуальной машины, поскольку гораздо проще перевести виртуальную машину в автономный режим и изменить размеры разделов, чем для физической системы.

"По-разному."

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

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

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

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

Все это говорит: выполнение всего этого на уровне гипервизора означает, что вам, вероятно, придется перезагрузить виртуальную машину, чтобы изменить размер разделов. Использование 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 в одном сегменте и разбить его на разделы / LVM.

Пример:

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

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

Логические тома проще создавать на лету, изменять их размер, удалять.
Вопрос «к LVM или нет» всегда имеет один и тот же ответ, это зависит :)
Это имеет смысл, если вам нужна гибкость на уровне диска (ов), раздела (ов).
Это не имеет особого смысла, если вам не нужна гибкость, предоставляемая LVM, или вы не хотите использовать другие функции LVM

Я на самом деле люблю использовать LV, потому что они не легко доступны с Virt-сервера. Таким образом, эти файлы не могут быть легко уничтожены / перемещены случайно.

Другие важные особенности ЛЖ:

• Вы можете сделать снимки
• Вы можете анализировать дисковый ввод-вывод на основе LV ( iostat)
• Легко изменить размер
• С помощью снимков вы можете сделать последовательный клон работающих систем

Чтобы уменьшить сложность, я использую LV как диск (не как раздел). Недостаток заключается в том, что я могу легко изменить размер только последнего раздела «диска», но моя стандартная компоновка диска VM учитывает это (поэтому последний раздел содержит важные данные приложения).

В дополнение к гибкости образы виртуальных машин на основе LVM потенциально имеют меньше накладных расходов, поскольку к ним не осуществляется доступ через файловую систему. С другой стороны, это убирает средства легкого перемещения изображений, как если бы вы делали это с файлом. Не невозможно, но немного сложнее

Мой собственный опыт ....

Я хотел использовать логический том (lv) с lvm2 для файловой системы ext4; не как диск, а точнее, просто как неразделенный сырой диск для фс.

Я обнаружил, что запуск виртуальной машины будет остановлен на этапе initrd; если я закомментирую /etc/fstabзапись, машина загрузится. Оставить /etc/fstabкомментарий было не то решение, с которым я был счастлив жить. Итак, я создал нормальный образ диска (все еще логический том), разделил его на один раздел fdiskи создал на нем файловую систему. Больше никаких проблем

Соответствующие горы в моем /etc/fstabиспользовали UUID.

Я думал об использовании файла или файловой системы, но решил против этого.

В моем случае я использую систему на основе Debian Jessie Devuan

На самом деле я использую только LVM для резервного хранения на уровне гипервизора, файлы изображений для птиц. Я также рекомендовал бы использовать их на уровне гостей. Это правда, что вы не выиграете от объединения разрозненных источников хранения или не найдете более легким увеличить общее доступное дисковое пространство (поскольку вы можете получить это так же легко, изменяя размер представляемого гипервизором), но иногда вы выделяете слишком много для одной файловой системы. , Вам может понравиться простой способ взять 1 гигабайт из / opt и передать его / var (например). Если вы делаете регулярные разделы внутри самой виртуальной машины, то это значительно усложняет изменение размера.

В дополнение к другим хорошим ответам здесь, единственная действительно хорошая причина использовать LVM внутри виртуальной машины - это то, что вы хотите, чтобы тестовая среда экспериментировала и получала практический опыт работы с LVM.

Вы можете просмотреть различные HOWTO и руководства, попрактиковаться в общих (и не очень распространенных) приемах администрирования LVM, настроить различные сценарии сбоев и узнать, как с ними справляться.

т.е. как самоучитель.

Редактировать: ниже уже не верно. Значение использования тонкой подготовки, предоставляемой LVM для образов дисков VM, вероятно, ситуативно;

Работаете ли вы на виртуальных машинах разработки на ноутбуке? тогда вам, наверное, лучше с QCow2.

Управление фермой виртуальных машин, которая может использовать огромное количество памяти на нескольких дисках? LVM, вероятно, является хорошим способом управления этим хранилищем.

Одна из причин не использовать lvm - вы не можете перезаписать хранилище, используя lvm. Если вы создаете 10 ВМ с 100 ГБ дискового пространства, вам потребуется 1000 ГБ фактического диска, даже если 9 из десяти ВМ будут когда-либо использовать только 20 ГБ своих файловых систем. Разреженные образы дисков или образы в формате qcow2 могут означать, что им должно быть выделено только пространство, фактически используемое гостями.

Будет ли это полезно для вас, зависит от того, что вам нужно из вашего хранилища.