Home » Виртуализация » KVM » Live (горячий) бэкап виртуальных машин KVM

Live (горячий) бэкап виртуальных машин KVM

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

Онлайн-курс по устройству компьютерных сетей

На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Введение

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

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

В итоге я остановился на Xen там, где нужно поставить систему на программный рейд mdadm, и Hyper-V в тех случаях, где рейд либо не нужен совсем, либо он аппаратный. В своей работе так или иначе приходится сталкиваться с различными системами, поэтому разбираться приходится во всем, в том числе и в kvm.

Есть 2 различных способа сделать бэкап виртуальной машины kvm:

  1. С остановкой или заморозкой системы на короткий промежуток времени.
  2. Без остановки системы вообще.

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

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

Какой диск выбрать в kvm - lvm, raw (img) или qcow2

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

LVM. Тут все понятно. Использование lvm томов в виде дисков виртуальных машин. Такой диск будет блочным устройством и должен работать быстрее всех остальных типов, так как нет лишней прослойки в виде файловой системы.

Плюсы:

  • Снэпшоты средствами самого lvm, с них легко снять бэкап без остановки виртуальной машины.
  • Максимальное быстродействие.
  • Легко изменить размер диска.

Минусы:

  • Более сложное управление по сравнению с дисками в виде отдельных файлов.
  • Менее гибкое управление пространством диска. Если весь диск разбить на lvm разделы для виртуалок, то места на нем не останется, даже если вируталки будут пустые.
  • Более сложный перенос на другой сервер.

RAW. Это обычный формат сырых данных. Среди дисков в виде файлов это будет самый простой и быстрый вариант. Все данные пишутся как есть без дополнительных обработок и служебной информации. Формат является универсальным для большинства популярных гипервизоров.

Плюсы:

  • Максимальная простота и производительность среди образов в виде файла.
  • Универсальный формат с поддержкой в большинстве гипервизоров.
  • Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.

Минусы:

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

QCOW2. Родной формат для гипервизора QEMU. Расшифровывается как QEMU Copy-on-write. Этот формат позволяет создавать динамические диски для виртуальных машин, а так же поддерживает снепшоты. Теоретически, скорость работы должна хоть и не сильно, но уступать RAW. Как обстоит дело на практике, я не знаю, не замерял и подробно эту информацию не проверял.

Плюсы:

  • Поддержка снепшотов и динамических дисков. Как следствие - более удобное управление дисковым пространством.
  • Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.

Минусы:

  • Более низкая производительность, по сравнению с другими типами образов.

У каждого типа есть свои преимущества и недостатки. Lvm проще всего бэкапить, но им сложнее всего управлять. Для того, кто хорошо знаком с lvm это не проблема, если сталкиваешься первый раз, то возникает много вопросов. У raw нет снепшотов, лично для меня это большой минус, я этот формат вообще не рассматриваю. Если нет максимальной нагрузки на дисковую подсистему, то QCOW2 мне кажется наиболее приемлемым вариантом. Собственно, ниже и пойдет рассказ, как совместить удобство управления QCOW2 и простоту бэкапов и снэпшотов lvm. Я покажу, как сделать живой бэкап виртуальной машины kvm в формате qcow2 без остановки виртуальной машины.

Бэкап виртуальной машины kvm без остановки

Перед практической реализацией живого бэкапа виртуальной машины, снова немного поговорим о теории. Для бэкапа виртуальной машины kvm достаточно просто скопировать ее диски в виде файлов. Это можно сделать даже при работающей машине. Но если в этот момент на виртуалке идет какая-то дисковая активность, вы скорее всего получите неработающий образ. И это логично. Значит нам, чтобы гарантированно скопировать диск, виртуальную машину нужно выключить, либо придумать что-то еще.

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

С самими снепшотами тоже есть нюансы. Есть 2 разных типа снепшота. Например, если вы сделаете снепшот qcow2 средствами virt-manager, то удивитесь, не увидев новый файл снепшота. Оказывается, снепшот будет создан внутри qcow2, а файл как был один, так и останется. Это очень неудобно, так как если у вас будет занят весь доступный для файла объем, вы гарантированно получите ошибку при старте вашей виртуалки. А контролировать объем диска, в котором находятся снепшоты трудно и неудобно. И бэкапы в таком случае делать тоже не получится. Хотя получится, но все равно не удобно. Нужно будет отдельными командами конвертировать состояние виртуальной машины до снепшота в отдельный файл и его уже забирать для бэкапа. Плюс ко всему машину в этом случае нужно будет заморозить на момент создания снимка. Заморозка будет кратковременной, но все равно без нее не обойтись. Я приведу для примера команды, которыми это можно делать, но сам я не стал использовать такой способ, потому что, во-первых, не смог найти команды на объединения снепшота и основного файла, во-вторых, меня не устраивает даже кратковременная заморозка системы.

Замораживаем виртуалку:

# virsh domfsfreeze vm-name

Делаем снепшот:

# qemu-img create -f qcow2 -b vm-name.qcow2 vm-name-snapshot.qcow2

Размораживаем

# virsh domfsthaw vm-name

Конвертируем снепшот в отдельный образ:

# qemu-img convert -O raw vm-name-snapshot.qcow2 /backup-vm/vm-name-snapshot.img

Преобразовываем raw обратно в qcow2:

# qemu-img convert -O qcow2 /backup-vm/vm-name-snapshot.img /backup-vm/vm-name-snapshot.qcow2

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

В рунете я вообще не нашел информации, как все сделать красиво, удобно и быстро. Нашел инструкцию на официальном сайте libvirt - http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit Дальше фактически будет перевод с моими пояснениями.

Установка qemu-guest-agent

Мы будем делать снепшот средствами virsh. При этом остановки или заморозки системы не будет вообще. Чтобы этот вариант корректно работал, вам необходимо установить на виртуальную машину qemu-guest-agent. Для этого вам сначала нужно добавить Channel Device по имени org.qemu.guest_agent.0. Проще всего это сделать через virt-manager.

Установка qemu-guest-agent

Затем в систему надо установить пакет qemu-guest-agent. Для debian и centos все просто:

# apt-get install qemu-guest-agent
# yum install qemu-guest-agent

Для windows надо с диска virtio-win установить пакет qemu-ga из папки guest-agent, которая находится в корне диска.

Подробнее об установке qemu-guest-agent можно прочитать в документации redhat. Теперь у нас все готово для выполнения живого бэкапа виртуальной машины в kvm без остановки этой виртуалки.

Выполняем снепшот виртуальной машины:

# virsh snapshot-create-as --domain vm-name backup-snapshot -diskspec vda,file=/snapshot/vm-name-backup.qcow2 --disk-only --atomic --quiesce --no-metadata
vm-name имя виртуальной машины
backup-snapshot название снэпшота, может быть любым
vda имя диска, для которого указываем адрес снепшота
/snapshot/vm-name-backup.qcow2 путь и имя файла для снепшота

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

# virsh domblklist vm-name
Обращаю внимание на важный момент, который я сначала упустил и долго не мог разобраться в логике создания снепшота. Параметр diskspec не указывает для какого диска создается снепшот, а просто обозначает путь до снепшота. Если у вас несколько дисков, а в diskspec вы указали только один диск, то снепшоты все равно будут созданы для всех дисков. При этом для тех дисков, где вы указали путь, будет использоваться указанный, а для остальных будет по-умолчанию в той же папке, где лежит исходный файл ВМ. Этот нюанс серьезно меняет логику работы скриптов для автоматизации бэкапа в том случае, если у машин несколько дисков. Написав скрипт для бэкапа машин с одним диском, у меня не получилось его быстро оптимизировать для нескольких.

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

# pigz -c /virt/vm-name.qcow2 > /backup-vm/vm-name.qcow2.gz

Когда выполнение бэкапа завершено, объединим снапшот с основным файлом:

# virsh blockcommit vm-name vda --active --verbose --pivot

После этого файл снэпшота можно удалить:

# rm /snapshot/vm-name-backup.qcow2

Для полноты картины забэкапим еще и настройки виртуалки:

# virsh dumpxml vm-name > /backup-vm/vm-name.xml

И на этом все. Мы сделали полный бэкап работающей виртуальной машины kvm без ее остановки. Сама она даже не поняла, что с ней что-то сделали. Работающие БД на ней не испытывают никаких проблем. Проверял на postgresql. Терминальные сессии в windows server тоже чувствуют себя отлично.

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

По мотивам всего написанного выше я набросал простенький скрипт для автоматического живого бэкапа всех дисков всех работающих в момент выполнения скрипта виртуальных машин. Обращаю внимание, что бэкапятся все диски. Скрипт привожу просто для примера, не используйте его, если вам не нужны полные бэкапы всех дисков. Лично я бэкаплю только небольшие системные диски. Все, что много весит, предпочитаю архивировать другими способами уже изнутри виртуальной машины. Если это базы данных, то делаю бэкапы нужных баз postgresql, если это файловый сервер, то использую 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.

Заключение

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

Онлайн-курс по устройству компьютерных сетей.

На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Важное дополнение в самом конце. Не забывайте проверять возможность восстановления систем из ваших резервных копий. Ведь конечная цель не сделать бэкап, а восстановиться из него!!!

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

106 комментариев

  1. Евгений

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

  2. Андрей

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

  3. Добрый день
    Доработал скрипт с разными проверками. Может кому пригодится. А то я очень сильно был удивлен когда удалился мой образ ВМ из-за ошибок на первых шагах. Потерял данные :(
    https://github.com/darksmoke/Scripts/blob/main/Linux/kvm_live_backup.sh

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

  4. Андрей

    Добрый день. Везде лазил, но похожего не нашёл ... При работающих виртуалках, ПЕРЕНЁС их файлы (CentOS 8 KVM) в другой каталог. Через неделю заметил это. А виртуалки работали, копила данные ... Как теперь из работающей виртуалки сделать файл? Одну потерял остановив ...

    • Даже не представляю, как это исправить. Наверняка как-то можно, но моих знаний не хватает, чтобы что-то предложить. То ли виртуалки в оперативной памяти новые данные копят, то ли продолжают писать в удаленный файл. Не известно. Но раз они все еще работают, значит данные в том или ином виде живы.

  5. Добрый день!

    Огромное спасибо за Ваш скрипт!

    Позволил себе его немного доработать.
    В частности реализовал отработку параметра --diskspec при наличии нескольких дисков в виртуалке.
    Кусок кода ниже.

    # Список виртуальных дисков VM
    disk_list=`virsh domblklist $activevm | grep vd | awk '{print $1}'`
    for disk in $disk_list
    do
    diskspec="${diskspec} --diskspec $disk,file=$snap_dir/$activevm.$disk.snapshot"
    done

    Где snap_dir - отдельная папка со снапшотами
    Используем полученную переменную в следующей команде.

    # Делаем снепшот диcков
    virsh snapshot-create-as --domain $activevm snapshot$diskspec --disk-only --atomic --quiesce --no-metadata >> $logfile

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

    Ещё, при определении того какие виртуальные машины бэкапить, неплохо было бы проверять, запущен ли на них qemu-agent, потому как бэкап без работающего агента завершится ошибкой.
    for activevm in $vm_list
    do
    # Проверяем активность агента на VM
    virsh qemu-agent-command $activevm '{"execute":"guest-ping"}' > /dev/null 2>&1
    if [ $? -eq 0 ] ;then
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Agent is alive on $activevm" >> $logfile
    # Агент доступен, продолжвем

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

    # Проверяем что VM использует снапшот, благо его расширение мы знаем
    virsh domblklist $i | grep $disk | awk '{print $2}' | grep -q snapshot
    if [ $? -eq 0 ] ;then
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Commit snapshot $i $snap_dir/$activevm.$disk.snapshot" >> $logfile
    # Объединяем снапшот
    virsh blockcommit $activevm $disk --active --verbose --pivot >> $logfile
    sleep 2
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Delete snapshot $activevm $snap_dir/$activevm.$disk.snapshot" >> $logfile
    # Удаляем снепшот
    #rm -f $snap_dir/$activevm.$disk.snapshot
    else
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Snapshot $activevm $snap_dir/$activevm.$disk.snapshot not present" >> $logfile
    fi

    Надеюсь мои доработки будут кому-нибудь полезны.

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

      • "Я не использую этот метод" - Можете поделиться что в итоге используете ?
        Скрипт вроде работает корректно когда руками его запускаешь, но нельзя учесть всё.
        Спасибо!

        • Везде, где нужно kvm, ставлю proxmox.

          • Proxmox наглухо прибит гвоздями к debian, а я предпочитаю CentOS.
            Думаю у Proxmox под капотом та же логика работы, что и у "нашего" скрипта, может только более продвинутая система отслеживания работы и вылавливания ошибок.
            В любом случае, спасибо!

            • Это да, я тоже люблю все на centos держать, но тут решил, что оно того не стоит. Лучше взять из коробки. Благо, я debian знаю не хуже чем centos. Одинаково с тем и другим работаю.

    • Евгений

      у вас не осталось полного текста вашего скриптика ?

  6. Аноним

    Мда, с удалением образа машины вместо снэпшота - это жестко -))

    Пока так:
    error: unsupported configuration: online commit not supported with this QEMU binary
    # virsh -v
    4.5.0

    • Для удалятелей я отдельно предупреждение сделал: " На время отладки советую для начала закомментировать строку с удалением снепшота, на всякий случай."

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

  7. Добрый день!
    error: Guest agent is not responding: QEMU guest agent is not connected
    это что за ошибка подскажите

  8. Алексей

    Zerox, а инструкцию по установке и настройке KVM на CentOS вы не писали?

  9. скрип жесть, убил мне виртуалку.. ничего не забекапил.

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

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

        • Специально написал: "На время отладки советую для начала закомментировать строку с удалением снепшота, на всякий случай. Рекомендую этот крипт прогнать сначала на тестовом сервере."

  10. Аноним

    Я не понимаю, ребята, а как же vol-clone???
    Объясните плиз)

  11. Подскажите, вот создал я снимок виртуальной машины в KVM "sudo virsh snapshot-create-as --domain generic --name generic_backup --diskspec hdb,file=/mnt/kvm/backup/generic.qcow2 --disk-only --atomic --quiesce --no-metadata
    " и он нормально создался.
    Пишу "sudo virsh snapshot-list generic" и снимки отсутствуют. Пиушу "sudo virsh domblklist generic" и вижу "hdb /mnt/kvm/backup/generic.qcow2" . Не пойму почему первая команда нечего не выводит ?

    • Нашел ответы в комментариях выше =)

      • Виталий

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

  12. Добрый день. Не получается запустить virt-manager через putty. Выдает ошибку (virt-manager:6095): Gtk-WARNING **: cannot open display:
    Хотя до этого все настраивал и работало. Просто решил заново все перезалить и настроить, чтобы составить для себя инструкцию в ворде. И все, кабздец, не получается запустить вирт менеджер)))))
    1. В винде запущен VcXsrv
    2. #vi /etc/ssh/sshd_config

    X11Forwarding yes

    X11DisplayOffset 10

    X11UseLocalhost yes
    #service sshd restart
    3. в путти Connection ->SSH -> X11 ставлю галку на против пункта- Enable X11 forwarding

    • Я такими настройками не занимался, не подскажу.

      • Дружище, напиши пожалуйста как твоем скрипте сделать, так чтобы было открыто исходящие пакеты на порт 22 для ssh чтобы пробросить X11
        мне кажется дело в все в этом, я до сих пор ..бусь с этой проблемой))))

        • Короче ПАСАНЫ!!! Если у вас не будет работать virt-manager и выдает ошибку (virt-manager:6463): Gtk-WARNING **: cannot open display:
          То это: 1) Перегрузить ПК клиент и сервер или 2) Это значит у вас отключен ipv6, да да, три недели е..ался и нашел все же причину))) Проброс X11 идет по ipv6, ппц)

  13. C чем связана - трудно сказать. В сети много вопросов-ответов по этой ситуации. Я не нашел, окончательного решения, которое бы избавило от этой ситуации навсегда. Грешат на libvirt. После такого сообщения ситуация выглядит следующим образом: изменения из файла снапшота накатываются на исходный файл вашей ВМ, но не происходит окончательного переключения активного диска на исходный файл. Изменения продолжают писаться и в исходный файл и в файл снапшота, это видно если выгрузить конфиг командой virsh dumpxml. Почему-то не получается сделать окончательное переключение активности на исходный файл ВМ и отключить снапшот. У меня делается резервное копирование 2х ВМ и такая ошибка на более загруженной машине появляется чаще, где-то раз в 10-15 дней. На другой реже.

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

  14. Добрый день!

    Приходилось ли вам сталкиваться с ситуацией, когда при накате снапшота на основной файл коммандой
    virsh blockcommit YOUR_VM hda --active --pivot
    выдавалась ошибка:
    error: failed to pivot job for disk hda
    error: block copy still active: disk 'hda' not ready for pivot yet

    Как вы из нее выходите и автоматизировали в скрипте обработку этого события?
    С делаю так (не знаю корректно это или нет):
    virsh blockjob YOUR_VM hda --pivot

    • Не было такой ошибки. С чем она связана?

    • Вероятно, не установлен гостевой агент в системе или читайте внимательно "block copy still active", что как бы намекает, что все еще выполняется блочное копирование.

      В примере выше это никак не реализовано, но по факту можно проверять: если .snapshot не создан, то выполнять копирование выключением ВМ.

      А вообще, спасибо за статью - натоклнуло на мысль, как реализовать и написать свой скрипт.

  15. Сергей

    Добрый день!
    Спасибо за интересную и, главное - полезную информацию.
    Не могли бы Вы пояснить более подробно следующий шаг, который выполняется после создания снепшота виртуальной машины:

    "
    После того, как сделали снимок, скопируйте куда вам нужно основной файл виртуальной машины. Я предпочитаю его сразу сжимать всеми ядрами процессора с помощью архиватора pigz и далее по тексту ..."
    Интересует несколько вопросов:
    1. Процесс копирования основного файла виртуальной машины осуществляется при включенной машине? Обычное копирование? А как же желание исключить влияние активности в файловой системе VM ?
    2. Зачем объединять основной файл со снимком?

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

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

  16. Добрый день !
    на сервере 2 виртуалки - винда и centos, в обе добавлены каналы org.qemu.guest-agent.0, тип unix. на винде поставлены дрова и запущены две службы. при попытке заморозки или снэпшота на centos - всё проходит на ура. при потыке заморозить винду получаю следующее:
    # virsh domfsfreeze vm2
    error: Unable to freeze filesystems
    error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': this feature or command is not currently supported

    Версия qemu:Compiled against library: libvirt 3.2.0
    Using library: libvirt 3.2.0
    Using API: QEMU 3.2.0
    Running hypervisor: QEMU 2.9.0

    В чем проблема ? CentOS Linux release 7.4.1708 (Core)

    • Евгений

      Нужно установить репозиторий centos-qemu-ev, и обновиться. Из этого репозитория всё работает как надо. Проверено.

  17. Спасибо за помощь!
    Все стало понятно!
    Надо будет попробовать, и конечно не на рабочем.
    Там простой на данный момент невозможен.

    P.S. Я хотел это сделать чтобы можно было настроить backup-vm всех б на данный момент их 3.
    Ничего я думаю что-то получиться.
    Выше есть данные что стоит, если есть идея как поправить скрипт который будет работать смогу попробовать.
    Поставить ещё Виртуалку и попробовать.

    Ещё раз спасибо всем.

  18. Может я что-то не так делаю?
    Хотя вроде следую выше описанному.
    Выполняем команду
    virsh snapshot-create-as --domain dns.server1 backup-snapshot -diskspec hdb,file=/virt/snapshot/dns.server1-backup.qcow2 --disk-only --atomic --quiesce --no-metadata
    Получаем ответ
    ошибка: Операция не поддерживается: Этот QEMU не поддерживает создание снимка работающего диска

    Подумал может остановить, хорошо еще этот ДНС пока не production only test server

    virsh shutdown --domain dns.server1

    Выполняем команду
    virsh snapshot-create-as --domain dns.server1 backup-snapshot -diskspec hdb,file=/virt/snapshot/dns.server1-backup.qcow2 --disk-only --atomic --quiesce --no-metadata

    Получаем ответ: Снимок домена backup-snapshot создан
    Проверяем
    196K dns.server1-backup.qcow2
    Странно что так выходит.
    Выше писали что на CentOS пакеты старые может в этом проблема?
    Но на этом сервере уже есть 2 виртуалки рабочие и используются на полную.

    • Просто обнови QEMU - сейчас есть 2.11.0 версия
      У меня 2.9.0 и нет ошибок
      В CentOS добави epel-release repository

      • Доброе утро!
        Как ни странно он стоит epel-release repository но нет ничего нового.
        Я конечно еще проверю но не думаю что обновится.

        • Попробуй добавить репозиторий qemu-kvm-rhev.repo - здесь много вкусного для qemu
          [root@study ~]# cat /etc/yum.repos.d/qemu-kvm-rhev.repo
          [qemu-kvm-rhev]
          name=oVirt rebuilds of qemu-kvm-rhev
          baseurl=http://resources.ovirt.org/pub/ovirt-4.1/rpm/el7Server/

          mirrorlist=http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-3.5...
          enabled=1
          skip_if_unavailable=1
          gpgcheck=0

          • перепроверил репозиторий на наличие qemu-kvm
            [root@study ~]# yum whatprovides qemu-kvm
            10:qemu-kvm-1.5.3-141.el7.x86_64 : QEMU is a machine emulator and virtualizer
            Repo : base

            10:qemu-kvm-ev-2.9.0-16.el7_4.8.1.x86_64 : QEMU is a machine emulator and
            : virtualizer
            Repo : @qemu-kvm-rhev

            Просто добави репозиторий @qemu-kvm-rhev (написал выше)
            Потом установи qemu c репозиторий @qemu-kvm-rhev:
            yum --disablerepo=* --enablerepo=qemu-kvm-rhev install qemu-kvm

            • Спасибо за помощь!
              Так как Сервер уже в рабочем состоянии это ему не помешает?
              2 Виртуалки уже работают!
              Спасибо ещё раз.

              • Рад был помочь
                Конечно помешает. Надо удалить старый, и поставить новый, иначе будет конфликт, да и yum не позволит установить

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

            • Здравствуйте, у меня в процессе воспроизведения возник вопрос, разве после снепшота (в данном случаи на горячую) и после его применении на основной системе, OS не должна откатится в состояние до снепшота?

              • Нет
                В том и дело что "горячий снапшот"
                Если отследишь с virsh domblklist vm_name увидите что создаётся новый фаил где записываются изменения пока основной фаил (диск) копируется / или что там ещё делаете с ним. А когда делаете merge - то изменения записываются в основной фаил (диск) и с virsh domblklist vm_name увидите что активен стал основной диск - и он далее будет работать. И машина не откатится нигде потому что негде откатится.

                • Спасибо за ответ
                  Теперь понятно, почему VM работает как в чем не бывало, при манипуляциями с основным файлом (диском)

  19. Доброе утро Володя.
    Да вы совершенно правы!!!
    Спасибо за подсказку!!!
    На первом dns.server1 это hdb , на втором это vdb и на третьем vdb и vdc так как там два диска.
    Спасибо большое, сегодня же протестирую и напишу как это работает!

  20. Здравствуйте!
    Очень подробно ор\писано и спасибо автору.
    Но я столкнулся с той же проблемой что описал firebolt про удаление дисков.
    Команды которые я использовал следующие :
    virsh snapshot-create-as --domain dns.server1 backup-snapshot -diskspec vda,file=/virt/snapshot/dns.server1-backup.qcow2 --disk-only --atomic --quiesce --no-metadata
    virsh snapshot-create-as --domain web.server1 backup-snapshot -diskspec vda,file=/virt/snapshot/web.server1-backup.qcow2 --disk-only --atomic --quiesce --no-metadata
    virsh snapshot-create-as --domain mail.server1 backup-snapshot -diskspec vda,file=/virt/snapshot/mail.server1-backup.qcow2 --disk-only --atomic --quiesce --no-metadata

    Подскажите где я ошибся в команде.
    Единственное чего добился это что snapshot/mail.server1-backup.qcow2 заменял собой основной диск и сервер естественно после это не загружался.
    Меняя какой диск должен работать я запускал его в течении 1-2 минут.
    Данные у меня такие :

    CentOS Linux release 7.4.1708 (Core)
    virsh version
    Скомпилировано с помощью: libvirt 3.2.0
    Библиотека: libvirt 3.2.0
    API: QEMU 3.2.0
    Гипервизор: QEMU 1.5.3

    Если нужны ещё какие нибудь данные могу предоставить.

    • Володя

      Ошибка по-моему в названии устройства. Скорее всего у вас не " vda", что то из этого набора - "sda" "sdb" "hda" "hdb"

    • Володя

      Что бы выяснить что что вписать вместо "vda" виполните команду "virsh domblklist dns.server1 " , "virsh domblklist web.server1", "virsh domblklist mail.server1"

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

    • Ниже идут примеры команд:

      virsh domfsfreeze vm-name
      • Эта команда не замораживает виртуальную машину, а делает образ консистентным, то есть дает гарантию целостности файловой системы гостевой машины. На практике это выражается в том, что когда вы загрузите систему из сохраненного образа, она точно включится, и вы не получите предупреждения о предыдущем некорректном завершении работы, ведь при включении сохраненного образа работающей машины, произойдет запуск как если бы до этого было аварийное выключение. Тоже самое делает ключ --quiesce, который вы используете при создании снэпшота.

        • А разве чтобы сделать образ консистентным не нужно на какое то время заморозить машину? Нужно же остановить все дисковые операции, чтобы, к примеру, та же бд остановилась и прекратила активность.

          • Ну так вы же все равно замораживаете все дисковые операции, используя ключ --quiesce, вот в этой команде:
            # virsh snapshot-create-as --domain vm-name backup-snapshot -diskspec vda,file=/snapshot/vm-name-backup.qcow2 --disk-only --atomic --quiesce --no-metadata

            --quiesce это как бы более лаконичное представление virsh domfsfreeze vm-name, перед началом создания снапшота. И virsh domfsthaw vm-name после окончания создания.

            Выдержка из мана virsh:
            If --quiesce is specified, libvirt will try to use guest agent to freeze and unfreeze domain's mounted file systems. However, if domain has no guest agent, snapshot creation will fail. Currently, this requires --disk-only to be passed as well

            • Что-то вы меня совсем запутали. domfsfreeze я не использую, отказался от этого способа, о чем и написал в статье. Вместо него я использую snapshot-create-as. То есть в статье я привел пример отдельного использования этих двух методов. Вместе я их не применяю.

              • # virsh snapshot-create-as --domain vm-name backup-snapshot -diskspec vda,file=/snapshot/vm-name-backup.qcow2 --disk-only --atomic --quiesce --no-metadata

                тоже самое, что последовательность следующих комманд :

                #virsh domfsfreeze vm-name
                # virsh snapshot-create-as --domain vm-name backup-snapshot -diskspec vda,file=/snapshot/vm-name-backup.qcow2 --disk-only --atomic --no-metadata
                #virsh domfsthaw vm-name

                То есть, на низком уровне, опция --quiesce делает, то же самое, что и domfsfreeze и domfsthaw. Кстати даже при активации этих опций нет абсолютных гарантий, что вы получите полностью рабочую копию виртуальной машины. Система загрузится, но если в момент создания снэпшота были открытые файлы, или активные транзакции БД, то существует ненулевой шанс, что файлы или базы будут повреждены. Кажется, единственный шанс гарантированно получить рабочую копию виртуальной машины, это делать бэкап, когда машина выключена. А важные данные архивировать внутри ВМ, средствами гостевой машины.

                • Спасибо за разъяснение. Я, видимо, либо перевел неправильно, либо не допонял. Я думал процесс domfsfreeze более длительный по времени и представляет собой другой механизм.

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

  22. Внимание! Этот скрипт бэкапа очень опасный! За 2 месяца тестирования я уже три раза поудалял файлы жестких дисков своих виртуальных машин. Если формат файла не qcow2 и снапшоты не поддерживаются, если виртуалка запущена, но qemu-agent не отвечает, если... Еще какой-то момент был мною выявлен при тестировании этого скрипта, уже не помню. ...тогда хана вашей виртуалке - скрипт удалит вместо снапшота сам основной файл жесткого диска.

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

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

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

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

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

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

      • Диски удаляются безвозвратно в тех случаях, которые я описал. Это я уже проверил. В таком виде, в каком он у меня сейчас, я его в бою использовать не осмелюсь. Надо допилить. Когда сделаю, давайте, вам его отдам, опубликуете в свою статью?

  23. Михаил

    Автор спасибо, все отлично.
    Есть опыт бэкапа таким образом FreeBSD систем? Не удается повесить на guest машину qemu-agent:
    error: Guest agent is not responding: QEMU guest agent is not connected

    • Не пробовал с freebsd. Надо смотреть, поддерживает ли qemu эту систему. Если нет, то вариантов не вижу, только гасить машину и бэкапить на холодное.

  24. Денис Бутов

    Полностью не согласен с автором на счет минусов LVM.
    1) Не вижу сложностей у правлении дисками.
    2) Для оптимизации места можно использовать LVM Thin provisioning. Она использует TRIM и поэтому, предположительно, должна работать и с Windows guest https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/thinprovisioned_volumes.html
    3) В чем разница что переносить, файл или LVM раздел. Из раздела легко получается файл (и наоборот) командами DD или qemu-img convert, например вот так: qemu-img convert /dev/vg00/lvimage -O qcow2 -с file.qcow и он будет уже сжат.
    В достоинства lvm можно записать еще и возможность кэширования тома на SSD, если это необходимо.

  25. Василий

    Здравствуйте! Вопрос немного не в тему... Подскажите, как можно наиболее легко перенести виртуальную машину находящуюся на lvm (suse linux interprise 11 sp 3) на hyper-v (2016). Заранее спасибо.

    • Сходу не скажу, нет такого опыта. Но думаю решение легко нагуглится. У всех современных гипервизоров есть возможность перемещать виртуалки между собой. По крайней мере мне всегда удавалось перенести виртуальную машину на другой гипервизор, если это требовалось. Если совсем не получится, то можно пойти другим путем и использовать Veeam Agent для Linux FREE.

    • Денис Бутов

      qemu-img convert /dev/vg00/lvimage -O vhdx file.vhdx диск машины вы таким образом сконвертируете. А дальше все зависит от гостевой ОС.

  26. Теперь столкнулся со следующей проблемой, при попытке сделать снапшот командой:

    [root@server-kvm2 ~]# virsh snapshot-create-as --domain CentOS-7 CentOS-7-snapshot -diskspec vda,file=/snapshot/vm-name-backup.qcow2 --disk-only --atomic --quiesce --no-metadata

    Получаю ошибку: Operation not supported: live disk snapshot not supported with this QEMU binary

    Результат поисков, говорит, что базовые пакеты в CentOS урезанные и нужно подключать отдельный репозиторий "oVirt rebuilds of qemu-kvm-rhev", так ли это?

    • Скорее всего да. В репозиториях centos все очень старое. Из-за этого я использую для kvm debian. Так просто проще и меньше нюансов ненужных.

      • Можно поставить epel-repository (yum install epel-release) и взять более новые версии
        Сам на Centos7, # virsh version
        Using library: libvirt 3.2.0
        Using API: QEMU 3.2.0
        Running hypervisor: QEMU 2.9.0

  27. Большое спасибо Вам за статью! Более полезного материала ни где больше не встречал.

    Однако руководствуясь Вашими примерами у меня возникли проблемы с qemu-guest-agent. После настройки сhannel Device и попытки запуска qemu-guest-agent сервис не запускается, перепроверял как описано в официальном документации RedHat. Выходит ошибка:

    Jun 13 12:05:37 server-kvm7 polkitd[904]: Registered Authentication Agent for unix-process:176099:143685278 (system bus name :1.6226 [/usr/bin/pktty
    Jun 13 12:07:07 server-kvm7 systemd[1]: Job dev-virtio\x2dports-org.qemu.guest_agent.0.device/start timed out.
    Jun 13 12:07:07 server-kvm7 systemd[1]: Timed out waiting for device dev-virtio\x2dports-org.qemu.guest_agent.0.device.
    -- Subject: Unit dev-virtio\x2dports-org.qemu.guest_agent.0.device has failed
    -- Defined-By: systemd
    -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
    --
    -- Unit dev-virtio\x2dports-org.qemu.guest_agent.0.device has failed.
    --
    -- The result is timeout.
    Jun 13 12:07:07 server-kvm7 systemd[1]: Dependency failed for QEMU Guest Agent.
    -- Subject: Unit qemu-guest-agent.service has failed
    -- Defined-By: systemd
    -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
    --
    -- Unit qemu-guest-agent.service has failed.
    --
    -- The result is dependency.
    Jun 13 12:07:07 server-kvm7 systemd[1]: Job qemu-guest-agent.service/start failed with result 'dependency'.
    Jun 13 12:07:07 server-kvm7 systemd[1]: Job dev-virtio\x2dports-org.qemu.guest_agent.0.device/start failed with result 'timeout'.
    Jun 13 12:07:07 server-kvm7 polkitd[904]: Unregistered Authentication Agent for unix-process:176099:143685278 (system bus name :1.6226, object path

    Подскажите, какие дополнительные настройки Вы проделывали, чтобы запустить qemu-guest-agent ?

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

      • Разобрался, по ошибке запускал qemu-guest-agent со стороны KVM сервера, а не со стороны виртуального хоста.

        Ещё раз спасибо за статью!

    • Валерий

      У меня та же проблема. Но стартую на вирте.

      • Валерий

        Надо читать инструкции. И строго следовать им.
        Сперва ставим в настройках сервера, что есть GA, а потом уже на госте инсталлируем пакет.
        Поставил галку, снёс GA, установил GA.

  28. Напишите пожалуйста, статью на тему гипервизора KVM на CentOS 7/Debian 8, с установки гипервизора до загрузки виртуальных машин, удаленного к ним подключения, установки на них ос...!Настройка сетей, vlan, vSwitch!

  29. На Центос7 вроде не будет работать там libvirt урезанный.

    • На Centos 7 не проверял.

      • Я проверял, надо QEMU обновлять, иначе не работает. У меня Цент7 и КВМ основная система.

        • На Centos как обычно, все очень старых версий. Нужно ставить более свежие версии QEMU и libvrt. Возможность делать снепшоты описанным способом появилась не так давно, по сравнению с возрастом гипервизора. Года 2-3 назад, точно не помню. Где-то встречал об этом упоминание.

          • Windows я так не стал бы сохранять. Не надежно ИМХО, как там теневое копирование прошло или не прошло, неизвестно. А для Linux очень не плохо расписано здесь: https://habrahabr.ru/post/242213/. С Windows в KVM это проблема. Пока хорошего и надежного решения я не вижу. Может если только штатными средствами из под самой Windows сохранять на Linux шару samba, а оттуда уже бекапить, но тоже не очень.

  30. А на какой системе вы экспериментировали? Кто хост?
    Спасибо.

  31. Андрей

    Здравствуйте!
    Как специалист пощупавший n-систем виртуализации на какой из них посоветуете остановиться. Сам пользуюсь Hyper-V. Но думаю может есть смысл перейти на что то другое, особенно когда сервер нужно в дата-центре разместить. Спасибо.

    • Я сам больше всего люблю hyper-v, особенно в составе полноценного windows server. Мне трудно сказать, что лучше. Если есть аппаратный рейд, то можно использовать hyper-v. Если рейда нет совсем, то обязательно настраиваю программный mdadm и использую либо xenserver, либо kvm. Они одинаково неудобны :) Но зато бесплатно и с надежным рейдом. Не рассматриваю esxi вообще, так как платные версии очень дорогие, а бесплатная малофункциональна.

  32. Гм... А у редхата почитать никак?

  33. Это я к тому, что после миграции средствами KVM исходный файл не удаляется. И с него вполне можно делать backup. В proxmox исходный файл удаляется.

  34. Вообще то KVM уже умеет живую миграцию виртуалок из коробки ) Попробуйте на 2х серверах с одинаковым комплектом ПО одной версии. Авторизация между серверами по SSH ключами. У меня в Gentoo работает. На счет Debian & CentOS не скажу ... ПО не свежее.

    У меня так:
    Linux 4.4.26-gentoo x86_64
    libvirt - 2.1.0-r2
    qemu - 2.7.0-r5

    На отдельной машине:
    virt-manager - 1.3.2

    • Кстати да, сессии пользователей все равно рвутся ... даже у proxmox. Есть решение от VmWare, но это совсем другая история и бабки.

    • Так миграция, это же не бэкап. Я ее и не проверял. Она отлично работает в кластерах proxmox, это видел.

  35. посмотрите на veeam agent for linux, есть снапшоты, всё намного проще и бесплатно.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar