QEMU. устройство хранения block vs file.

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

Зачем нужна стадия ресурсоёмкого и длительного копирования? Вызов qemu-img resize на qcow2 образах занимает жалкие доли секунды.

Сходу я не могу придумать таких задач. Я в проде не вижу примеров удобного применения qcow2 по сравнению с lvm.

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

ресурсоёмкое и длительное копирование

копирование чего куда? blockresize отрабатывает мгновенно, qemu-img тоже, там же ничего не делается

про qcow2 с пеной у рта кричит: - «ЗАБУДЬТЕ…!!! Это прошлый век

может так быть, что он дурачок просто. кроме снапшотов для собственно версионирования и кейса с множеством машин который я выше объяснил у virsh есть еще и механизм консистентного бекапа без остановки машины и он тоже на qcow2 опирается. делать вот это вот всё через таблицу разделов lvm - это тупизм.

Для того, чтобы использовать qemu-img resize, нужно выключить гостя. Чтобы это обойти, надо сделать копию образа, увеличить его размер, потом подсунуть этот новый файл гостю.

В случае с lvm я просто увеличиваю том.

В обоих случаях в конце, нужно virsh'ем пнуть гостя, чтобы он перечитал диск с новым размером.

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

Но раз всё равно для расширения вживую нужно в virsh лезть, нельзя что ли там же просто blockresize сделать?

Я не спец, а так. Но почему raw приравнивается к блочному устройству? Он может просто файлом валятся обычным, у меня вот так и есть, три qcow2 виртуалки, ну тупо потому что менять размеры можно вжух и всё, две raw виртуалки, потому что могут просто взять dd и накатить этот образ на реальный диск и всё сразу будет работать в железе, очень просто и удобно. И ещё раздел на диске, я запускаю виртулку с ним в ней накатываю что угодно и ребутаюсь на этот раздел, ну если надо что проверить с qcow2 такой финт ушами не прокатит, а тут вуаля и готово, оч удобно. Так что мне кажется тут зря «прошлый век» прочие речи, это просто абсолютно разные типы хранения виртулок, для разного и существуют и друг друга не заменяют (полностью) А вот про скорости, ну чисто в теории если qemu работает напрямую с диском как с raw файлом, то должно быть быстрее. Но опять же в терии может быть медленее так как в таком случае хрен его знает как будет работать DMA (я до сих пор не разобрался как оно работает в реальности, физически и в каких случаях) может когда работа идёт поверх EXT4 системы например оно умеет на DMA перебрасывать работу, а когда qemu работает с диском как с файлом то такого не происходит (ну типа так да?).

А вообще, я запутался кажется… :( Тут надо тупо залезть в код и посмотреть, ага, если вот так то у нас это, то и вот это, а если сяк то будет так, сяк и эдак и всё. Но эт надо сидеть и корпеть, а ещё и всякие случаи учитывать, когда в одних условиях будет сяк, а в других эдак. Но тут хоть понимание будет, чево, куда да как.

Но вот что точно бред это орать про «прошлый век», не прошлый и не век, а просто разное предназначение, хотя если без изысков и требований ваще без разницы что использовать.

Причём с явным хаком в виде подмены файла и потенциальными проблемами от расхождения оригинала

Он нужен был только для qcow2. Для lvm - такой необходимости нет.

нельзя что ли там же просто blockresize сделать?

Сейчас уже не помню. Врать не буду. Я последний раз в проде сталкивался с qcow2 на большом количестве виртуалок лет пять назад. И примерно тогда же на личном железе перешёл окончательно на lvm.

в qcow2 несколько проще создавать snapshot’ы и создавать клоны на основе базового образа

Но и то и другое делается через layering и (как минимум раньше) работало по принципу VMDK - оригинальный образ становится «снапшотом» а новый слой объявляется «текущим стейтом».

После этого все изменения пишутся в новый слой. И эта схема всегда на обе ноги хромала при «удалении снапшота» когда надо перенести старые блоки в новый слой и только потом удалить изначальный образ который «снапшот».

P.S.: да и сейчас оно работает так же - https://wiki.qemu.org/Documentation/CreateSnapshot

Не надо там ничего «исследовать» - всё «исследовано» до вас. У кукухи (тонкой не преаллоцированной) есть метаданные которые при записи ренее незаписанных блоков нужно менять.

Поэтому если у тебя идет регулярная запись новых данных, а не переписывание ранее записанных, то кукуха соответственно кратно проседает. Плюс к этому есть еще проблема flush/sync, когда одна ВМ которая начинает стрелять flush’ами аффектит остальные, особенно под нагрузкой (там много операций надо прокатить через журнал ФС). И еще есть проблема с тем, что сброс кэшей производится не в том порядке в каком данные писались, и некоторые «особо оптимизированные» приложения с этого внезапно офигевают.

А вот если у тебя LVM, да формат raw, и cache=none, да еще и io=native (с сопутствующим O_DIRECT), то флаши просто превращаются в дрейнинг очереди, и эффект о синков замечают только те кто в параллель в кучу потоков без синка пишет.

А еще особым разделом специальной олимпиады является миграция ВМ чьи диски лежат в qcow на локальной ФС (хотя и с LVM оно тоже входит в набор достаточно упоротых процедур).

В том же опенстеке например самым быстрым универсиальным диском по факту является LVM предоставляемый на гипервизоры по iSCSI. ВМ с такими дисками мигрируют без прерывания активности - сначала мигрируют ВМ потом устраивают storage live migration (да, я знаю что это «не облачно» но тем не менее клиент часто хочет)

С qcow такой финт ушами без остановки/фриза ВМ не сделать.

Сходу я не могу придумать таких задач.

Но это не значит, что их нет.

Но я не уверен, что на локалхосте у меня будут такие задачи, где это перевесит удобство управления.

В чем удобство управления выражаются?

В обоих случаях в конце, нужно virsh'ем пнуть гостя, чтобы он перечитал диск с новым размером.

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

В чем удобство управления выражаются?

На этот вопрос могу только рекомендовать ознакомиться с документацией.

Это за полминуты делает второй плейбук, который уже отрабатывает на гостях. И это как раз жалкие копейки по сравнению с ребутом.

Но это не значит, что их нет.

Ты у меня спросил по поводу таких задач, хотя изначально про это говорил не я. Зачем мне на лету выдумывать что-то? Я не исключаю, что можно найти способы применения, но я таковых не вижу пока. Точнее, теоретически, придумал один. Мне приходилось несколько лет назад работать в одной конторе, где была своя низкоуровневая распределённая файловая система со своими особенностями и все хранилища, включая служебные, работали под ней. Использовать там lvm было физически невозможно. И в теории, если бы там нужно было бы поднимать служебные виртуалки, то диски для них можно было бы использовать только в виде файлов - qcow2/raw. Но это теория.

А вот когда я выше рассказывал про ресайз, про невозможность или крайнюю нежелательность ребута гостей, про плейбуки - это реальный пример из реальной практики. И реализовано это всё было не на локалхосте, а для управления тысячами виртуальных машин на сотнях серверов в трёх датацентрах. И это только в одном отделе, в котором работал я. Другие отделы компании так же использовали этот же механизм и сколько у них было вм - я уже не знаю, но сильно больше.

Именно поэтому я и говорю, что lvm удобнее. Из практики. И именно поэтому я изначально спросил у тебя, что такого плохого для конечного пользователя в использовании lvm в качестве дисков виртуальных машин. В моём случае непосредственными пользователями были программисты и админы компании, которым предоставлялись запущенные на этих машинах сервисы. А конечными пользователями - обычные люди, клиенты компании. Ни первые, ни вторые не в курсе даже про сам факт использования именно qemu-kvm, не говоря уже про то, каким образом там создаётся диск. Вот меня и удивило твоё замечание про «пользование поделием, требующим LVM».

Раньше я использовал qcow2, а сейчас стал использовать raw (файл на ext4 с дырками) или пробрасывать диск целиком.

    '-blockdev node-name=DISK01,driver=raw,file.driver=host_device,file.filename=/dev/disk/by-id/ata-WDC_WD141KRYZ-01C66B0_9LGHJH0G,read-only=on'
    '-device virtio-blk-pci,drive=DISK01'

На этот вопрос могу только рекомендовать ознакомиться с документацией.

Какой именно документацией?

А внутри гостя и разметочку диска поправить и форматнуть... >>вобщем выключение гостя на фоне этого жалкие копейки по времени.

Это за полминуты делает второй плейбук, который уже отрабатывает на гостях. И это как раз жалкие копейки по сравнению с ребутом.

Вы случайно не военный?

Использовать там lvm было физически невозможно. И в теории, если бы там нужно было бы поднимать служебные виртуалки, то диски для них можно было бы использовать только в виде файлов - qcow2/raw. Но это теория.

Вот видите, вы уже начинаете прозревать. Представьте что у вас есть сервер на котором физически возможно использовать lvm, но он расположен далеко, админов рядом с ним нет, есть только один пользователь который не в любой рабочий день может оказаться в серверной. Для того что бы перегнать его на lvm надо его остановить, слить с него усё, переразбить, залить обратно, не ошибиться в процессе... И вот это всё делать возможно только в рабочее время силами пользователя который по вашим командам будет нажимать кнопочки стоя в холодной шумной серверной. И который не в любой рабочий день может оказаться в серверной.
И вот это вот всё, надо:
1. Предварительно согласовать с руководством заказчика, так как это время простоя и отвлечение пользователя от его работы.
2. Оповестить всех пользователей, что в день X сервак работать не будет. См. пункт 1 про время простоя.
И с оповещением пользователей не всё так просто, надо не то что в односторонеем порядке сказать, что в день D работать не будет и не имеет, возможны нюансы и именно в запланированный вами день делать это крайне не желательно. Т.е. начинаем всё сначала, выбираем другой день, опять обзваниваем пользователей...
И вот это всё только для эфемерного дальнейшего удобства Вашей! работы. Боюсь что заказчик если ему рассказать всю правду, не одобрит такой цирк.
ЗЫ Это я описал только один из... вариантов, но он не единственный, в других случаях более другие заморочки, но все они заканчиваются на вопросе от заказчика «Что бы что?».

Кто юзает qemu, поделитесь опытом

zvol )

Опыт реального продакшена(тысячи VM):

1. Был у нас qcow2, перешли на LVM
2. Огребли кучу проблем. Например, раньше на hdd-дисках, после рестарта гипера VMки без проблем запускались. Теперь нет, т.к. кеширование(один раз вычитывался базовый образ vs прочитать его 200(по количеству стартующих VM) раз).
3. Аналогично, раньше массовое создание VM создавало меньшую нагрузку. (А подтупливания по IO плохо сказываются на соседях).

В итоге перешли на ssd, но это костыль. В реальном проде IO VMок и так ограничено, соотв. в прибавке к производительности плюс несколько процентов нет никакого смысла, а кейсов где qcow2 выигрывает прямое блочное устройство - множество. Не удивлен, что в замерах автора qcow2 в 8 раз быстрее блочного устройства по той же причине. И то что замеры «некорректные» - не важно, это всё равно пример «рабочей нагрузки» где скорость реально выше из за кеширования под капотом.

Вот видите, вы уже начинаете прозревать.

Нет. Я на лету попытался притянуть за уши хоть какой-нибудь вариант. Так сказать, встал на сторону оппонента.

Представьте что у вас есть сервер на котором физически возможно использовать lvm, но он расположен далеко, админов рядом с ним нет, есть только один пользователь который не в любой рабочий день может оказаться в серверной.

К счастью, я не работаю с такими системами уже много лет. Есть ipmi/ip-kvm в датацентрах. Сотрудники датацентров или же админы организации обладают достаточными навыками. Впрочем, ранее, лет десять(а то и больше) назад, мне приходилось удалённо по ssh на живой системе переводить её с обычных разделов на mdadm-рейд. Думаю, что провернуть подобное с lvm тоже реально.

Нет, неунывающий DevOps-инженер. :)

Впрочем, ранее, лет десять(а то и больше) назад, мне приходилось удалённо по ssh на живой системе переводить её с обычных разделов на mdadm-рейд. Думаю, что провернуть подобное с lvm тоже реально.
мне приходилось удалённо по ssh на живой системе переводить её с обычных разделов на mdadm-рейд.

Без копирования?

С копированием.

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

Ну это стандартная схема. А то я подумал что прям совсем на живой, без всякого копирования и тем более перетыкания железа и используя только ssh. А так как у вас было большинство не сильно альтернативно одаренных осилят, я такое тоже делал.

А если у тебя еще и XFS с reflinks, то по сути получается почти как LVM, только на файловой системе :-)

где скорость реально выше из за кеширования под капотом

То есть, вы не осилили io=threads cache=writeback, но плохой LVM? Интересная логика. Достойная LORа

LVM хороший, а вот архитектура хостинга где VM на LVM - имеет свои нюансы и её выгода не очевидна ;)

В общем подождав пару дней, почитав мнение каждого и срач в комментах сделал вывод, что оставлю оба варианта (есть 2 железяки для этого) и файлы и блоки. Буду играться с cache, io, что-то проэкспериментирую с хабра, ну и ещё раз на досуге перечитаю исчерпывающее. Спасибо всем огромное за ответы. Ваше мнение и опыт я принял к сведению (и на грудь тоже) =)