LINUX.ORG.RU
решено ФорумAdmin

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

 , , ,


6

7

По мотивам данной темы - zol , не всё так хорошо... (комментарий) решил поизвращаться и накатить виртуалку (kvm) на формат qcow2, который в свою очередь будет натянут поверх тома zvol, чтобы иметь двухуровневую возможность снятия снапшотов виртуалки (снапшоты на уровне qcow и на уровне zfs).

процесс настройки:

создаем зеркальный пул:

zpool create -f -o ashift=12 kvmpool /dev/sdg /dev/sde

настройки пула:

zfs set compression=on kvmpool
zfs set primarycache=all kvmpool
zfs set atime=off kvmpool
zfs set dedup=off kvmpool
zfs set compression=lz4 kvmpool

создаем блочное устройство под виртуалку (том zvol):

zfs create -s -V 10g kvmpool/zvol1 -o volblocksize=128k

накатываем формат qcow2 на полученный виртуальный диск (напоминаю используем блочное устройство, а не имидж-файл)

qemu-img create -f qcow2 /dev/zvol/kvmpool/zvol1 8G
здесь умышленно не отдаю весь диск под qcow2.

далее ставлю виртуалку:

virt-install -n vm-qcow2 -r 1024 --vcpus=1 --disk path=/dev/zvol/kvmpool/zvol1,format=qcow2,bus=virtio,cache=none --vnc --os-type linux --accelerate --network=bridge:br0,model=virtio --hvm --disk path=debian-7.4.0-amd64-CD-1.iso,device=cdrom,perms=ro --vncport=5912 --force

все удачно установилось. смотрю сколько виртуалка отожрала у массива:

zfs list
NAME            USED  AVAIL  REFER  MOUNTPOINT
kvmpool         642M  14,3G   136K  /kvmpool
kvmpool/zvol1   641M  14,3G   641M  -
всего 641M скушал девственный дебиан.

запускаю virt-manager и вижу странность, он показывает, что под виртуалку отдан диск формата qcow2 размером 10G, хотя под qcow давалось лишь часть в 8G, fdisk в самой виртуалке показывает честные 8G, почему это так? и еще насоветуйте GUI для создания снапшотов виртуалок посредством qcow2, как я понимаю в моем virt-manager (версия 0.9.1) такой возможности нет?

подпишусь, интересно

dvrts ★★★ ()

и еще насоветуйте GUI для создания снапшотов виртуалок посредством qcow2

гуя я не видел, а снапшот создается так:
qemu-img create -f qcow2 -b centos-cleaninstall.img snapshot.img
тыц

dada ★★★★★ ()

чтобы иметь двухуровневую возможность снятия снапшотов виртуалки

этот функционал тебе не понадобится. все равно будешь использовать только один снапшот.

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

qemu-img create -f qcow2 -b centos-cleaninstall.img snapshot.img

да это понятно, интересует именно морда, для уровня эникейщика.

этот функционал тебе не понадобится. все равно будешь использовать только один снапшот.

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

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

и еще насоветуйте GUI для создания снапшотов виртуалок посредством qcow2, как я понимаю в моем virt-manager (версия 0.9.1) такой возможности нет?

Через virt-manager, я создаю снепшоты в версии 1.1.0. Если используешь qcow2, то можно делать даже их в он лайн, но... Он всю оперативу загоняет в снепшот, и всё это время машина простаивает... То есть фриз. - В общем сомнительное удовольствие. Хотя - да, консиснент, какой-никакой. Ну и в офлайн снепшоты - создаются быстро, и гладко.

мне нужно чтобы другие юзеры могли делать снапшот на уровне qcow2

Для этого, я через ansible накатываю хост системы для kvm, а потом одним кликом мышки, я добавляю целый узел в webvirtmgr, и пользователь сможет выключить машинку, сделать от неё снепшот, и откатиться тоже сможет. К сожалению, webvirtmgr, имеет по дефолту некоторые проблемы с html5 просмоторщиком мониторов машин, я написал им на багтреккер, они мне подсказали воркарраунд. - Короче, программа не идеальная, и не имеет полноценного ACL, хотя к LDAP, я её без особого труда прикрутил, и аутентификацию по группе оно умеет! - В целом, как решение для нищеброда получается, довольно годным, с тем учётом, что можно рулить происходящим внутри вм, прям с браузера, и без установки доп. софта + LDAP можно цеплять.

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

Ах и да... - Не помню, ты мне втолковывал, про RAID-10, или нет, на zfs, но я попробовал - штука весьма годная выходит, в плане скорости! В образе qcow2, на диск 10к моя база поднималась 20 часов, на диске WD enterprice 7200k - 24 часа, сейчас сотворил RAID-10, из моих любимых гринов+добавил два энтерпрайзных диска wd- короче четыре диска всего 1+0 или как там его... В общем, моя любимая база, развернулась на этом творчестве за 12 часов!

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

ты мне втолковывал, про RAID-10

да, причем не раз. У меня все БД только на RAID-10.

Через virt-manager, я создаю снепшоты в версии 1.1.0

ясно, значит у меня просто протухшая версия.

axelroot ()

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

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

Делаем снапшот нашей виртуалки

zfs snapshot kvmpool/zvol1@`date --rfc-3339=date`
бекап виртуалки можно записать только с полного снапшота (т.е. когда снапшот является единственным для zvol использующегося в качестве диска виртуалки). Посмотрим какие снапшоты у нас в наличии:
zfs list -t snapshot
NAME                       USED  AVAIL  REFER  MOUNTPOINT
kvmpool/zvol1@2015-03-18      0      -   651M  -

видим, что для тома zvol1 у нас единственный снапшот (т.е. он полный). Итак делаем бэкап виртуалки, который будет записан в файл и смотрим сколько времени это у нас займет:

time zfs send kvmpool/zvol1@2015-03-18  > /home/zvol1.backup

real	0m28.381s
user	0m0.000s
sys	0m0.072s

Таким образом мы получили бэкап виртуалки записанный в файл zvol1.backup всего за 28 секунд.

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

Т.к. на данный момент диск забэкапленной виртуалки у нас существует, давайте его переименуем, а для этого нужно удалить его снапшот. Удаляем снапшот:

zfs destroy  kvmpool/zvol1@2015-03-18
Останавливаем виртуалку и переименовываем диск(он мне просто понадобится для другой виртуалки)
zfs rename -f kvmpool/zvol1 kvmpool/zvol001
Смотрим что получилось
zfs list
NAME              USED  AVAIL  REFER  MOUNTPOINT
kvmpool           652M  14,3G   136K  /kvmpool
kvmpool/zvol001   651M  14,3G   651M  -
Ну вот теперь мы можем восстановить диск нашей виртуалки из бэкапа - zvol1.backup и замерить требующееся для этого время:
time cat /home/zvol1.backup | zfs receive -vdF kvmpool
receiving full stream of kvmpool/zvol1@2015-03-18 into kvmpool/zvol1@2015-03-18
received 1,27GB stream in 80 seconds (16,2MB/sec)

real	1m19.662s
user	0m0.016s
sys	0m1.568s

Как мы видим для развертывания виртуалки из бекапа потребовалось всего-то 79 секунд. А полученный файл zvol1.backup можно использовать как шаблон (template) при создании новых виртуалок.

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

получили бэкап виртуалки записанный в файл zvol1.backup всего за 28 секунд.
всего за 28 секунд.

651МB/28s = 23MB/s  — это скорость? Это говно, а не скорость!

(16,2MB/sec)

Ты на флешке эксперименты проводишь? Что ты хочешь всем этим сказать?

anonymous ()

При желании получаемые бэкапы виртуалок можно поджать

time zfs send kvmpool/zvol1@2015-03-18 | gzip -9 > /home/zvol1.backup.gz 

real	4m39.882s
user	4m19.660s
sys	0m1.160s

ls -lh /home/zvol1.backup.gz
-rw-r--r-- 1 root root 476M Мар 18 11:18 /home/zvol1.backup.gz
Реанимируется виртуалка из бэкапа так:
zcat /home/zvol1.backup.gz | zfs receive -vdF kvmpool

И по аналогии, но теперь только с xz

time zfs send kvmpool/zvol1@2015-03-18 | xz -z9c -T4 > /home/zvol1.backup.xz

real	12m37.614s
user	12m8.986s
sys	0m2.508s

ls -lh /home/zvol1.backup.xz
-rw-r--r-- 1 root root 316M Мар 18 11:40 /home/zvol1.backup.xz

Восстановление из бэкапа:

xzcat /home/zvol1.backup.xz | zfs receive -vdF kvmpool
axelroot ()
Ответ на: комментарий от axelroot

Эта тема о qcow2 или о zfs? Вижу только команды zfs. Ты сюда весь man zfs перепишешь?

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

Ты на флешке эксперименты проводишь?

на старых убитых ноутбучных дисках, все что было под рукой.

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

Кто бы сомневался. Без zfs-срача скучаешь, больше ничего тебе не интересно, фанатики такие фанатики.

anonymous ()

Ну а теперь сделаем бэкап виртуалки используя qcow2 натянутый на zvol

Делаем снапшот диска виртуалки

qemu-img snapshot -c snap1 /dev/zvol/kvmpool/zvol1

А теперь запишим бэкап виртуалки в файл используя снапшот от qcow2 и посмотрим сколько это займет времени:

time qemu-img convert -f qcow2 -O qcow2 -s snap1 /dev/zvol/kvmpool/zvol1 /home/zvol1.qcow

real	0m42.448s
user	0m1.464s
sys	0m1.604s

ls -lh /home/zvol1.qcow
-rw-r--r-- 1 root root 1,3G Мар 18 12:24 /home/zvol1.qcow

Как мы видим для создания бэкапа потребовалось 42 секунды, это в полтора раза дольше, чем бэкап от zfs.

axelroot ()

Ответа почему virt-manager врет о размере qcow2 диска так и не нашел.

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

Тебе не кажется что при использовании qcow2, zfs как бы не нужен?

P.S. Ты мог сделать external snapshot и не конвертировать внутренний снапшот в файл.

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

651МB/28s = 23MB/s — это скорость?

651МB - это в жатом состоянии на zfs, в реальности происходит запись 1,3G

ls -lh /home/zvol1.backup
-rw-r--r-- 1 root root 1,3G Мар 18 10:30 /home/zvol1.backup

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

при использовании qcow2, zfs как бы не нужен?

уже писал, юзеры будут пользовать под снапшоты qcow2 через гуй, бэкапы будут на zfs.

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

юзеры будут пользовать под снапшоты qcow2 через гуй, бэкапы будут на zfs.

Не очень понятно «бэкапы будут на zfs»

Ты отдашь виртуалку юзеру, пусть делает что хочет на уровне qcow2, а ты с этого момента будешь использовать только команды zfs?

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

651МB - это в жатом состоянии на zfs, в реальности происходит запись 1,3G

Т.е. zfs send зачем-то посылает не свои сжатые блоки, а разжимает и шлет реальные данные? Фу!

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

Это можно настроить, вроде у команды zfs send, есть параметры, для сжатия потока. Я думаю, это сделано специально, ибо вдруг, у тебя на той стороне сжатие отключено?

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

Нужно понимать, что virt-manager, это не продукт уровня enterprice, а штука которая пишется в свободное от работы время парочкой программистов.

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

ибо вдруг, у тебя на той стороне сжатие отключено?

или используется другой алгоритм сжатия.

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

бекап виртуалки можно записать только с полного снапшота (т.е. когда снапшот является единственным для zvol использующегося в качестве диска виртуалки)

Разверни мысль?

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

Это не можно настроить, это исходит из реализации и называется прозрачная компрессия. Но никто не мешает использовать bzip или 'ssh -C' в цепочке.

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

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

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

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

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

в какой-то из предыдущих версий ZOL проблемы возникали из-за цепочки инкрементов, только полный снапшот виртуалки улетал

zfs send -I kvmpool/fs@snap1 kvmpool/fs@snap10 | gzip -9 > /home/zvol1.backup.gz

не?

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

обломился я, бекап от инкремента закатывает и размер у бэкапа вроде тот, но при восстановлении пишет - cannot receive new filesystem stream: invalid backup stream. Сейчас попробую всю цепочку как ты предлагаешь.

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

не не канает - cannot receive incremental stream: most recent snapshot of kvmpool does not match incremental source

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

Вот в таком рекурсивном варианте все прокатывает, все дочерние объекты включая и инкрементальные снапшоты сворачиваются в бэкап-файл и разворачиваются из него

zfs send -R kvmpool/zvol1@4-2015-03-18 > /home/zvol1.1-4.backup
zfs list -t snapshot
NAME                         USED  AVAIL  REFER  MOUNTPOINT
kvmpool/zvol1@1-2015-03-18   208K      -   651M  -
kvmpool/zvol1@2-2015-03-18      0      -   651M  -
kvmpool/zvol1@3-2015-03-18      0      -   651M  -
kvmpool/zvol1@4-2015-03-18      0      -   651M  -
zfs list
NAME              USED  AVAIL  REFER  MOUNTPOINT
kvmpool          1,27G  13,6G   136K  /kvmpool
kvmpool/zvol001   651M  13,6G   651M  -
kvmpool/zvol1     651M  13,6G   651M  -
zfs destroy -r kvmpool/zvol1
time cat /home/zvol1.1-4.backup  | zfs receive -vdF kvmpool
receiving full stream of kvmpool/zvol1@1-2015-03-18 into kvmpool/zvol1@1-2015-03-18
received 1,27GB stream in 86 seconds (15,1MB/sec)
receiving incremental stream of kvmpool/zvol1@2-2015-03-18 into kvmpool/zvol1@2-2015-03-18
received 774KB stream in 1 seconds (774KB/sec)
receiving incremental stream of kvmpool/zvol1@3-2015-03-18 into kvmpool/zvol1@3-2015-03-18
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of kvmpool/zvol1@4-2015-03-18 into kvmpool/zvol1@4-2015-03-18
received 312B stream in 1 seconds (312B/sec)

real	1m28.925s
user	0m0.024s
sys	0m1.640s
zfs list -t snapshot
NAME                         USED  AVAIL  REFER  MOUNTPOINT
kvmpool/zvol1@1-2015-03-18   208K      -   651M  -
kvmpool/zvol1@2-2015-03-18     8K      -   651M  -
kvmpool/zvol1@3-2015-03-18     8K      -   651M  -
kvmpool/zvol1@4-2015-03-18      0      -   651M  -
 
axelroot ()
Ответ на: комментарий от axelroot

я знаю что цепочку инкрементальных снапшотов можно в файл сохранить, но мне нужен такой бэкап-файл из которого можно подняться не имея родиnельских объектов, и при таком раскладе остается либо полный снапшот либо опция -R

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

Ты отдашь виртуалку юзеру, пусть делает что хочет на уровне qcow2, а ты с этого момента будешь использовать только команды zfs?

ответь на вопрос, как ты бекапишь виртуалку только средствами zfs, а если там юзер активно пишет на диск?

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

Ставить гостевые дополнения в вирт. машинку, и ей слать каким-то образом сигналы. А по-другому - никак. Чудес не бывает.

Платные решения от вмварь, кстати такое умеют? Наверно умеют.)

DALDON ★★★★★ ()
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Я на это и намекаю, а то опять носятся тут с zfs как с патентованным средством от всех болезней.

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

и zfs и qcow2 и lvm при создании снапшотов используют одинаковый механизм Copy-On-Write, COW и ничего лучше пока не придумали.

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

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

но к фатальным последствиям это не приведет

Точно? Точно-точно?

K примеру пишется новая версия glibc, предположим прилетел апдейт yum update. Вот половина нового файла уже записалась и тут ты сделал снапшот. Что будет с файлом libc-2.##.so ?

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

Что будет с файлом libc-2.##.so ?

сможешь увидеть его полностью в следующем снапшоте.

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

Что будет с файлом libc-2.##.so ?

в случаях со снапшотами от qcow2 и lvm произойдет тоже самое.

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

в случаях со снапшотами от qcow2 и lvm произойдет тоже самое.

Проблема не в этом, а в том что zfs не панацея, как тебе кажется.

Снапшоты есть в qcow2, бекапы виртуалок средствами zfs неконсистентны, oт zfs остается только сжатие, но кому это надо? — диски большие и дешевые.

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

сможешь увидеть его полностью в следующем снапшоте.

а текущий бекап — битый — спасибо!

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

Верно, но зачем нужна прослойка zfs?

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

а текущий бекап — битый — спасибо!

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

zfs не панацея

этого никто и не утверждал.

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

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

Во-первых, это ТВОЙ случай. Ты отдал юзеру виртуалку и рулишь только на уровне диска.

В виртуалке делаешь xfs_freeze -f

       xfs_freeze halts new access to the  filesystem  and  creates  a  stable
       image  on disk.  xfs_freeze is intended to be used with volume managers
       and hardware RAID devices that support the creation of snapshots.

делаешь снапшот и тут же xfs_freeze -u

В крайнем случае делаешь suspend-to-disk или shutdown, если система позволяет простой, в случае кластерных систем это легко организовать.

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

если система позволяет простой

да если б простой был возможен, никто не городил бы cow.

виртуалке делаешь xfs_freeze -f

офигительное решение заморозить запись на ФС, да и к тому же это нужно чтобы xfs не превратилась в тыкву, уж лучше положить систему в даун.

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

axelroot ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.