Разделы LVM должны использоваться в изображениях виртуальной машины?
Другая альтернатива является qiv.
Быстрая Программа просмотра изображений для Linux, Соляриса (SunOS), FreeBSD и HP-UX... является очень маленькой и довольно быстрой gdk/Imlib программой просмотра изображений.
Требует: gdk-2.0 и Imlib2. Политика: GNU Функции GPL:
- перемещение и изменение масштаба изображения в полноэкранном режиме.
- установка изображения как x11 фон (центрируемый, размещенный рядом, расширенный..) с пользователем устанавливаемый цвет фона
- полноэкранный просмотр с большой строкой состояния
- внешняя поддержка программы "qiv-команды"
- режим экранной заставки
- яркость/контраст/гамма-коррекция
- реальная прозрачность
- maxpect (масштабируют к размеру экрана при сохранении соотношения сторон),
- scale_down (уменьшаются к большим изображениям для установки размеру экрана),
- слайд-шоу (с произвольным порядком, если Вы хотите),
- файловый сервер имени файла
- горизонтальное/вертикальное зеркальное отражение, вращайтесь слева/справа
- удалите функцию (переместитесь в .qiv-мусор/),
- перейдите к номеру изображения x, перейдите вперед/назад x изображения
- авторотация exif
- режим просмотра при запуске из файлового менеджера
"Это зависит".
Если Вы находитесь на среде, которой Вы управляете (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.
Логические тома легче создать на лету, изменить размер, удалить.
"К LVM или не" вопрос всегда имеет тот же ответ, он зависит :)
Это имеет смысл при необходимости в гибкости в диске (дисках), уровне раздела (разделов).
Это не имеет большого смысла, если Вы не нуждаетесь в гибкости, обеспеченной LVM, или не хотите использовать в своих интересах другие функции LVM
Мне на самом деле нравится использовать LVs, потому что они не легкодоступны с virt-сервера. Таким образом эти файлы не могут легко быть уничтожены/перемещены случайно.
Другие важные функции LVs:
- Можно сделать снимки
- Можно проанализировать диск IO на основе LV (
iostat) - Легкий изменить размер
- При помощи снимков можно сделать последовательный клон рабочих систем
Для сокращения сложности, я использую LV в качестве диска (не как раздел). Недостаток состоит в том, что я могу только легко изменить размер последнего раздела "диска" - но мой standard-VM-disk-layout принимает это во внимание (таким образом, последний раздел содержит данные важного приложения).
В дополнение к гибкости базировался LVM, образы виртуальной машины имеют потенциально меньше служебное, потому что к ним не получают доступ через файловую систему. С другой стороны, это убирает средства легко движущихся изображений вокруг, как Вы сделал бы с файлом. Не невозможный, но немного более сложный
-
1Это - ответ на другой вопрос. Вопрос здесь был об использовании LVM в гостях, не используя LVM на хосте (LVs для хранения дисков VM). – Stéphane Chazelas 29.10.2015, 19:13
-
2
Править: Ниже больше не верно. Значение использования тонкой резервации памяти, обеспеченной LVM для образов дисков VM, является, вероятно, ситуационным;
Вы выполняете VM's Разработки на ноутбуке? затем Вы, вероятно, более обеспечены с QCow2.
Управление фермой VM's, который может возможно использовать огромное количество устройства хранения данных через несколько дисков? LVM вероятен хороший способ управлять тем устройством хранения данных.
одна причина не использовать lvm является Вами, не может превысить возможности устройства хранения данных с помощью lvm. При создании 10 VM's с 100 ГБ устройства хранения данных Вам нужны 1 000 ГБ фактической дисковой емкости, даже если 9 из десяти VM's будет только когда-либо использовать 20 ГБ их файловых систем. Редкие Образы дисков или qcow2 изображения формата могут означать, что только устройство хранения данных, на самом деле используемое гостями, должно быть выделенным им.
На самом деле ли это полезно для Вас, зависит от того, в чем Вы нуждаетесь из своего устройства хранения данных.
-
1На самом деле можно превысить возможности устройства хранения данных с помощью lvm снимки. Это имеет наверху, все же. – derobert 13.09.2012, 18:53
-
2и на самом деле, более новые версии LVM поддерживают "тонкий пул", который является, превышают возможности w/o любая глупость снимок. – derobert 13.09.2012, 18:56
-
3Это - актуальный вопрос, хотя неправильный; то, что на "стандарт"/on-the-fly способ использовать результаты разделов/дисков LVM в обрисованном в общих чертах сценарии, конечно, стоит указать. Хотя, ответ мог быть изменен, чтобы отразить, что он добавит еще больше сложности к пути изучения. – ILMostro_7 11.02.2016, 22:47
Я на самом деле только использую LVM's для внешней памяти на уровне гипервизора, файлы изображений для птиц. Я также рекомендовал бы использовать их на гостевом уровне также. Это верно, что Вы не извлечете выгоду из объединения разрозненных источников устройства хранения данных или найдете легче увеличить общее доступное дисковое пространство (так как можно получить это столь же легко путем изменения размеров того, что гипервизор представляет), но когда-то Вы выделяете слишком много одной файловой системе. Вам мог бы понравиться простой способ взять 1 ГБ от/, выбирают и дают его / var (например). При выполнении регулярных разделов в самом VM затем, он делает аспект изменения размеров просто этим намного тяжелее.
В дополнение к другим хорошим ответам здесь, единственное действительно серьезное основание использовать LVM в VM является Вами, хотят, чтобы тестовая среда экспериментировала с и получила некоторый практический практический опыт с LVM.
Можно пройти различные ПРАКТИЧЕСКИЕ РУКОВОДСТВА и учебные руководства, распространенная практика (и not-so-common) гвозди администрирования LVM, настроить различные сценарии отказа и изучить, как иметь дело с ними.
т.е. как помощь самообразования.
Мой собственный опыт....
Я хотел использовать логический том (lv) с lvm2 для файловой системы ext4; не как диск, или, скорее, просто как не разбитый на разделы необработанный диск для fs.
Я обнаружил, что запуск ВМ останавливается на этапе initrd; если я закомментирую запись /etc/fstab, машина загрузится. Оставить запись /etc/fstab закомментированной было не тем решением, которое меня устраивало. Поэтому я создал обычный образ диска (все еще логический том), разбил его на один раздел с помощью fdisk и создал на нем файловую систему. Больше никаких проблем.
Соответствующие монтирования в моем /etc/fstab использовали UUID.
Я подумал об использовании file или filesystem, но решил отказаться.
В моем случае я использую систему Debian Jessie на базе Devuan