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

Введение

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

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

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

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

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

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

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

Начало работы

Настроить дисковые накопители

/dev/sda/dev/sdb/dev/sdbext4

1. Размечаем диск, создавая новый раздел:
2. Нажимаем клавишу o или g (разметить диск в MBR или GPT).
3. Далее нажимаем клавишу n (создать новый раздел).
4. И наконец w (для сохранения изменений).
5. Создаем файловую систему ext4:
6. Создаем директорию, куда будем монтировать раздел:
7. Открываем конфигурационный файл на редактирование:
8. Добавляем туда новую строку:
9. После внесения изменений сохраняем их сочетанием клавиш Ctrl + X, отвечая Y на вопрос редактора.
10. Для проверки, что все работает, отправляем сервер в перезагрузку:
11. После перезагрузки проверяем смонтированные разделы:

/dev/sdb1/mnt/storage

Добавить новое хранилище в Proxmox

ДатацентрХранилищеДобавитьДиректория

• ID — название будущего хранилища;
• Директория — /mnt/storage;
• Содержимое — выделяем все варианты (поочередно щелкая на каждом варианте).

Добавить

Создать виртуальную машину

1. Определяемся с версией операционной системы.
2. Заранее закачиваем ISO-образ.
3. Выбираем в меню Хранилище только что созданное хранилище.
4. Нажимаем Содержимое ➝ Загрузить.
5. Выбираем из списка ISO-образ и подтверждаем выбор нажатием кнопки Загрузить.

1. Нажимаем Создать VM.
2. Заполняем поочередно параметры: Имя ➝ ISO-Image ➝ Размер и тип жесткого диска ➝ Количество процессоров ➝ Объем оперативной памяти ➝ Сетевой адаптер.
3. Выбрав все желаемые параметры нажимаем Завершить. Созданная машина будет отображена в меню панели управления.
4. Выбираем ее и нажимаем Запуск.
5. Переходим в пункт Консоль и выполняем установку операционной системы точно таким же образом, как и на обычный физический сервер.

Настроить автозапуск

1. Щелкаем по названию нужной машины.
2. Выбираем вкладку Опции ➝ Запуск при загрузке.
3. Ставим галочку напротив одноименной надписи.

Start/Shutdown order

Step 3: Rename/Move the disk

This step is only necessary if the disk contains the VM ID, which includes most
storage types (iSCSI-Direct is an example where you can skip this step).

All of the examples below assume there’s no disk on the target storage for that
VM already. If there is, increase the trailing number so that the name is
unique. Eg. if you already have a vm-2300-disk-1 and
vm-2300-disk-2, then
use vm-2300-disk-3 instead.

For directory based storages (Directory, NFS, Gluster):

Find the path and rename the file.
For example, assuming the disk line was: local:400/vm-400-disk-1.qcow2:

# pvesm path 'local:400/vm-400-disk-1.qcow2'
/var/lib/vz/images/400/vm-400-disk-1.qcow2
# mkdir -p /var/lib/vz/images/2300
# mv /var/lib/vz/images/400/vm-400-disk-1.qcow2 /var/lib/vz/images/2300/vm-2300-disk-1.qcow2

For LVM (thin) storages:

Use

# lvs
(...)
vm-400-disk-1 pve Vwi-aotz--   42.00g

to find the disk’s name on the host (mala in this example). It must appear in the source VM’s config as well. Thus, the following command should give a similar result.

# cat /etc/pve/nodes/mala/qemu-server/400.conf | grep lvm
scsi1: local-lvm:vm-400-disk-1,size=42G

There are two crucial steps to move the disk. The first is renaming the logical volume according to the target VM.

# lvrename pve/vm-400-disk-1 pve/vm-2300-disk-1
Renamed "vm-400-disk-1" to "vm-2300-disk-1" in volume group "pve"

The second is to adapt the VM config files. Delete the line for this disk from the source VM config

# sed -i.backup '/vm-400-disk-1/d' /etc/pve/nodes/mala/qemu-server/400.conf

and add it to the one of of the target VM 2300, with changes according to lvrename. This means

# echo "scsi1: local-lvm:vm-2300-disk-1,size=42G" >> /etc/pve/nodes/mala/qemu-server/2300.conf

For ZFS:

Assuming the storage is named tank, and the pool property is
tank/host/vms, and the disk line was: tank:vm-400-disk-1:

# zfs rename tank/host/vms/vm-400-disk-1 tank/host/vms/vm-2300-disk-1

For ceph:

Assuming the pool is named rbd and the disk line was:
myceph:vm-400-disk-1, and there’s a monitor at the address 1.2.3.4, we
use following command:

# rbd -m 1.2.3.4 -n client.admin --keyring /etc/pve/priv/ceph/myceph.keyring --auth_supported cephx mv rbd/vm-400-disk-1 rbd/vm-2300-disk-1

If you only have one ceph storage, local to your PVE cluster, or have a local
ceph configuration for easier maintenance you might be able to shorten this
command to just:

# rbd mv rbd/vm-400-disk-1 rbd/vm-2300-disk-1

Introduction

storage pool type: lvm

LVM is a thin software layer on top of hard disks and partitions. It can be used to split available disk space
into smaller logical volumes. LVM is widely used on Linux and makes managing hard drives easier.

Another use case is to put LVM on top of a big iSCSI LUN. That way you can easily manage space on
that iSCSI LUN, which would not be possible otherwise, because the iSCSI specification does not define a
management interface for space allocation

Configuration

The LVM backend supports the common storage properties content, nodes, disable, and the following LVM specific properties:

• vgname
• base
• saferemove
• saferemove_throughput

General LVM advantages

LVM is a typical block storage, but this backend does not support snapshot and clones. Unfortunately,
normal LVM snapshots are quite inefficient, because they interfere all writes on the whole volume group
during snapshot time.

One big advantage is that you can use it on top of a shared storage, for example an iSCSI LUN. The backend
itself implement proper cluster wide locking.

Note: The newer LVM-thin backend allows snapshot and clones, but does not support shared storage.

Создание нового образа диска — qemu-img create

qemu-img create создает новый образ диска в базовой операционной системе для гостевой виртуальной машины. Формат команды:

qemu-img create -f fmt -o options size fname

где:

fmt — формат образа диска. В kvm в Ubuntu можно создать образы дисков следующих форматов: vvfat vpc vmdk vhdx vdi sheepdog sheepdog sheepdog rbd raw host_cdrom host_floppy host_device file qed qcow2 qcow parallels nbd nbd nbd dmg tftp ftps ftp https http cow cloop bochs blkverify blkdebug.
Из всего этого разнообразия реально используется только 4 формата:

• raw Файл содержащий как бы точную копию физического диска. Переводится как «сырой».  Данные пишутся как есть без всякой обработки и без дополнительной служебной информации. Основным преимуществом данного формата являются максимальная производительность дисковой подсистемы среди других образов за счет отсутствия служебной информации и дополнительных действий в моменты чтения/записи. Универсальность формата позволяет использовать RAW-диски  под управлением других гипервизоров(Xen, VMware).
  К минусам можно отнести невозможность создавать снапшоты а так же необходимость выделения для файла-образа всего объема дискового пространства указанного в параметре size, что в прочем в некоторых случаях избавляет от фрагментации файла-образа за счет единовременного выделения всего объема.
• qcow2 «Родной» формат  эмулятора QEMU с поддержкой сжатия, снапшотов и шифрования. Кроме того qcow2 образ занимает столько места, сколько реально занимают данные, вне зависимости от размера создаваемого при соз8589934592дании. Наиболее часто используемый и рекомендуемый формат.
  Производительность дисков в формате QCOW2 несколько уступает дискам в формате RAW. Диски в формате QCOW2 в большей степени подвержены фрагментации за счет постепенного а не едино разового выделения всего объема на физическом диске.
• vdi Образ виртуальных машин, поддерживаемый VirtualBox.
• vmdk Образ виртульных машин VMware.

size — размер создаваемого диска. Число и единица измерения — (kilobyte), (megabyte), (gigabyte), или (terabyte).

fname — имя файла образа диска.

$qemu-img create -f qcow2 -o size=8G /images/ca.img
Formatting '/images/ca.img', fmt=qcow2 size=4294967296

 $ qemu-img info /images/ca.img
image: ca.img
file format: qcow2
virtual size: 8.0G (8589934592 bytes)
disk size: 2.7G
cluster_size: 65536
Format specific information:
 compat: 0.10

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

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

1. Виртуальные машины выходят во внешний мир через сам хост kvm, на котором настроен NAT. Этот вариант вам будет доступен сразу после установки kvm. Ничего дополнительно настраивать не надо, так как сетевой бридж для этого virbr0 уже будет добавлен в систему. А в правилах iptables будет добавлен MASQUERADE для NAT.
2. Одна из виртуальных машин превращается в шлюз и через нее осуществляется доступ во внешний мир для всех виртуальных машин. Наиболее гибкий способ управления сетью для vm, но в то же время требует больше времени на настройку и набор знаний по работе с сетями.
3. Для виртуальных машин 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

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

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

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

Конвертация дисков qcow2 -> lvm в KVM (Proxmox)

Занимался на днях переносом виртуальных машин с обычного kvm гипервизора на proxmox. На исходном гипервизоре диски виртуальных машин были в формате qcow2. Я решил заодно сконвертировать диски из qcow2 в lvm и написать заметку об этом, чтобы не забыть.

Для тех, кто не знает, в чем разница между разными форматами дисков в гипервизоре KVM, предлагаю почитать об этом в моей статье на тему бэкапа виртуальных машин kvm. В общем случае, сконвертировать диски qcow2 в lvm можно следующим образом. Сначала преобразуем их в raw формат с помощью qemu-img.

# qemu-img convert /mnt/data/images/102/vm-102-disk-0.qcow2 -O raw /mnt/data/images/102/vm-102-disk-0.raw

1	# qemu-img convert /mnt/data/images/102/vm-102-disk-0.qcow2 -O raw /mnt/data/images/102/vm-102-disk-0.raw

Далее raw образ переносим на новый сервер. На нем же к виртуальной машине подключаем новый диск из lvm хранилища такого же размера, как raw образ. Далее в консоли proxmox выполняем конвертацию в lvm с помощью обычного dd.

# dd if=/mnt/data/images/102/vm-102-disk-0.raw of=/dev/pve/vm-102-disk-0

1	# dd if=/mnt/data/images/102/vm-102-disk-0.raw of=/dev/pve/vm-102-disk-0

Все то же самое можно сделать одной командой на новом сервере, перенеся туда диск в формате qcow2.

# qemu-img convert -p -n -f qcow2 -O raw /mnt/data/images/102/vm-102-disk-0.qcow2 /dev/pve/vm-102-disk-0

1	# qemu-img convert -p -n -f qcow2 -O raw /mnt/data/images/102/vm-102-disk-0.qcow2 /dev/pve/vm-102-disk-0

Последняя команда qemu-img будет работать медленнее, чем dd из предыдущего примера. Каким способом конвертировать — решать вам. Не забудьте изменить путь к lvm разделу. В моем случае он /dev/pve/vm-102-disk-0, у вас имя группы томов может быть другим, не pve.

Я описал общий случай для любого гипервизора KVM. Но конкретно в proxmox это можно сделать проще. Если вам нужно конвертировать qcow2 в lvm на этом же хосте, то достаточно просто через web интерфейс выбрать Move disk и указать в качестве storage хранилище с LVM. Proxmox сам конвертирует диск с помощью того же qemu-img.

Конвертация дисков qcow2 -> lvm в KVM (Proxmox)

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

1. Переносим qcow2 диск со старого гипервизора на новый.
2. На новом создаем виртуальную машину, подключаем к ней диск любого размера на обычном хранилище в виде директории.
3. Запоминаем имя этого диска и удаляем его. Вместо него переносим диск со старого гипервизора и указываем ему такое же имя.
4. Запускаем виртуалку на новом сервере, убеждаемся, что она работает, выключаем.
5. Через web интерфейс proxmox переносим диск на storage с lvm. Proxmox сам выполнит конвертацию.

Я по такой схеме переносил как linux машины, так и windows. Проблем не было. Единственное, надо не забыть зайти через консоль в windows машину и проверить сетевые настройки. Нужно будет заново настроить сеть, иначе по rdp не подключиться. После переноса сетевой адаптер поменяется.

Ускорение дисковой подсистемы Qemu KVM в Linux +35

• 25.03.20 02:48

•
inetstar
•
#493696
•
Хабрахабр

•
Tutorial

•

•

8900

Блог компании RUVDS.com, Высокая производительность, Виртуализация, Настройка Linux, Накопители

Иногда я берусь за различные задачи по настройке серверов. Некоторое время назад ко мне обратился владелец небольшой хостинговой компании, с интересной проблемой. Он хотел бы на своих серверах, где уже стоял Ubuntu 18.04, запускать виртуальные машины с Windows под KVM.
Однако проведённое им тестирование показало, что дисковая система KVM прилично отставала от показателей, которые у него были под Hyper-V. Он хотел раскочегарить qemu на своих Ubuntu серверах, чтобы избежать закупок дорогих серверных лицензий Windows (бесплатная версия Microsoft Hyper-V Server не устраивала из-за своих ограничений).

0. Диспозиция

Windows 10 LTSC	Hyper-V 2 CPU	KVM 2 CPU

О размере тестового файла для CrystalDiskMarkВнимательный читатель может заметить, что использовались разные по размеру области для тестирования от 100МБ до 4ГБ. Дело в том, что размер области очень влияет на время выполнения теста: чем больше область, тем длиннее шёл тест.
Однако, так как каждый раз виртуальная машина запускалась заново, кеш Windows сбрасывался и не оказывал влияние на результаты. Результаты для области 100МБ и 4ГБ отличались в пределах погрешности, но время было в 40 раз больше.
Тестирований за время настройки было проведено огромное количество, чтобы задача не затянулась на месяцы, основная часть испытаний была проведена с областями размером 100МБ-1ГБ. И только решающие испытания были проведены с областями 4ГБ.

4. Добавляем в каждую виртуальную машину выделенный поток для обслуживания IO

<iothreads>1</iothreads>
<disk type=’block’ device=’disk’>
<driver name=’qemu’ type=’raw’ cache=’none’ io=’threads’ iothread=’1′/>
<source dev=’/dev/win/terminal’/>
<target dev=’vda’ bus=’virtio’/>
<boot order=’2’/>
<address type=’pci’ domain=’0x0000′ bus=’0x04′ slot=’0x00′ function=’0x0’/>
</disk>

7. Результаты после применения всех твиков

Hyper-V 2 CPU	KVM 2 CPU	KVM 4 CPU

KVM из коробки 2 CPU	KVM после твиков 2 CPU

Основные элементы успехаЗамеченные ошибки направляйте в личку. Повышаю за это карму.

Благодарности

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

Конвертация виртуальной машины Windows.

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

Теперь переходим непосредственно к конвертации. В консоли хоста Proxmox выполним команду:

Shell

qemu-img convert -f vmdk </path/to/disk.vmdk> -O raw /mnt/pve/hdd1/images/101/disk0.raw -p

1	qemu-img convert-fvmdk<pathtodisk.vmdk>-Orawmntpvehdd1images101disk0.raw-p

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

Запустится процесс конвертации диска.

После завершения конвертации нужно изменить конфиг виртуальной машины. Для этого открываем в редакторе файл конфигурации ВМ(в нашем случае ВМ имеет ID 101):

Shell

nano /etc/pve/qemu-server/101.conf

1	nanoetcpveqemu-server101.conf

Если узел Proxmox находится в кластере, путь до файла конфигурации будет выглядеть так:

Shell

nano /etc/pve/nodes/<node-name>/qemu-server/101.conf

1	nanoetcpvenodes<node-name>qemu-server101.conf

В строке ide0 укажем наш сконвертированный диск:

Сохраните изменения. Теперь можно запустить виртуальную машину.

Настройка ВМ после конвертации.

После конвертации необходимо проделать следующие действия: удалить VMtools(если они установлены) и установить необходимые драйвера.

Удаление VMtools производится через стандартную оснастку «Программы и компоненты».

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

Для установки драйверов потребуется скачать и подключить к ВМ образ с драйверами. Скачать его можно из официального источника..

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

Это самый простой способ установить необходимые драйвера. Также, не лишним будет установить гостевой агент из папки guest-agent.

Теперь нам нужно переключить системный диск с устаревшего контроллера IDE на Virtio. Для этого выключаем виртуальную машину и вносим изменения в конфиг файл, который мы уже редактировали. Приведем его к следующему виду:

Обратите внимание, что нужно указать первым загрузочным устройством наш системный диск. (Думаю, что загрузочный диск, всё же, лучше разместить на шине 0, поэтому нужно заменить в файле конфигурации virtio1 на virtio0)

Диски, созданные при создании ВМ, теперь можно удалить.

После этого можно включать виртуальную машину и использовать по назначению.

Troubleshooting and known issues

Thin Overprovisioning

In a LVM_thin pool there is no space limit when defining LVM volumes in it — regardless if these volumes are virtual disks for containers or virtual machines or just volumes for any other purpose defined by «lvcreate». If the total amount of all defined logical volume size within a thin pool exceeds the physical size of the pool it is called «overprovisioning».

Attention! You can never use more space for data than physically is available! Unfortunately in case of reaching the space limit no direct warning or error message occurs. At the user interface — e.g. inside a virtual machine — it looks like all logical space can be used; but when exceeding the physical limit the data are corrupt!

Therefore it is recommended

— to avoid overprovisioning; or at least, if not possible

— to check regularly via

lvs 

the actual physical usage.

See also «Automatically extend thin pool LV» in

Clonezilla Live CDs

This method is fast, reliable and OS independent as it uses live CDs.

• Now, boot the physical host with Clonezilla, go for beginner mode and select device — device and then remote, just follow the wizard
• On the Proxmox VE host, prepare a KVM guest, make sure you got a big enough IDE disk assigned (add 1 GB extra to be on the safe side) and also boot this KVM guest with the live CD and execute a shell.
• Become root and run fdisk (fdisk /dev/sda/) to make sure that sda is here, exit fdisk with ‘w’. this was essential.
• Now enter all commands from the wizard on the source server tells you (configure network and request the copy process)
• After success (the wizard just copies the data, means I got a 80 GB disk but only 5 GB data on it so it was just a few minutes for the whole process on a gigabit network) just change the boot device to the hard disk and start the VM. Windows will install all needed drivers automatically, just the Intel NIC drivers for e1000 must be loaded from ISO (I got one big driver ISO from Intel containing all NIC drivers).

Конвертация образа диска qemu-img convert

Для конвертации одного формата образа в другой используется опция convert:

qemu-img convert -c -f fmt -O out_fmt -o options fname out_fname

где:

-c — компрессия (сжатие) целевого диска. Компрессию поддерживают только и форматы.

-f fmt — формат исходного диска, в большинстве случаев хорошо определяется автоматически.

-O out_fmt — формат целевого диска

-o options — куча опций. Чтобы узнать, какие опции допустимы для данной конвертации можно ввести:

$ qemu-img convert -O qcow2 ca.img ca1.img -o ?
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
encryption Encrypt the image
cluster_size qcow2 cluster size
preallocation Preallocation mode (allowed values: off, metadata)
lazy_refcounts Postpone refcount updates

FreeNAS

Those are the necessary steps to migrate a Ubuntu Bionic VM from FreeNAS 11.2 to Proxmox VE 6.2-1.
The VM in FreeNAS was created with the following parameters

• Boot Loader Type: UEFI
• Guest OS: Ubuntu Bionic
• Disk
  • Disk Mode: AHCI
  • Zvol: test/ubuntu-1xmtpt

Check the name of your zvol by going to Virtual Machines → Options of the VM ⋮→ Devices → Options of your disk ⋮ → Edit → Zvol

Preparation in FreeNAS

1. Create a shared directory in Sharing → Unix (NFS) Shares with path .
2. Enable SSH in Services & edit the SSH service (Actions) to allow password login for root
3. Copy the zvol to the shared directory
   1. Log in to FreeNAS via SSH

      ssh [email protected]

   2. Copy the zvol to the shared directory

      dd if=/dev/zvol/test/ubuntu-1xmtpt of=/mnt/test/ubuntu.raw bs=1m

Importing to Proxmox VE

1. Create a virtual machine (here vmid is 103) in Proxmox VE. Make sure to set BIOS to OVMF (this is UEFI).
2. Delete the disk that was created in step 1.
3. Create a directory
4. Mount the shared directory from FreeNAS

    sudo mount -t nfs 192.168.31.241:/mnt/test /home/user/freenas

5. Import the image of the FreeNAS VM to the Proxmox VE VM as unused disk (vmid 103, storage local)

   qm importdisk 103 /home/user/freenas/ubuntu.raw local --format qcow2

6. In the GUI of Proxmox VE:
   1. Go to the hardware view of your new virtual machine
   2. Set the display to spice
   3. Double click on the unused disk to attach it and choose Virtio as bus
   4. Go to the options view of your new virtual machine
   5. Choose your new virtio disk as bootdisk

Заключение

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

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

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