LINUX.ORG.RU

Резервное копирование виртуальной машины QEMU/KVM с паузой и записью памяти

 , , ,


6

5

В интернете есть статьи, где было описано как сделать бэкап работающей виртуальной машины (ВМ) с использованием гостевого агента QEMU (см. например https://bozza.ru/art-337.html ). Что же делать, если в ВМ нельзя установить этот агент? В таком случае поможет кратковременная пауза виртуальной машины и запись её памяти. Перерыв в доступности ВМ будет только на время записи её памяти на диск и чтения обратно.

Опишу последовательность действий, как набор команд терминала.

Процесс копирования.
  1. Запрашиваем состояние ВМ
virsh list  
 Id    Name                           State
----------------------------------------------------
 2     my_vm                          running

ВМ работает.

  1. Создаем папку для бэкапа:
mkdir -p ~/backup/my_vm 
  1. Запрашиваем список дисков ВМ
virsh domblklist my_vm --details
Type       Device     Target     Source
------------------------------------------------
file       disk       hda        /var/lib/libvirt/images/my.img
  1. Делаем внешний снимок диска для минимизации времени простоя ВМ:
virsh snapshot-create-as --domain my_vm bus \
 --disk-only --atomic  --no-metadata \
 --diskspec hda,snapshot=external,file=/var/lib/libvirt/images/my.img-bus
Domain snapshot bus created
  1. Записываем память ВМ в директорию бэкапа
virsh save my_vm ~/backup/my_vm/memory.dump
Domain my_vm saved to /home/piter/backup/my_vm/memory.dump

ВМ при этом выключается.

  1. Копируем снимок диска:
cp /var/lib/libvirt/images/my.img-bus ~/backup/my_vm/

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

  1. Восстанавливаем ВМ из файла памяти:
virsh restore --running ~/backup/my_vm/memory.dump
Domain restored from /home/piter/backup/my_vm/memory.dump
  1. ВМ работает, можно без спешки скопировать основной диск.
cp /var/lib/libvirt/images/my.img ~/backup/my_vm/
  1. После того как диск скопирован — присоединяем файл снимка к диску
virsh blockcommit my_vm hda --active --pivot
Successfully pivoted
  1. и удаляем его
rm /var/lib/libvirt/images/my.img-bus
  1. Копируем в папку файл описания ВМ libvirt:
virsh dumpxml my_vm > ~/backup/my_vm/libvirt.xml

Процесс копирования завершен.

Копия ВМ содержит неконсистентный файл диска, снимок диска и снимок памяти ВМ:

ls  ~/backup/my_vm/
libvirt.xml  memory.dump  my.img  my.img-bus
Процесс восстановления.
  1. Останавливаем ВМ
virsh shutdown my_vm
  1. Восстанавливаем из копии файлы диска и его снимка
cp ~/backup/my_vm/my.img /var/lib/libvirt/images/my.img 	
cp ~/backup/my_vm/my.img-bus /var/lib/libvirt/images/my.img-bus
  1. Восстанавливаем ВМ из файла памяти:
virsh restore --running ~/backup/my_vm/memory.dump
Domain restored from /home/piter/backup/my_vm/memory.dump
  1. ВМ работает, присоединяем файл снимка к диску
virsh blockcommit my_vm hda --active --pivot
Successfully pivoted
  1. и удаляем его
rm /var/lib/libvirt/images/my.img-bus

Процесс восстановления завершен.



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

Версии:

qemu-system-x86_64 --version
QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.42)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

virsh --version
4.0.0
smola0609
() автор топика

Отлично! Сейчас как раз пилю свой велосипед для управления снапшотами на базе backing files, само собой получается ограничение на то, что ВМ должна быть выключена для манипуляции со снапшотами. С подходом через паузу+сохранение памяти, гипотетически можно подумать о сохранении всего состояния машины

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

В "статье" написана полная дичь.

Вот правильные статьи:

https://wiki.qemu.org/Documentation/CreateSnapshot
https://qemu-project.gitlab.io/qemu/system/images.html#vm-005fsnapshots

Руками в qemu его сценарий достигается через savevm + на выбор:

  1. копирование внешнего файла снапшота
  2. инкрементальное копирование существующего qcow

Оффдока на virsh тут.

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

В «статье» написана полная дичь.

да не, вроде рабочий алгоритм.

Вот правильные статьи:

и что там есть по задаче бэкапа с мин. простоем?

копирование внешнего файла снапшота

в статье это и делается в т.ч.

инкрементальное копирование существующего qcow

через virsh backup-begin ?

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

да не, вроде рабочий алгоритм.

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

и что там есть по задаче бэкапа с мин. простоем?

где запрос на минимальный простой, если «ВМ при этом выключается»?

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

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

это Redirect-on-Write external снапшот, т.е. основной образ (my.img) в момент создания снапшота «замораживается», а запись измененных блоков ведется в файл my.img-bus.
Запись в my.img-bus прекращается в момент сохранения состояния VM (virsh save), т.о. дамп памяти memory.dump консистентен с my.img-bus (а после virsh blockcommit консистентен с основным образом)

где запрос на минимальный простой, если «ВМ при этом выключается»?

Запрос сформулирован в статье:

Перерыв в доступности ВМ будет только на время записи её памяти на диск и чтения обратно.

На самом деле там ещё прибавляется время на копирование RoW снапшота my.img-bus (на 6 шаге), но он должен быть небольшого размера.
Основной образ (my.img) копируется уже после включения VM (virsh restore).

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

это Redirect-on-Write external снапшот, т.е. основной образ (my.img)

в чем будет отличие от «полный снапшот → скопировать образ → откатить скопированный образ до снапшота»? Подразумевается, что работает не только для qcow2?

Запрос сформулирован в статье:

Перерыв в доступности ВМ будет только на время записи её памяти на диск и чтения обратно.

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

xgatron
()

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

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

Да, внешний снимок можно создать на любом типе файла (raw, qcow2) на lvm и на образах ceph.

Вот пример создания снимка для ВМ с диском на lvm.

virsh -c qemu:///system domblklist one-41 --details
 Тип     Устройство   Назначение   Источник
--------------------------------------------------------
 block   disk         vda          /dev/vg0/hvs-110-82

virsh -c qemu:///system snapshot-create-as --domain one-41 bus \
--disk-only --atomic  --no-metadata 
--diskspec vda,snapshot=external,file=/data/0/datastores/0/disk-41.bus
Снимок домена bus создан

После снимка ВМ уже имеет следующий диск:
virsh -c qemu:///system domblklist one-41 --details
 Тип    Устройство   Назначение   Источник
--------------------------------------------------------------------
 file   disk         vda          /data/0/datastores/0/disk-41.bus

virsh -c qemu:///system blockcommit one-41 vda --active --pivot
Операция поворота цепочки завершена успешно

После коммита все возвращается:

virsh -c qemu:///system domblklist one-41 --details
 Тип     Устройство   Назначение   Источник
--------------------------------------------------------
 block   disk         vda          /dev/vg0/hvs-110-82

А откуда qemu знает, что файл disk-41.bus- это довесок к lvm-тому? А вот откуда:

sudo qemu-img info /data/0/datastores/0/disk-41.bus
image: /data/0/datastores/0/disk-41.bus
file format: qcow2
virtual size: 2 GiB (2147483648 bytes)
disk size: 196 KiB
cluster_size: 65536
backing file: /dev/vg0/hvs-110-82
backing file format: raw
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
Child node '/file':
    filename: /data/0/datastores/0/disk-41.bus
    protocol type: file
    file length: 192 KiB (197120 bytes)
    disk size: 196 KiB
smola0609
() автор топика

Есть некоторые сомнения. Дамп памяти и диска должны быть на один момент времени

ИМХО, раз уж при создании дампа памяти ВМ выключается, то лучше так: сначала дамп памяти, потом snapshot, потом включение вм и бекап snapshot’а

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

да не, вроде рабочий алгоритм.

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

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

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

Есть некоторые сомнения. Дамп памяти и диска должны быть на один момент времени

так и есть, я это пояснял в сообщении выше (Резервное копирование виртуальной машины QEMU/KVM с паузой и записью памяти (комментарий))

ИМХО, раз уж при создании дампа памяти ВМ выключается, то лучше так: сначала дамп памяти, потом snapshot, потом включение вм и бекап snapshot’а

да, такой алгоритм проще для восприятия (хотя результат одинаковый), но есть нюанс: дамп памяти (virsh save) содержит конфиг машины в xml. Если после virsh save сделать снапшот (virsh snapshot-create-as), а потом сделать virsh restore, то в xml снапшота не будет, поэтому нужно при restore указывать правильный xml через опцию --xml.

там стоит обратить внимание на ключи –memspec и –live

я тоже про них подумал и потестил:

virsh snapshot-create-as --domain vm4 snap8 --memspec snapshot=external,file=/var/lib/libvirt/qemu/extsnap/vm4-snap8.mem --diskspec hda,snapshot=external,file=/var/lib/libvirt/qemu/extsnap/vm4-snap8.qcow2 --atomic --live
Хорошая новость - команда действительно работает и создает внешний RoW снапшот диска, а также дамп пямяти (при этом его формат тот же, что в случае virsh save). Плохая новость - в моем тесте опция --live ничего не поменяла, т.е. VM встает на паузу на время снятия дампа памяти. Поэтому существенных преимуществ перед алгоритмом из обсуждаемой статьи - нет, кроме того что время простоя сокращается на virsh restore.

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

Я не понимаю что здесь написано :(

Если хранилище для 2х ВМ в одном месте (ну типа iSCSI,NFS и т.д.) то достаточно просто:

virsh migrate --live 

если хранилище в разных местах то на 2ом месте лепим такой же диск (ну в смысле имя) и делаем:

virsh migrate --live --copy-storage-all

Все !

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

я тоже думал про вариант с миграцией (поскольку там и память и диск могут копироваться в live режиме).
Кстати в хабровской публикации этой статьи (https://habr.com/ru/sandbox/251746/) есть отсылка к другой статье 2014 года, где в комментах тоже предлагают варианты с миграцией (https://habr.com/ru/articles/242213/#comment_8211437)

Но приведенные тобой команды никак на законченную инструкцию не тянут (cтрого говоря они даже синтаксически не верны, т.к. не указаны имя VM и destination uri).
Допустим мы подняли второй экземпляр libvirtd, на который будет осуществляться live миграция. Насколько я помню после окончания миграции source перейдет в inactive state, а destination будет либо active, либо suspended. По крайней мере в случае shared storage так будет, чтобы исключить конкурентный доступ к диску.
Ну и как это поможет сделать бэкап (диск+память)?

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

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

А вот насчет бекапа тут упс, я с тормозил. Я когда прочитал что тут написано особо про память то думал что это про лайв.

С бекапом все просто, торомозишь машину, делаешь снапшот лвм и запускаешь. Потом бекапишь снапшот сколько вздумается и удаляешь его. Все.

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

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

достаточно давно ввели.

С бекапом все просто, торомозишь машину, делаешь снапшот лвм и запускаешь. Потом бекапишь снапшот сколько вздумается и удаляешь его. Все.

это crash consistent снапшот. И для него не обязательно ставить на паузу VM (если только не подразумевался сценарий, когда на LVM томе лежат qcow2 образы). В статье же говорится про бэкап вместе с памятью (RAM).

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

В смысле на лвм тоже лежат? ЛВМ это диски, давным давно, когда все это началось были тесты показывающие что блочные устройства внутри по скорости не отличаются от натива. С тех я в ВМ для локальных сторажей юзаю только ЛВМ.

Я не ставлю на паузу я полностью останавливаю.

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

Я не ставлю на паузу я полностью останавливаю.

т.е. в shutdown?
А в статье рассматривается алгоритм без shutdown, а только с относительно небольшим простоем на паузе (время сохранение+восстановления дампа памяти). Бэкапится диск+ram.

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

Я предпочитаю с полным остановом, для меня так надежнее. Сколько там время остановки и запуска? 5 минут?

Опять же с конкретными вещами нужно разбираться по своему, к примеру если там БД, то бекап делается средствами БД ну и т.д.

mx__ ★★★★★
()

Стоит отметить следующий недостаток бэкапов с памятью: они привязаны к версии qemu (и/или libvirtd?). Что для долгосрочного бэкапа совсем не хорошо, поэтому я по-возможности сохраняю RAM средствами OS (hibernate на MS Windows).

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