В каком виде хранить VPS на Qemu-kvm?

lvm

qcow2

lvm

copy-on-write нету, фу.

lvm + virtio

и не нужно.

Ок.

copy-on-write нету, фу.

Не релевантно.

LVM

qcow2

если не сложно, то можно объяснить чем одно лучше другого или в чем вообще разница?

гуглил по этому вопросу.. в одном месте говорят, что qcow2 быстрее, в другом, что lvm

я храню в raw потому что у меня эта проблема: раздуло образы всех виртуалок

qed

Я храню в LVM. Но у меня образ не большой... С LVM гораздо удобней, чем с raw. Можно уменьшать/увеличивать размер разделов когда надо. Про qcow2 ничего не скажу, но не уверен, что образ получится уменьшить(если он распухнет) так же быстро, как я меняю размер доступного места для LVM.

Вроде бы он очень просто ресайзится..

Я хотел бы еще спросить по поводу типа носителя.. Лучше всего ведь использовать Virtio? Этот же вопрос касается и сети.. также virtio?

Лучше всего ведь использовать Virtio? Этот же вопрос касается и сети.. также virtio?

Yes

А security-баг в qemu, связанный с хранением на LVM,уже исправили?

Ещё вариант - qcow2 на LVM.

qcow2 on LVM - что бы почитать?

Извращенно как-то :)

Еще вопрос. А как с миграцией? Проблем не возникает? Насколько я знаю, сначала создается аналогичный раздел на другой ноде, а затем обычным способом, через virsh migrate переносится система?

Да, лучше использовать virtio. Для виртуалок с оффтопом можно его не использовать, а так-вроде как производительность у virtio выше.

А security-баг в qemu, связанный с хранением на LVM,уже исправили?

Эт какой?

Совершенно верно. Кроме virsh есть ещё и gui какое-то, но с virsh удобней работать, чем по кнопкам тыкать...

Тест на тест не приходится. Как-то я замерял у себя, особой разницы не заметил. Может, dd не самая подходящая тулзень для измерения скорости работы блочных устройств, не знаю... Просто я другой подобной утилиты не встречал.

ну я до создания темы много почитал об этом.. в разных ситуациях выигрывают различные способы.. где-то LVM, где-то qcow2.. хотя на самом деле меня больше интересует работа сети. Т.к. нет ничего, что активно ведет запись на хард. В основном чтение, один раз и хранит в ОЗУ (игровые сервера например).

В общем, до установки Ubuntu, я поигрался с Proxmox, там использовал qcow2.. там ставил на виртуалку убунту, и сейчас юзаю LVM, также ставил Ubuntu на виртуалку. По ощущениям, qcow2 на Proxmox'е кажется быстрее работал (установка и т.д.) но могу ошибаться. На глаз вряд ли можно такое определить.

Но все же будет более удобное в использовании? Более мобильное.. Вдруг будет необходимость перебросить VPS на другую ноду.. С чем будет быстрее это сделать?

Да, вначале нужно создать аналогичный раздел на другой ноде. У меня проблем не возникало, делал всё как написано в официальной документации к virsh. Правда, не так часто я это делал. Поэтому не поручусь, что миграция всегда проходит гладко.

Быстрее с образом. В случае с LVM нужно создать виртуальную группу томов и том с теми же именами, что были на системе, с которой будет осуществляться миграция. Перед миграцией убедитесь, что окружение вашей VM(сетевые бриджи, образа iso, дисковые разделы на LVM) будет доступно по тому же пути в системе, на которую вы мигрируете ваш VPS. virsh пока не умеет воссоздавать нужное окружение на другой ноде.

А по поводу разметки диска в случаи, если я буду использовать образы?

swap 4g, root - все остальное?

Для виртуалок с оффтопом можно его не использовать

Я бы так не сказал. Я бы сказал необходимо!

Размер swap зависит от потребностей системы, которая будет вертеться на VDS. Не очень нагруженная VDS отлично работает даже с 512Мб подкачки. Вы должны оценить(если надо провести тестирование), какой размер swap вам реально необходим для работы определённого набора ПО с орпеделённой нагрузкой. 4Гб это очень щедро.

Нет, Вы не поняли..я имею введу размер swap раздела на ноде :)

Либо я не так Вас понял.

Я храню на LVM и на работе(LVM-тома лежат на SAN-е, экспортируемом по iSCSI, Ganeti-кластер с миграцией виртуалок) и дома(энтерпрайза поменьше - всего-лишь libvirt+virt-manager)

А каким образом происходит миграция виртуалок между нодами? Есть какая-нибудь схема или что-то вроде этого? Файлы файлы виртуалки напрямую отсылаются на другую ноду, или куда-то сохраняется как временный файл?

На ноде 4Гб нормально. Я подумал, что вы VDS 4Гб хотите отдать, это слишком жирно для VDS-ки...

каким образом происходит миграция виртуалок между нодами?

Схема такая: iSCSI-хранилище экспортируется на физ. ноды. На хранилище - Clustered LVM, каждая виртуалка - отдельный том. При миграции происходит только перенос содержимого оперативной памяти и запуск виртуалки на другой ноде. Downtime при живой миграции по замерам(в тепличных условиях) - до 5 секунд(здесь же время, за которое до свича дойдет что мак уже на другом порту). Сама миграция выполняется от 10 до 30 секунд(в зависимости от кол-ва оперативы на виртуалке).

т.е. насколько я понял, у ваших нод общее хранилище, поэтому все так быстро?

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

если у меня нет общего хранилища

Тогда самый простой способ - реплицировать каждое изменение на соседние ноды. Например - через DRBD

Либо это не то что мне нужно, либо я не правильно понял, что это такое :)

НО в общем, вопрос был другим.. А именно: Требуется ли какое-то дополнительное место (например для временных файлов) во время Live Migration? Где-то читал, что сначала сервер упаковывается во временный файл, а затем уже отправляется на другую ноду.. Но мне кажется, что это немного глупая реализация, поэтому хочу уточнить, так ли это..

Требуется ли какое-то дополнительное место (например для временных файлов) во время Live Migration?

Нет, потому что во время миграции в моей схеме образы жестких дисков УЖЕ синхронизированы, происходит передача RAM -> RAM.

Где-то читал, что сначала сервер упаковывается во временный файл, а затем уже отправляется на другую ноду.. Но мне кажется, что это немного глупая реализация, поэтому хочу уточнить, так ли это..

Возможно при других схемах построения кластера так и делается. Но если образ виртуалки будет 100 гигов, допустим, то миграция в отсутствии Fiber Channel или Infiniband займет довольно долго, что не гуд.

Тогда нужно будет задуматься об общем хранилище.. просто сейчас такой возможности нет

Тогда нужно будет задуматься об общем хранилище

Как я уже говорил - можно обойтись без общего хранилища, если использовать DRBD

Сейчас немного прочитал про DRBD.. Допустим я на двух нодах создам LVM VG1, то их нужно просто соединить по DRDB и они как RAID1 будут зеркалироваться?

Да

то их нужно просто соединить по DRDB

Только не просто, а вдумчиво тюнинговать канал и подбирать нормальное сетевое оборудование. Лучше многоголовые карты Intel. Каналы bounding.

В общем, я понял, что лучше пока постараться обходится без миграции, а потом собрать нормальное оборудование :) с внешним хранилищем и т.д.

Лучше два внешних хранилища и из них raid. А иначе Ваше хранилище становится узким местом. На iSCSI дороже будет чем на DRBD.

Я думаю, что лучше пока постараться не использовать миграцию.. Позже немного изменить конфигруацию нод и купить какой-нибудь NAS.. а на ноды поставить SSD под систему и кэш.

Просто мы не планировали организацию нод и как-то не задумывались о таких вопросах.

и купить какой-нибудь NAS

Вы имели ввиду SAN? Диски Гостей в виде файлов, уже выше решили что медленно.

а на ноды поставить SSD под систему и кэш.

Вы имели ввиду под гостевые домены? Хосту SSD не зачем, выигрыш 0 от такой схемы.

Возможно и SAN :) с сетевыми хранилищами и прочими системами дела еще не имел.. и с виртуализацией я толком то и не работал. Пока еще учусь в этом направлении.

Я понял, я постарался направление задать!

ну, в общем спасибо.. нужно будет подробнее почитать об этом всем.

Необходимо использовать или необходимо не использовать?

без virtio ввод/вывод гостя win будет тормозить.