LINUX.ORG.RU
ФорумAdmin

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

 , , ,


3

1

Всю жЫсть использовал для дисков формат qcow2. В xml’е секция под это выглядит вот так

<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2'/>
  <source file='/kvm/images/vm.qcow2'/>
  <target dev='vda' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</disk>

В ТГ наткнулся на канал, в котором чувак (препод в одной из госконтор) упорото топит во-первых за разметку хоста - lvm (у меня RAID-1), во-вторых диски ВМ он создаёт тоже lvm lvcreate -n vm -L16G vg (некий бутер из lvm получается) и его секция в конфиге выглядит так

<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none' io='native'/>
  <source dev='/dev/ssd/vm' index='2'/>
  <backingStore/>
  <target dev='vda' bus='virtio'/>
  <alias name='virtio-disk0'/>
  <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
</disk>

а про qcow2 с пеной у рта кричит: - «ЗАБУДЬТЕ…!!! Это прошлый век. Использование хранилок блочными в сто раз быстрее, чем файлами».

В общем я замерил. Файлом у меня скорость чтение/запись примерно в 8 раз быстрее, чем блоком.
Кто юзает qemu, поделитесь опытом, как всё-таки лучше будет юзать диски под ВМ.

P.S> Лев, если ты это читаешь - сорян. Я хочу выяснить у местного бомонда действительно ли ты прав в своей теории…=)

★★

Зависит от характера нагрузки. Для Баз давнных - raw будет всегда лучше, чем файлы.

qcow2 - это контейнер, внутри которого поднято «виртуальное блочное хранилище». И в случае, если qcow2 создается сразу полного размера, и занимает на жестком диске НЕПРЕРЫВНУЮ последовательность блоков (а для файловых систем это редкое явление)… то скорость чтение/записи будет более менее идентичной. В остальных случаях - будет уступать блочным методам хранения. При работе с qcow2 также следует четко помнить о том, что любое обращение к данным будет идти по цепочке:

вирт.машина — qemu — qcow2(вирт. блок) — файловая система хоста — данные в хранилище.

При работе с блочным устройством, цепочка получается короче:

вирт.машина — qemu — блочное устройство.

tsvbrest
()
Ответ на: комментарий от Shprot

Хм… Замерять скорости изнутри виртуальных машин - не очень корректно. Там ведь и время может быть… виртуальным…

По опыту эксплуатации, блочное хранение - всегда быстрее. Особенно, если ВМ интенсивно работает с вводом/выводом.

Разумеется, что доступ к блочному хранилищу должен быть нормально настроен… В отличие от файловых систем, операции чтения/записи блочного хранилища не кешируется в ОЗУ хоста…

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

tsvbrest
()

Блочное будет быстрей. qcow нужен для своих фич. Но про разницу в 8 раз не верю. Думаю и в 2 раза не будет. Поэтому по дефолту qcow.

Я бы так сказал. Для рута - qcow. А для данных, если там внутри бд — raw.

С lvm надо быть аккуратным.

vbr ★★★★
()
Ответ на: комментарий от firkax

Насчет LVM - Это глубоко дискуссионный вопрос. LVM сильно облегчает жизнь в плане расширения, изменения «размеров диска» и т. д. К тому же… Если вам нужно будет поднимать надцать образов ВМ на разных хостах, с разными контроллерами и т.д. LVM очень сильно облегчает жизнь, за счет «маскировки» конкретных особенностей физического хоста. (Скажем /dev/sd, /dev/hd уже способны выпить много крови при автоматических разворачиваниях) и т.д. В общем, LVM - не панацея, и не всегда нужна, но часто облегчает жизнь неунывающего DevOps….

tsvbrest
()

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

Khnazile ★★★★★
()
Ответ на: комментарий от firkax

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

Как говорится - все дело именно в этой прослойке

tsvbrest
()
Ответ на: комментарий от vbr

В случае, если на хосте много оперативной памяти, и работает только одна виртуалка - то вполне мог такие цифры получить.

Это связано с файловым кешем хоста. тот же ext4 весьма агрессивно использует ОЗУ для кеширования операций чтения/записи. т.е. по сути была измерена скорость работы с кешем. Но не следует забывать, что в этом случае:

  1. Виртуалка считает, что она сохранила данные на диск… А физически этого не произошло. И произойдет через весьма ощутимый промежуток времени… В течении которого, любой сбой повлечет утерю этих самых данных.

  2. Если виртуалок будет много - тогда кеш будет только мешать… ибо qcow2 начнут неявно (на уровне файловой системы) конкурировать за него… И тут результат может быть весьма разнообразным.

tsvbrest
()
Ответ на: комментарий от Shprot

cache=‘unsafe’ т.е. кешировать блочный ввод/вывод. Ускорение за счет ОЗУ хоста. Но в случае чего - потеря данных, которые хост не успел записать на диск. поэтому и unsafe

Ибо виртуалка будет думать, что у нее все ок и записано, а на самом деле - все не совсем так…

tsvbrest
()
Ответ на: комментарий от Shprot

cache=‘unsafe’ - это небезопасный кеш, операции записи будут выполнятся без flush, производительность внутри VM становится запредельной.

Bloody ★★
()
Последнее исправление: Bloody (всего исправлений: 1)

Это прошлый век

Скорее, наоборот. Блочные устройства были задолго до qemu и qcow2

Но это не значит, что qcow2 лучше. Он другой и у него свои задачи

  1. как уже сказали, qcow2 (как и любые другие файлы) будет работать через файловую систему хост системы. Это лишняя фрагментация, и чуть большее время доступа, и более высокое влияние одних гостей на других

  2. qcow2 использует thin provision (диск будет создан почти нулевого размера, а потом будет расти по мере заполнения, до заданного размера)

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

  4. в случае повреждения диска тебе может быть существенно (иногда - на порядки, особенно если диск накрылся во время роста thin privision диска) сложнее восстановить данные с qcow2

Использование хранилок блочными в сто раз быстрее, чем файлами».

Да, но

  • далеко не в сто раз
  • заметить разницу ты сможешь только на hdd, т.к. на ssd сильная фрагментация будет гораздо меньше заметна, и увидишь только под высокими нагрузками и в основном при записи

ИМХО

  • Если ожидаются высокие нагрузки, лучше взять блочное устройство
  • Если речь о домашней лабе, не хранящей важные данные, да ещё и на nvme, гораздо удобнее будет создать qcow2 и пользоваться его преимуществами
router ★★★★★
()
Ответ на: комментарий от firkax

Я всегда говорил что LVM ненужно.

Случай, блин. Ты или админ локалхоста, или учился работе с компами давным давно и с тех пор закостенел и превратился в энта

lvm уже лет 15 - мейнстрим. То, что ты его до сих пор не осилил, не говорит о тебе ничего хорошего

З.Ы. Рекомендую ознакомится с любым актуальным курсом по линуксу. redhat, lpi, да хоть даже астра

З.З.Ы. виндузятник, что ли? Вроде только у них lvm не прижился

router ★★★★★
()
Последнее исправление: router (всего исправлений: 2)

IBM-овцы в своё время в обзоре рекомендовали .qed. От .qcow2 по формату отличается только отсутствием снепшотов. Зато производительность как у .raw. Т.е. .qed как бы взял лучшее от обоих.

Хотя, формально, поддержка .qed от проекта Qemu давно закончилась, но там по факту просто нечего улучшать, всё просто работает. Во всяком случае, драйвер .qed они пока не отключили.

anonymous
()
Ответ на: комментарий от router

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

firkax ★★★★★
()
Ответ на: комментарий от anonymous

.qed. От .qcow2 по формату отличается только отсутствием снепшотов. Зато производительность как у .raw.

Так снапшоты это единственная фича qcow2 по сравнению с raw, никаких других причин его использовать нет.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Столь не любимый вами LVM, тем не менее, часто выручает в тех ситуациях, когда нужно сделать бэкап той-же базы данных… КОторую нельзя на долго выводить из эксплуатации…. Типа включить в базе режим бэкапа, сбросить все буфера на диск, сдалать snapshot, вернуть базу в нормальный режим работы…

Сделать бэкап snapshot… Удалить snapshot

https://tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html

и не только для виртуалки. 8)

tsvbrest
()
Ответ на: комментарий от router

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

лишняя фрагментация, и чуть большее время доступа

трудно судить насколько значима там может быть дополнительная фрагментация. насколько помню, там достаточно большие страницы. кроме того фрагментация всё равно есть - у гостя, да и на ssd это менее заметно уже. тормоза возможно до какой-то степени объясняются с работой на свежем (пустом) qcow2, потому что расширение файла (любого) имеет какую-то цену.

asdpm
()
Ответ на: комментарий от tsvbrest

В общем, LVM - не панацея, и не всегда нужна, но часто облегчает жизнь неунывающего DevOps….

Видите, она «облегчает жизнь неунывающего DevOps», но не того кто будет этим пользоваться.

anc ★★★★★
()
Ответ на: комментарий от greenman

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

firkax ★★★★★
()
Ответ на: комментарий от anc

Видите, она «облегчает жизнь неунывающего DevOps», но не того кто будет этим пользоваться.

С трудом представляю себе ситуацию, когда к продакшен-системе подпускают человека без знания основ. LVM — это уровень эникея.

anonymous
()
Ответ на: комментарий от anonymous

Видите, она «облегчает жизнь неунывающего DevOps», но не того кто будет этим пользоваться.

С трудом представляю себе ситуацию, когда к продакшен-системе подпускают человека без знания основ. LVM — это уровень эникея.

А причем здесь знания или другие умения?

anc ★★★★★
()
Ответ на: комментарий от firkax

и вводит в заблуждение касательно того, сколько ещё места на физическом диске можно занять.

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

Потому как занимать больше чем выделено в сумме всем виртуалкам всё равно нельзя - чревато отказом если они туда неожиданно зальют несжимаемые блоки.

Можно. К сжимаемым или несжимаемым блокам это не имеет отношения. Постой пример, у вас файл сервер, на него внезапно залили дофига всего и место закончилось, какая разница почему оно закончилось? На текущий момент оно просто закончилось.
Другой пример, вы создали какой-то очень большой файл, сам образ расширился, но потом вы его удалили. Со стороны хост системы занято много, со стороны гостя немного. Т.е. повода паниковать нет, это была разовая акция и для хост системы ничего плохого не случилось.

anc ★★★★★
()
Ответ на: комментарий от anonymous

С трудом представляю себе ситуацию, когда к продакшен-системе подпускают человека без знания основ. LVM — это уровень эникея.

Я писал про тех кто будет пользоваться, а не обслуживать.

anc ★★★★★
()

Разумеется, блочным устройство лучше. Нет двойной работы, как минимум. А уж фризы при росте файла qcow2 - так это моё почтение. Можно, конечно, создать его сразу в полном объёме, но двойная работа всё равно никуда не денется.

А, да, вот ещё что. Вот лежат у тебя образа на ФС. Портится ФС и ты теряешь все свои виртуалки, да?

targitaj ★★★★★
()
Ответ на: комментарий от anc

Ну я неунывающий DevOps, использую qemu с дисками на lvm, пользователи виртуальных машин даже не догадываются о том, через какую подсистему в госте работает диск. Они иногда приходят с просьбой увеличить диск, я запускаю ansible, который идёт по хостам и его расширяет. Да. с qcow бы делал так же, но вместо одной команды в плейбуке, было бы три, одна из которых очень ресурсоёмкое и длительное копирование.

Если вдруг, я ударюсь головой и мне захочется поменять настройки VM, я всегда могу взять qemu-img convert и сделать из lvm qcow2, но я не могу пока придумать реальных кейсов для этого. И всё-равно пользователь в гостевой ОС разницу не увидит(кроме очевидной просадки по скорости с qcow2, о которой уже тут в треде говорили).

shell-script ★★★★★
()
Ответ на: комментарий от router

Только избранное, что бы было понятно.

Но это не значит, что qcow2 лучше. Он другой и у него свои задачи

И

lvm уже лет 15 - мейнстрим. То, что ты его до сих пор не осилил, не говорит о тебе ничего хорошего

Сначала вы признаете право на использование qcow2, но потом люто топите за lvm.

anc ★★★★★
()
Ответ на: комментарий от tsvbrest

Виртуалка считает, что она сохранила данные на диск… А физически этого не произошло

Такое произойдёт только если специально выставлен режим кеширования unsafe. Тогда ОС в виртуалке никак не может заставить хост скинуть данные на накопитель. В режимах writethrough и directsync виртуалка получит уведомления о записи, когда данные реально будут записаны. В режиме writeback уведомление о записи будет выдано сразу, но у ОС в виртуалке будет возможность затребовать сброс данных на накопитель.

i-rinat ★★★★★
()