Hyper-v или kvm? / блог компании ruvds.com / хабр

[править] Резервное копирование виртуальных машин kvm

Сам скрипт: Файл:Vmsnapshot.txt.

Скрипт использует команду virsh, тоисть с чистым kvm не работает.
За раз бэкапит одну машину, работает в двух режимах:

Если все диски виртуальной машины находятся на lvm томах

делается снимок ее оперативной памяти (при этом она сама переходит в состояние suspend ), далее делаются снапшоты всех lvm томов и виртуальная машина снова переходит в рабочее состояние с последующим снятием резервной копии со снапшотов.

Бэкап будет включать в себя:
- образы всех жестких дисков с расширением .lzo;
- снимок памяти с расширением .vmstate;
- определение домена с расширением .xml (если dumpDomain=yes);

Если виртуальная машина имеет хоть один жесткий диск в файле

или явно установлен параметр shutdownGuest=yes, делается холодный бэкап дисков виртуальной машины и ее xml определение.

Бэкап будет включать в себя:
- образы всех жестких дисков с расширением .lzo;
- определение домена с расширением .xml (делается всегда);

Бэкапы будут лежать по пути: .

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

# Путь к лог файлу
logPath=/var/log/vmbackup
# Делать снимок оперативной памяти
saveState=yes
# Имя виртуальной машины
guest=»test_10″
# Размер снапшота lvm, суммарно в группе томов должно быть свободно
# n*snapshotSize, где n — количество виртуальных дисков vm
snapshotSize=5G
# Кому слать сообщения об ошибках
email=root
# Опции для команды dd( менять не нужно)
ddOptions=»bs=100M conv=notrunc»
# Папка куда делать бэкап
backupDest=»/opt/backup/vm_states»
# Имя команды для сжатия образа жесткого диска с опциями
lzop=»lzop -c -1″
# Сохранять xml описание домена
dumpDomain=yes
# Выключать ВМ перед сохранением резервной копии
shutdownGuest=no
# Команда через которую будет осуществляться выключение ВМ, если не определено
# используется virsh shutdown vm_name
shutdownCommand=»»
# Включать ВМ после бэкапа, имеет смысл только при shutdownGuest=yes
startGuestAfterBackup=yes
# Таймаут времени перед повторной проверкой состояния ВМ
# после отправки команды на выключение
sleepShutdown=30
# Важно!
# Максимальное количество попыток проверки выключилась ли ВМ.
# Тоесть после выполнения команды virsh shutdown скрипт будет ждать
# sleepShutdown*sleepCount секунд, чтобы она выключилась и если результат отрицательный
# -прекратит свою работу.
sleepCount=5
# Запускать гостя после холодного бэкапа
startGuestAfterBackup=yes
# Диски ВМ, которые не будут сохраняться в резервной копии
# формат строго один диск на строчку
# Пример:
# excludeDisk=»
# /dev/sda
# /dev/sdb
# »
excludeDisk=»
«

QEMU guest agent is not connected

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

error: Guest agent is not responding: QEMU guest agent is not connected

Если сделать дамп состояния vm1, то видно, что агент не подключен (disconnected):

# virsh dumpxml vm1
…
<channel type=’unix’>
<source mode=’bind’ path=’/var/lib/libvirt/qemu/vm1-win7.agent’/>
<target type=’virtio’ name=’org.qemu.guest_agent.0′ state=’disconnected’/>
<alias name=’channel0’/>
<address type=’virtio-serial’ controller=’0′ bus=’0′ port=’1’/>
</channel>
…

А должно быть

Это может быть из-за:

ошибки запуска агента в гостевой vm1 (например, виртуальная машина не была перезагружена или не были запущены службы QEMU Guest Agent и QEMU Guest Agent VSS Provider);
из-за включенного SELinux на хосте (попробуйте отключить » и посмотреть, будет connected или нет)
или еще из-за чего-нибудь.

Исправляем и пробуем наконец-то сделать бекап виртуальной машины без ее остановки:

1. Снапшот:

# virsh snapshot-create-as —domain vm1 —name vm1.snap —disk-only —atomic —quiesce –no-metadata
Domain snapshot snapshot created

Копия диска:

# cp /vms/vm1.iso /backup/vms/vm1/

Конфиг:

# virsh dumpxml vm1 > /backup/vms/vm1/vm1-dumpxml.xml

Слияние снапшота с копией

# virsh blockcommit vm1 vda —active —verbose —pivot
Block commit:
Successfully pivoted

Теперь данные будут записываться в основной диск vm1, а в backup будет копия диска и конфиг, восстановиться из которых можно с помощью virsh create.

Авторизуйтесь для добавления комментариев!

KVM

KVM — простой в использовании, легкий, нетребовательный к ресурсам и довольно функциональный гипервизор. Он позволяет за минимальные сроки развернуть площадку виртуализации и организовать виртуализацию под управлением операционной системы Linux. В процессе работы KMV осуществляет доступ к ядру операционной системы через специальный модуль (KVM-Intel или KVM-AMD). Изначально KVM поддерживал только процессоры x86, но современные версии KVM поддерживают самые разные процессоры и гостевые операционные системы, в том числе Linux, BSD, Solaris, Windows и др. Кстати, все Wiki-ресурсы (MediaWiki, Wikimedia Foundation, Wikipedia, Wikivoyage, Wikidata, Wikiversity) используют именно этот гипервизор.

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

KVM позволяет виртуальным машинам использовать немодифицированные образы дисков QEMU, VMware и другие образы, содержащие операционные системы. Каждая виртуальная машина имеет своё собственное виртуальное аппаратное обеспечение: сетевые карты, диск, видеокарту и другое железо.

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

Установка KVM в операционной системе Linux заключается в инсталляции пакета KVM и библиотеки виртуализации Libvirt, а также в тщательной настройке среды виртуализации. В зависимости от используемой на хосте операционной системы необходимо настроить мост или подключение к VNC-консоли, с помощью которой виртуальные машины будут взаимодействовать с хостом.

Администрировать KVM сложнее, так как прозрачный доступ к файлам, процессам, консолям и сетевым интерфейсам отсутствует, это приходится настраивать самостоятельно. Перестройка параметров VM в KVM (CPU, RAM, HDD) не очень удобна и требует дополнительных действий, включающих перезагрузку ОС.

Сам проект не предлагает удобных графических инструментов для управления виртуальными машинами, только утилиту Virsh, реализующую все необходимые функции. Для удобного управления виртуальными машинами можно дополнительно установить пакет Virt-Manager.

У KVM нет встроенных инструментов, подобных Fault Tolerate для VMware, поэтому единственный способ создать кластер высокой доступности — использовать сетевую репликацию при помощи DRDB. Кластер DRBD поддерживает только два узла, а узлы синхронизируются без шифрования. То есть для более безопасной связи необходимо использовать VPN-соединение.

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

Гипервизор KVM распространяется как продукт с открытым исходным кодом, а для корпоративных пользователей существует коммерческое решение Red Hat Virtualization (RHEL), основанное на KVM и платформе управления виртуальной инфраструктурой oVirt.

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

Следует учесть, что у KVM нет службы поддержки. Если что-то не получится, можно рассчитывать на форумы и помощь сообщества. Или перейти на RHEL.

Импорт из сервера с VDSmanager-KVM

Для импорта нажмите Импорт → Импорт VDS → Добавить.

Укажите:

Есть пароль для root — опция авторизации с помощью пароля пользователя root;
Пароль — пароль пользователя root. Поле доступно только при включении опции Есть пароль для root;
IP — адрес сервера;
Наименование.

При успешном подключении к серверу и получении информации о виртуальных машинах сервер добавляется в список в Импорт → Импорт VDS.

Нажмите Импорт → Импорт VDS → Список VDS для просмотра виртуальных машин, которые можно импортировать. Для запуска импорта выбранных виртуальных машин нажмите Импорт.

Условия, необходимые для импорта:

Наличие достаточного количества свободных ресурсов на узлах кластера.
Если VDSmanager настроен на интеграцию с IPmanager, то VMmanager так же должен быть настроен на интеграцию с тем же IPmanager.
VDSmanager должен работать с виртуализацией KVM.

Добавление памяти

To change the memory allocation in a VM, dump the xml as above, then edit your xml to have:

<domain type='kvm'>
  ...
  <memory>262144</memory>
  <currentMemory>262144</currentMemory>
  ...
</domain>

Now define the VM as above. Keep in mind that the memory allocation is in kilobytes, so to allocate 512MB of memory, use 512 * 1024, or 524288.

Изменение модели сетевой карты

kvm and qemu currently default to using the rtl8139 NIC. Supported NICs in Ubuntu 8.04 LTS are i82551, i82557b, i82559er, ne2k_pci, pcnet, rtl8139, e1000, and virtio. To use an alternate NIC, dump the xml as above, then edit your xml to have:

<domain type='kvm'>
  ...
    <interface type='network'>
      ...
      <model type='e1000'/>
    </interface>
  ...
</domain>

Now define the VM as above.

2-й вариант (ручками)

Т.к. vm2 уже есть, создадим vm3 и сравним результаты.

Выключаем оригинал:

# virsh shutdown vm1

Копируем диск:

# cp /data/vms/{vm1,vm3}.img

Делаем дамп xml от vm1:

# virsh dumpxml vm1 > /tmp/vm3-template.xml

Удаляем UUID оригинала, libvirt добавит новые значения:

# sed -i /uuid/d /tmp/vm3-template.xml
# sed -i ‘/mac address/d’ /tmp/vm3-template.xml

Переименовываем имена со старого на новое:

# sed -i s/vm1/vm3/ /tmp/vm3-template.xml

Создаем новую vm3:

# virsh define /tmp/vm3-template.xml
# virsh start vm1
# virsh start vm3

Этот вариант я подсмотрел здесь: http://unix.stackexchange.com/questions/8351/

Импорт удаленных машин из сервера с VMmanager KVM/Cloud или из сервера с libvirt

Для импорта нажмите Импорт → Импорт VM → Добавить.

Укажите:

IP — IP-адрес сервера;
Есть пароль для пользователя — опция авторизации с помощью пароля пользователя;
Имя пользователя ssh;
Пароль — пароль пользователя ssh. Поле доступно только при включении опции Есть пароль для пользователя;
Порт ssh;
Тип подключаемого сервера:
- Импорт из libvirt;
- Импорт из другого VMmanager KVM.
Путь к VMmanager — директория установки VMmanager KVM/Cloud. Поле доступно только при включении опции Импорт из другого VMmanager KVM.

При успешном подключении к серверу и получении информации о виртуальных машинах сервер добавляется в список в Импорт → Импорт VM.

Нажмите Импорт → Импорт VM → Список VM для просмотра виртуальных машин, которые можно импортировать. Для запуска импорта выбранных виртуальных машин нажмите Начать импорт.

Укажите:

Узел кластера — сервер для импорта. По умолчанию — Автоматический выбор — выбирается наиболее подходящий узел кластера. Подробнее об алгоритме выбора см. статью Настройка распределения виртуальных машин по узлам кластера;
Импортировать владельца — опция импорта пользователя, которому принадлежит виртуальная машина;
Хранилище — при импорте проверяется наличие хранилища с таким же названием, как и на сервере-источнике. Если в VMmanager хранилище с таким названием не добавлено, то виртуальный диск виртуальной машины копируется в хранилище, которое указано в данном поле. При импорте виртуальной машины из сетевого хранилища наименование хранилища-приёмника должно отличаться. Нельзя импортировать виртуальную машину, если её виртуальный диск расположен в сетевом хранилище, которое подключено как к серверу-источнику, так и к серверу-приёмнику;
Отключить проверку хранилища — опция отключения проверки наличия хранилища, совпадающего с хранилищем импортируемой виртуальной машины. Т.е. при включении опции виртуальный диск копируется в хранилище, указанное в поле Хранилище. Обязательно включите опцию, если виртуальный диск копируется из сетевого хранилища;
Сеть по умолчанию — импортированная виртуальная машина подключается к сети с таким же названием, как и на сервере-источнике. Если в VMmanager сеть с таким названием не добавлена, то виртуальная машина подключается к сети по умолчанию, которая указана в данном поле;
Новое доменное имя — опция указания нового доменного имени виртуальной машины;
Домен — новое доменное имя. Поле доступно только при включении опции Новое доменное имя;
Выбрать новый IP — опция указания нового IP-адреса виртуальной машины;
Тип IP-адреса — поле доступно только при включении опции Выбрать новый IP:
- Публичный — с доступом из сети Internet;
- Приватный — без доступа из сети Internet;
- NAT — для использования с сетями NAT.
IP-адрес — новый IP-адрес. Поле доступно только при включении опции Выбрать новый IP.

Условия, необходимые для импорта:

Наличие достаточного количества свободных ресурсов на узлах кластера.
Если VMmanager-источник настроен на интеграцию с IPmanager, то VMmanager-приёмник также должен быть настроен на интеграцию с тем же IPmanager.

Режимы архивирования

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

Режим Snapshot (Снимок). Этот режим можно еще назвать как Live backup, поскольку для его использования не требуется останавливать работу виртуальной машины. Использование этого механизма не прерывает работу VM, но имеет два очень серьезных недостатка — могут возникать проблемы из-за блокировок файлов операционной системой и самая низкая скорость создания. Резервные копии, созданные этим методом, надо всегда проверять в тестовой среде. В противном случае есть риск, что при необходимости экстренного восстановления, они могут дать сбой.
Режим Suspend (Приостановка). Виртуальная машина временно «замораживает» свое состояние, до окончания процесса резервного копирования. Содержимое оперативной памяти не стирается, что позволяет продолжить работу ровно с той точки, на которой работа была приостановлена. Разумеется, это вызывает простой сервера на время копирования информации, зато нет необходимости выключения/включения виртуальной машины, что достаточно критично для некоторых сервисов. Особенно, если запуск части сервисов не является автоматическим. Тем не менее такие резервные копии также следует разворачивать в тестовой среде для проверки.
Режим Stop (Остановка). Самый надежный способ резервного копирования, но требующий полного выключения виртуальной машины. Отправляется команда на штатное выключение, после остановки выполняется резервное копирование и затем отдается команда на включение виртуальной машины. Количество ошибок при таком подходе минимально и чаще всего сводится к нулю. Резервные копии, созданные таким способом, практически всегда разворачиваются корректно.

Типы гипервизоров

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

Рис. 1. Принцип работы гипервизора 1-го типа

Рис. 2. Принцип работы гипервизора 2-го типа

Примеры гипервизоров 1-го типа: Hyper-V, KVM, ESXi. Гипервизоры 2-го типа: VMware Workstation, Oracle Virtual Box, OpenVZ. Нас интересуют только системы виртуализации первого типа, так как вторые больше подходят для индивидуального использования, чем в качестве решений уровня предприятия.

Отметим, что Hyper-V и WMware — это проприетарные решения, поэтому мы подготовили обзор и сравнение гипервизоров этих моделей. Мы также поговорим и о решении с открытым исходным кодом — KVM. Многие предприятия выбирают именно его, не смотря, что некоторые независимые эксперты считают это решение довольно сырым и непригодным на корпоративной кухне. Однако, согласно отчету IT Central Station за январь 2018 года, 25% операторов связи и 11% финансовых организаций считают именно KVM лучшим гипервизором. Так что при рассуждениях о том, какой гипервизор выбрать, это решение исключать нельзя.

Рис. 3. Немного статистики от IT Central Station

Сначала мы рассмотрим проприетарные решения, а затем попытаемся выяснить, стоит ли использовать KVM.

Скрипт для автоматического бэкапа виртуальных машин KVM

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

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

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

#!/bin/bash

# Дата год-месяц-день
data=`date +%Y-%m-%d`
# Папка для бэкапов
backup_dir=/backup-vm
# Список работающих VM
vm_list=`virsh list | grep running | awk '{print $2}'`
# Список VM, заданных вручную, через пробел
#vm_list=(vm-1 vm-2)
# Лог файл
logfile="/var/log/kvmbackup.log"

# Использовать это условие, если список VM задается вручную
#for activevm in "${vm_list}";
# Использовать это условие, если список работающих VM берется автоматически
for activevm in $vm_list
    do
        mkdir -p $backup_dir/$activevm
        # Записываем информацию в лог с секундами
        echo "`date +"%Y-%m-%d_%H-%M-%S"` Start backup $activevm" >> $logfile
        # Бэкапим конфигурацию
        virsh dumpxml $activevm > $backup_dir/$activevm/$activevm-$data.xml
        echo "`date +"%Y-%m-%d_%H-%M-%S"` Create snapshots $activevm" >> $logfile
        # Список дисков VM
        disk_list=`virsh domblklist $activevm | grep vd | awk '{print $1}'`
        # Адрес дисков VM
        disk_path=`virsh domblklist $activevm | grep vd | awk '{print $2}'`
        # Делаем снепшот диcков
        virsh snapshot-create-as --domain $activevm snapshot --disk-only --atomic --quiesce --no-metadata
        sleep 2
        for path in $disk_path
            do
                echo "`date +"%Y-%m-%d_%H-%M-%S"` Create backup $activevm $path" >> $logfile
                # Вычленяем имя файла из пути
                filename=`basename $path`
                # Бэкапим диск
                pigz -c $path > $backup_dir/$activevm/$filename.gz
                sleep 2
            done
        for disk in $disk_list
            do
                # Определяем путь до снепшота
                snap_path=`virsh domblklist $activevm | grep $disk | awk '{print $2}'`
                echo "`date +"%Y-%m-%d_%H-%M-%S"` Commit snapshot $activevm $snap_path" >> $logfile
                # Объединяем снепшот
                virsh blockcommit $activevm $disk --active --verbose --pivot
                sleep 2
                echo "`date +"%Y-%m-%d_%H-%M-%S"` Delete snapshot $activevm $snap_path" >> $logfile
                # Удаляем снепшот
                rm $snap_path
            done
        echo "`date +"%Y-%m-%d_%H-%M-%S"` End backup $activevm" >> $logfile
    done

Обращаю внимание на несколько моментов:

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

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

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

/usr/bin/find /backup-vm/*/ -type f -mtime +90 -exec rm -rf {} \;

Данная команда удалит все файлы старше 90 дней в папках с названиями виртуальных машин, расположенных в /backup-vm.

[править] Восcтановление виртуальной машины из резервной копии снятой скриптом vmsnapshot

Автоматическое восстановление ВМ

Cкрипт восстановления: Файл:Vmrestore.txt.

Скрипт предназначен только для восстановления 1 к 1 бэкапов созданных скриптом vmsnapshot ( xml файл конфигурации домена должен присутствовать в бэкапе, по умолчанию так и есть, из него берется имя ВМ и типы дисков), lvm группы томов должны существовать в системе на которой происходит восстановление( сами тома или папка где храниться raw образ диска ВМ могут быть созданы автоматически при указании force=yes ). Параметры задаются в самом скрипте или в конфиге( любой переданный первым аргументом файл содержащий список переменных):

# Путь к лог файлу
logPath=/var/log/vmrestore 
# Кому слать сообщения об ошибках
email=root 
# Путь до бэкапа созданного скриптом vmsnapshot
srcRestore="/opt/backup/vm_states/test_30/20130808_11:28" 
# Создавать lv и папки где храняться диски ВМ. Если не существуют
force=yes 
# Запускать ВМ после востановленя, актуально только для холодного бэкапа,
# Виртуалки снятые на «горячую» запустяться с восстановлением памяти
startAfterRestore=yes

Ручное восстановление ВМ

С холодного бэкапа

Восстанавливаем диски вм в нужное место , пример:

lzop -dc disk1.lzo > /new/path/disk1.img
lzop -dc disk1.lzo > /dev/vg_name/vm_disk1

меняем путь до соответствующего диска в xml определении домена( используя nano, vim, mcedit) и если мы поменялии тип диска ( был в файле стало lvm или наоборот) меняем тип диска и source ( type=’file’, source file= для диска в файле и type=’block’, source dev= для диск на блочном устройстве)

Пример:
Преносим вм из файла(/opt/vm/disk1.img) на lvm (/dev/vg_system/disk1)

было:

<disk type='file' device='disk'> 
 <driver name='qemu' type='raw' io='native'/> 
 <source file='/opt/vm/disk1.img'/> 
 <target dev='vda' bus='virtio'/> 
 <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> 
</disk>

стало:

<disk type='block' device='disk'> 
 <driver name='qemu' type='raw' io='native'/> 
 <source dev='/dev/vg_system/disk1'/> 
 <target dev='vda' bus='virtio'/> 
 <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> 
</disk>

Определяем домен из xml конфигурации

virsh define domain.xml

Если все сделано правильно, можем запустить ВМ

visrsh start vm_name

Если не запускается — смотрим /var/log/messages

С горячего бэкапа

Восстанавливаем диски вм в нужное место , пример:

lzop -dc disk1.lzo > /new/path/disk1.img
lzop -dc disk1.lzo > /dev/vg_name/vm_disk1

Пример:
Преносим вм из файла(/opt/vm/disk1.img) на lvm (/dev/vg_system/disk1)

было:

<disk type='file' device='disk'> 
 <driver name='qemu' type='raw' io='native'/> 
 <source file='/opt/vm/disk1.img'/> 
 <target dev='vda' bus='virtio'/> 
 <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> 
</disk>

стало:

<disk type='block' device='disk'> 
 <driver name='qemu' type='raw' io='native'/> 
 <source dev='/dev/vg_system/disk1'/> 
 <target dev='vda' bus='virtio'/> 
 <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> 
</disk>

Восстанавливаем домен из снимка памяти:

visrh restore vm_name.vmstate --xml domain.xml

Если не восстанавливаеться — смотрим /var/log/messages

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

virsh dumpxml /tmp/domain.xml

Восстанавливаем определение домена:

virsh define  /tmp/domain.xml

Сетевой Bridge для kvm

Настройка сети для виртуальных машин kvm может быть настроена различными способами. Я как минимум 3 наиболее популярных знаю:

Виртуальные машины выходят во внешний мир через сам хост kvm, на котором настроен NAT. Этот вариант вам будет доступен сразу после установки kvm. Ничего дополнительно настраивать не надо, так как сетевой бридж для этого virbr0 уже будет добавлен в систему. А в правилах iptables будет добавлен MASQUERADE для NAT.
Одна из виртуальных машин превращается в шлюз и через нее осуществляется доступ во внешний мир для всех виртуальных машин. Наиболее гибкий способ управления сетью для vm, но в то же время требует больше времени на настройку и набор знаний по работе с сетями.
Для виртуальных машин kvm создается отдельный сетевой бридж во внешнюю сеть. Они напрямую получают в нее сетевой доступ.

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

sudo apt install bridge-utils

Теперь на хосте приводим сетевые настройки в /etc/netplan к следующему виду.

network:
  ethernets:
    ens18:
      dhcp4: false
      dhcp6: false
  version: 2

  bridges:
    br0:
      macaddress: 16:76:1a:3b:be:03
      interfaces:
        - ens18
      dhcp4: true
      dhcp6: false
      parameters:
        stp: true
        forward-delay: 4

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

В предложенном наборе правил netplan у меня один сетевой интерфейс на хосте гипервизора — ens18. Он изначально получал настройки по dhcp. Мы добавили новый сетевой бридж br0, в него добавили интерфейс ens18. Так же мы указали, что br0 будет получать сетевые настройки по dhcp. Я указал mac адрес для того, чтобы он не менялся после перезагрузки. Такое может происходить. Адрес можно указать любой, не принципиально. Я сделал похожий на адрес физического сетевого интерфейса.

Теперь надо применить новые настройки.

sudo netplan apply

Сразу после этого вы потеряете доступ к серверу по старому адресу. Интерфейс ens18 перейдет в состав bridge br0 и потеряет свои настройки. А в это время бридж br0 получит новые сетевые настройки по dhcp. IP адрес будет отличаться от того, что был перед этим на интерфейсе ens18. Чтобы снова подключиться удаленно к гипервизору kvm, вам надо будет пойти на dhcp сервер и посмотреть, какой новый ip адрес ему назначен.

Если у вас нет dhcp сервера или вы просто желаете вручную указать сетевые настройки, то сделать это можно следующим образом.

network:
  ethernets:
    ens18:
      dhcp4: false
      dhcp6: false
  version: 2

  bridges:
    br0:
      macaddress: 16:76:1a:3b:be:03
      interfaces:
        - ens18
      addresses:
        - 192.168.25.2/24
      gateway4: 192.168.25.1
      nameservers:
        addresses:
          - 192.168.25.1
          - 77.88.8.1
      dhcp4: false
      dhcp6: false
      parameters:
        stp: true
        forward-delay: 4

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

Обращайте внимание на все отступы в конфигурационном файле netplan. Они важны

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

Далее еще один важный момент. Чтобы наш kvm хост мог осуществлять транзит пакетов через себя, надо это явно разрешить в sysctl. Добавляем в /etc/sysctl.d/99-sysctl.conf новый параметр. Он там уже есть, надо только снять пометку комментария.

net.ipv4.ip_forward=1

Применяем новую настройку ядра.

sudo sysctl -p /etc/sysctl.d/99-sysctl.conf
net.ipv4.ip_forward = 1

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

Заключение

В начале статьи я сказал, что не встретил готового решения по живому бэкапу kvm. (upd. Уже после публикации статьи мне подсказали готовое решение kvmBackup.) На самом деле это не совсем верно. Есть хорошая готовая сборка на основе kvm — proxmox. Я подробно рассматривал ее в отдельном материале — Установка и настройка proxmox. Но все же это решение конкретного коллектива разработчиков со своими возможностями и ошибками. В проксмокс реализован живой бэкап виртуальных машин из коробки. К сожалению, я не смог быстро найти техническую реализацию их решения. Возможно, все было бы еще проще. Но так тоже ничего получилось.

Важное дополнение в самом конце. Не забывайте проверять возможность восстановления систем из ваших резервных копий

Ведь конечная цель не сделать бэкап, а восстановиться из него!!!