Я только что построил блестящий новый хост виртуальной машины на основе KVM / libvirt, содержащий 4 жестких диска SATA II и работающий под управлением CentOS 5.5 x86_64.
Я решил создавать диски виртуальных машин как логические тома в группе томов LVM, управляемой как пул хранения libvirt, вместо обычной практики создания дисков как образов qcow.
Что я не могу решить заключается в том, следует ли мне создавать логические тома виртуальной машины в группе томов хоста виртуальной машины или в выделенной группе томов.
Какой метод выбрать и почему?
md0 содержащий /boot файловая системаmd1 занимая оставшееся пространство, которое содержит группу томов LVM vghost. vghost содержит корневую файловую систему хоста виртуальной машины и раздел подкачкиvghost как требуетсяvghost относительно легкоНесмотря на то, что этот метод, кажется, работает, я не могу избавиться от ощущения, что это как-то плохая идея. Я чувствую что:
md0 и md1 как в методе 1, кроме make md1 достаточно большой, чтобы вместить хост виртуальной машины (например, от 5 до 10 ГБ)md2 занимая оставшееся пространство. md2 содержит группу томов LVM vgvms, чьи логические тома будут использоваться исключительно виртуальными машинамиvgvms не боясь сломать ОС хостаvgvms, что не очень хорошо.ОБНОВЛЕНИЕ №1:
Одна из причин, по которой меня беспокоит нехватка дискового пространства хоста виртуальной машины в методе 2, заключается в том, что я не знаю, достаточно ли мощный хост виртуальной машины, чтобы запускать все службы на виртуальных машинах, т.е. Возможно, мне придется перенести некоторые / все службы с виртуальных машин на ОС хоста.
ОБНОВЛЕНИЕ №2:
Одна из причин, по которой я считаю, что система не может быть спроектирована для использования хоста VG в качестве пула хранения libvirt в методе 1, - это некоторое поведение, которое я заметил в virt-manager:
Хорошо продуманный вопрос!
Я бы выбрал метод 2, но это больше личное предпочтение. Для меня недостатки метода 2 не являются большой проблемой. Я не вижу, чтобы операционная система хоста переросла свой раздел 5-10 ГБ, если только вы не начнете устанавливать на нее дополнительные вещи, чего вам действительно не следует. Для простоты и безопасности ОС хоста действительно должна быть минимальной установкой, не запускающей ничего, кроме минимума, необходимого для администрирования (например, sshd).
Минусы метода 1 на самом деле не проблема, ИМО. Я не думаю, что будет какой-либо дополнительный риск для безопасности, поскольку, если рутированная виртуальная машина каким-то образом способна вырваться из своего раздела и заразить / повредить другие разделы, наличие ОС хоста на отдельном VG может не иметь никакого значения. О двух других минусах я не могу говорить на собственном опыте, но мне кажется, что CentOS, LVM и libvirt достаточно гибкие и надежные, чтобы не беспокоиться о них.
РЕДАКТИРОВАТЬ - ответ на обновление 1
В наши дни виртуализация оказывает очень низкое влияние на производительность, особенно при использовании процессоров со встроенной поддержкой, поэтому я не думаю, что перенос службы с гостевой виртуальной машины в ОС хоста когда-либо стоил бы. Вы мощь получить прирост скорости на 10%, работая на «голом железе», но вы потеряете преимущества небольшой, жесткой, безопасной ОС хоста и потенциально повлияете на стабильность всего сервера. Не стоит, ИМО.
В свете этого я все же предпочитаю метод 2.
Ответ на обновление 2
Кажется, что конкретный способ, которым libvirt предполагает размещение хранилища, является еще одним аргументом в пользу метода 2. Моя рекомендация: используйте метод 2.
Возможно, вы захотите взглянуть на это, может быть, поработайте и посмотрите, как этот проект делает то, о чем вы говорите.
ProxmoxVE - это хост KVM без операционной системы, в котором используется реализация libvirt на Perl, а не более тяжелый аналог RHEL. Он реализует оба сценария.
Виртуальные диски .raw и разреженные, похожи на .qcow, но быстрее.
Форматы образов дисков qcow и vmdk также поддерживаются, но я думаю, что здесь могут быть ограничения LVM. Я ими не пользуюсь, поэтому особо не могу сказать об этом.
Хранилище LVM совместно используется виртуальными машинами на узле и может быть устройствами DRBD.
Что касается совместного использования пространства VG ОС, единственное ограничение, о котором следует беспокоиться, - это размер моментального снимка во время резервного копирования. Здесь это значение можно изменить в файле конфигурации, и я иногда вижу на форумах, где людям приходилось его менять, но значения по умолчанию хорошо служили мне уже пару лет - даже с огромными виртуальными дисками.
http://pve.proxmox.com/wiki/Storage_Model#LVM_Groups_with_Network_Backing
Найдена группа томов "LDatastore1" с использованием типа метаданных lvm2.
Найдена группа томов "LDatastore0" с использованием типа метаданных lvm2.
Найдена группа томов pve с использованием типа метаданных lvm2.
ACTIVE '/ dev / LDatastore1 / vm-9098-disk-1' [4,00 ГБ] наследовать
ACTIVE '/ dev / LDatastore1 / vm-7060-disk-1' [2,00 ГБ] наследовать
ACTIVE '/ dev / LDatastore1 / vm-5555-disk-1' [8,00 ГБ] наследовать
ACTIVE '/ dev / LDatastore0 / vm-4017-disk-1' [8,00 ГБ] наследовать
АКТИВНЫЙ '/ dev / LDatastore0 / vm-4017-disk-2' [512,00 ГБ] наследовать
ACTIVE '/ dev / LDatastore0 / vm-7057-disk-1' [32,00 ГБ] наследовать
ACTIVE '/ dev / LDatastore0 / vm-7055-disk-1' [32,00 ГБ] наследовать
ACTIVE '/ dev / LDatastore0 / vm-6030-disk-1' [80,01 ГБ] наследовать
АКТИВНЫЙ '/ dev / pve / swap' [3,62 ГБ] наследовать
АКТИВНЫЙ '/ dev / pve / root' [7,25 ГБ] наследовать
АКТИВНЫЙ '/ dev / pve / data' [14,80 ГБ] наследовать
ЦП БОГОМИПС: 53199.93
REGEX / СЕКУНДА: 824835
РАЗМЕР HD: 19,69 ГБ (/ dev / mapper / LDatastore0-testlv)
БУФЕРИРОВАННЫЕ ЧТЕНИЯ: 315,17 МБ / с
СРЕДНЕЕ ВРЕМЯ ПОИСКА: 7,18 мс
FSYNCS / СЕКУНДА: 2439.31
ЦП БОГОМИПС: 53203.97
REGEX / СЕКУНДА: 825323
РАЗМЕР HD: 7,14 ГБ (/ dev / mapper / pve-root)
БУФЕРИРОВАННЫЕ ЧТЕНИЯ: 198,52 МБ / с
СРЕДНЕЕ ВРЕМЯ ПОИСКА: 0,26 мс
FSYNCS / SECOND: 1867,56
Пока только одна система пытается использовать любой данный LV в режиме чтения / записи в любое время, возможно использовать одну и ту же VG для хоста и гостей. Если несколько систем попытаются записать на один и тот же LV, это приведет к повреждению файловой системы.