Опции монтирования файловых систем с образами вируальных машин

есть еще предложения по теме вопроса?

Канеш. Лови: под образ виртуалки не нужна ФС.

man lvm

а что нужно?

man lvm

не понял?

Тебе как бы намекают, что не обязательно хранить образы виртуалок, в виде файлов. Есть ещё, например, блочные устройства, в частности - lvm

а как их копировать? Мне удобны образа в виде файлов.

dd if=/dev/mapper/vg-lv of=file

не интересно, спасибо. Есть что-нибудь интересное по теме треда?

Кроме noatime в опциях монтирования ничего интересного нет. Интереснее cache=none в настройках виртуалки, чтобы она блочный кеш хоста не засирала.

noatime можно везде ставить, но с виртуалками это не сильно что-то изменит, потому что файлов мало.

Ты бы тип ФС указал для каких-то конкретных предложений. Из общего еще могу noexec предложить

ещё есть zvol

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

zvol, копируются мухой + сжатие самих волюмов

И чем lvm для образа лучше дырявого (sparse) файла, или zvol?

на люнексе

Там когда-нибудь работающий quickassist в дедупе сделают? А то считать контрольные суммы одними инструкциями из стандартного набора в 2015 - «это конечно приколько, когда все соснули, но как-то неинтересно».

от дедупликации только один вред (не нужна), сжатия тостатошно.

не нужна на виртуалках с 100500 одинаковых файлов

Типичное

если не работает/сломано, значит вам это не нужно

И да, в соляре оно работает, в фряхе тоже, а у афтырей zfsonlinux CDDL головного мозга. Хотя GPLv3 емнип не запрещает юзать cryptoapi (и следовательно аппаратный обсчёт SHA) в не-GPL модулях.

а как их копировать?

откройте для себя снапшоты lvm

Мне удобны образа в виде файлов.

и сопуствующее им уменьшение производительности за счет дополнительной файловой прослойки

дедуп требует немеренного количества рамы, поэтому и не нужна

откройте для себя снапшоты lvm

потрогайте снапшоты от zfs и почувствуйте разницу.

ничего не имею против :-)

...стоящей по три копейки за гиг.

zfs кстати сам по себе тоже жрёт нормально так. Давайте юзать жыр32, чё.

а как их копировать?

Например, через virsh vol-clone.

стоящей по три копейки за гиг.

ага особенно годная рама с ецц

откройте для себя снапшоты lvm

спасибо, пока не хочу

и сопуствующее им уменьшение производительности за счет дополнительной файловой прослойки

пока всё устраивает

вот это интересно, спасибо

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

1. Память с ецц в общем тоже стоит копейки (по сравнению скажем с HGST Ha10).

2. Мосье хоть считал, сколько потребуется памяти, или просто где-то слышал, что МНОХА?

3. На zfsonlinux дедуп жрёт не память, а проц. Почему - см. выше (не работает аппаратный обсчёт контрольных сумм).

не память

http://constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe

For every TB of pool data, you should expect 5 GB of dedup table data, assuming an average block size of 64K.
This means you should plan for at least 20GB of system RAM per TB of pool data, if you want to keep the dedup table in RAM, plus any extra memory for other metadata, plus an extra GB for the OS.

ецц в общем тоже стоит копейки (по сравнению скажем с HGST Ha10).

ну-да, ну-да, Skoda тож копейки стоит по сравнению с Bugatti

http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size...

Просвещайся, например.

Calculate memory requirement as follows:

Each in-core deduplication table (DDT) entry is approximately 320 bytes.
Multiply the number of allocated blocks by 320.

nbw blind_oracle DALDON я, конечно, же посмотрю man lvm, но не могли бы вы на пальцам передать суть схемы с использованием lvm? Как это будет выглядеть? Картина вцелом. Спасибо.

не могли бы вы на пальцам передать суть схемы с использованием lvm? Как это будет выглядеть? Картина вцелом. Спасибо.

Грубо говоря, каждый том (LV) виртуалка определяет как блочное устройство, где может присутствовать таблица разделов и некоторая разметка.

ну это-то как раз понятно. Мне непонятно как такие вещи содержать и обслуживать.

как такие вещи содержать и обслуживать.

Схема обслуживания зависит от конкретных задач.
Для выполнения основных действий достаточно интерфейса управления гипервизором после добавления StoragePool типа VG.
Через virt-manager это всё делается элементарно.
А тюнинг как раз описывается в man lvm.

А как ты файл объемом стопицот гигов обслуживаешь? Тряпочкой протираешь два раза в неделю? :)

у меня таких нет. Максимум, под логи, есть 100 гиг. Обычный размер - 20/40/60 гиг. Я хотел бы понять как выглядит работа с lvm вариантом. Как, например, мне подготовить болванку на рабочем хосте, распространить её по целевым хостам, привести её там в соответствие, сделать локальную резервную копию. Вы же не занимаетесь установкой каждой виртуалки с нуля прямо на месте, правда? Как всё это выглядит в варианте с файлами, мне понятно. А как это будет при чистом lvm, без ФС?

ну вот примеры раскатывания виртуалок на zvol

Очередной тред выбора бакапов (комментарий)

qcow2 верхом на zvol для kvm без кеша.

бекап виртуалок и их шаблоны

qcow2 верхом на zvol для kvm без кеша. (комментарий)

спасибо

в случае с лвм виртуалки напрямую используют в качестве блочных устройств логические тома, сделать их копию можно с помощью снапшота, который зафиксирует состояние тома на время, при этом перемещая старые данные (подвергшиеся изменению) в тело снапа, в это время можно сделать копию тома используя dd или cat или pv и т.п.

мне всегда было интересно, а как СУБД переносят снятие снапшота с действующей машины? Там с этим всё нормально?

нет не нормально, БД надо глушить перед снапом, либо делать дамп а следом снап.

тогда я вообще не вижу никакой разницы от «погасить виртуалку и сделать копию файла образа». Один хрен же надо СУБД гасить. А дамп без разницы откуда снимать.

Не надо ничего гасить, правильные СУБД без проблем переносят падение (а запуск ВМ из снапшота аналогичен падению). Для лучшей консистентности перед созданием снапшота СУБД блокируют на запись, а после - разблокируют.

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

Я не против исследования и внедрения чего-то нового, но мне надо понять целесообразность подобного действия. Конечно, я поиграюсь на стендовой машинке, пяток свободных дисков есть. Сейчас же я пытаюсь ответить на вопрос «как оно может выглядеть вцелом», общую картину. Вот сейчас я понимаю, что снапшот машины, как таковой, особого смысла для меня не имеет, раз нет гарантии целостности БД.

Хорошо, вернемся к lvm и созданию/распространению болванок. Из вышесказанного я понимаю, что на целевых машинах всё-таки потребуется ФС достаточного размера для приёма временного файла, который на месте будет уже развёрнут в объём lvm. Это так?

Хорошо, вернемся к lvm и созданию/распространению болванок. Из вышесказанного я понимаю, что на целевых машинах всё-таки потребуется ФС достаточного размера для приёма временного файла, который на месте будет уже развёрнут в объём lvm. Это так?

Не совсем... вобще, в качестве диска для машины можно использовать и снапшот lvm. при этом место будет тратиться под разницу между томом и изменениями в снапшоте... но производительность снизится

и да... злоупотреблять этим не следует

В моём случае блокировка СУБД на критичной машине на запись равносильна остановке процессов торговой системы.

Это на пару секунд всего, пока не сделается снапшот. Настолько критично? Тогда странно что это крутится внутри ВМ.

Хорошо, вернемся к lvm

Никто не мешает разливать в лвм сразу из сети, типа:

host1# cat img.bin | nc 1.1.1.1 1111
host2# nc -l -p 1111 > /dev/mapper/vg-...

Тогда странно что это крутится внутри ВМ.

а какая разница? Виртуализация надежность разве снижает?

Никто не мешает разливать в лвм сразу из сети, типа:
host1# cat img.bin

то есть, ФС всё-таки нужна? Ведь img.bin лежит на ФС?

а какая разница? Виртуализация надежность разве снижает?

виртуализация снижает надёжность, строго говоря. она добавляет сверху ещё одно ядро гипервизора, которое может упасть. и она снижает производительность и повышает латентность.

то есть, ФС всё-таки нужна? Ведь img.bin лежит на ФС?

img.bin лежит там, где ты его готовишь. никто не мешает тебе готовить ВМ в лвм и переливать из лвм в лвм напрямую через сеть. тогда фс не нужна.

Переносят, точно так же, как жёсткую перезагрузку. Не больше, не меньше. То есть, в 99 процентах, перенесут - адекватно, если нагрузка не очень большая по записи.