Хранение виртуалок в LVM

Вообще то вот так:
(ssd -> pv -> vg -> lv -> host_fs -> raw -> vm_fs

Чтобы расширить VMку нужно сначала расширить lv, потом расширить raw образ и только потом расширить разделы внутри VMки.

Доктор, где вы берёте такие картинки? Нужно расширить lv и затем расширить ФС в ВМ. Почитай также про lvm thin provision.

Не нужно создавать файловую систему на LV и класть туда образ диска, LV можно (и нужно) непосредственно подключать к ВМ как диск.

virt-manager такое делать не давал. Сделал через virsh - завелось. Спасибо!

thin provision - интересная вещь! Буду курить. Спасибо!

/closed

Создай LVM-пул из твоего VG, будет давать.

Вы же понимаете, что при использовании thin provisioning вы должны быть всегда готовы добавить новое устройство к пулу, иначе внезапно случатся совершенно неожиданные проблемы.

Мониторинг спасает отца русской демократии от неожиданностей.

Просто нужно заранее планировать занимаемый объём, метадаты в том числе.

Это, кажется, занимает слишком много уровней абстракции

Не надо использовать промежуточные ФС.

Необходимо оперировать блочным устройством, которое будет использоваться ВМ.

Но я бы сейчас делал на CEPH.

Вот, почитать Вам:

http://docs.ceph.com/docs/master/rbd/rbd-cloudstack/

Когда виртуалка начинает быстро пухнуть (например, от каких нибудь кордампов/логов или от какого-нибудь dd if=/dev/zero of=/dev/sda5 с забытым count=1024), мониторинг обычно не помогает - слишком быстро всё происходит. Ctrl+C конечно срывает dd, но оно уже всё в page cache и стремительным домкратом флушится на диск. После чего начинается веселье, что запись в любой раздел виртуалки на тонком томе тупо падает по ошибке I/O или фризится прямо в процессе монтирования (зависит от политики обработки ошибок). Понятно что это всё решается - но далеко не всегда тривиально, особенно если в виртуалках используются какие-нибудь btrfs/zfs у которых redirect write по умолчанию включен.

Ну и у ТС, как японимаю по объему диска, «для дома на поиграться» - так что о мониторинге говорить не имеет смысла. Или вы считаете, что у каждого линуксоида дома заббикс установлен?

Ceph поверх одного диска? Нууу, это будет интересно. Хотя экспиренс прокачать ничего так, и впоследствии расширяться можно на другие хосты - это существенный плюс

каких нибудь кордампов/логов

Логи не растут так быстро, кордампы не создаются так массированно.

какого-нибудь dd if=/dev/zero of=/dev/sda5 с забытым count=1024

Часто ты такое в виртуалке делаешь? И главное — зачем?

у каждого линуксоида дома заббикс установлен

По себе сужу =).

Ceph поверх одного диска?

простите, не заметил, что у Вас используется ПК. Вскользь увидел слово «хост».

я у себя дома просто qcow2 использую. Образы лежат на ФС. Для чего усложнять дома?

Самообучение.

qcow2 слишком медленный.

qcow2 слишком медленный.

Кто Вам такое сказал? )

qcow2 слишком медленный.

Да не так что бы и сильно относительно хоста. Но все зависит от задач.
ЗЫ Да, таки thin отнюдь не быстрый.

qcow2 слишком медленный.

Это было очень давно и уже не актуально.

Тесты гонял. raw образ намного опережает qcow2.

Фраза «намного» это как «средняя по больнице». Я тоже тесты гонял разница не особо большая от хоста. В thin вы должны больше просадки получить.
Но повторюсь, все зависит от задачи. Безусловно raw (не thin) без снапшотов, будет быстрее чем qcow2. Но тут все понятно и так, по технологии, «fs над fs».

намного

ну, как принято, давайте пруф.

https://serverfault.com/questions/677639/which-is-better-image-format-raw-or-...

и, что это =) ?

fio показывайте. берем общий случай — 70% read, 30% write.

и, что это =) ?

То, что на момент 2015 года qcow2 таки отставал заметно от raw.

Raw block device быстрее.

никто не спорит

Часто ты такое в виртуалке делаешь? И главное — зачем?

В рамках тестирования. Потому что если этого не сделать, скрипты udev на него накидываются при вызове partprobe, отчего потом приходится с нехорошими словами возвращать систему в предыдущее состояние (убивать сервисы, отмонтировать, останавливать свап и т.п.)