Магия виртуализации: вводный курс в proxmox ve

Какой диск выбрать в 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 без остановки виртуальной машины.

Тестирование FIO

Тестовый хост — Pentium Silver J5005, 8GB Ram, mdadm RAID1 2x2Tb Seagate HDD (подключены к SoC AHCI), OCZ Vertex2 EX 100Gb SSD Cache (подключен к ASMedia ASM1061), transparent_hugepage выключены. FIO под Windows Server 2008R2 скачанный отсюда: https://bluestop.org/fio/ у меня не заработал. Все время при запуске падал — fio.exe has stopped working.

Очевидно, это проблемы со сборкой, потому что FIO скачанный отсюда: https://ci.appveyor.com/project/axboe/fio/build/job/1q9lno301yq74mxc/artifacts заработал без проблем.

Тесты запускались такими командами:

fio.exe   --name=baseline --rw=randread --direct=1 --size=1g --iodepth=32 --blocksize=4096 --thread --ioengine=windowsaio --filename=E\:fiotest --name=hddBaseline --stonewall
fio.exe   --name=baseline --rw=randwrite --direct=1 --size=1g --iodepth=32 --blocksize=4096 --thread --ioengine=windowsaio --filename=E\:fiotest --name=hddBaseline --stonewall

То есть тест блоками по 4k, случайные чтение и запись, глубина очереди 32, размер тестового файла — 1Gb, без кеширования на уровне Windows (direct=1).

Тесты запускались по три раза, чтобы тестовый файл попал в SSD-кеш.

Результаты тестирования fio

• Предсказуемо, стабильно высокие результаты при минимальной загрузке VCPU показал вариант, когда включено кеширование на LVM и Proxmox в режимах WriteBack. Его недостатком можно считать вероятность потери данных при выходе из строя SSD или отключении питания.
• Не сильно отстает конфигурация с кешированием только на SSD в режиме WriteBack. От выхода из строя SSD можно защититься, использовав два накопителя в зеркальном массиве.
• Разница между форматами qcow2 и raw несущественна, при большей функциональности qcow2.
• В режимах Writeback на уровне proxmox без кеширования на SSD на уровне lvm, скорость записи очень нестабильна. Она может быть как довольно высокой (3000-4000 IOPS), так и довольно низкой (500-1000 IOPS) и меняется произвольным образом.
• Режимы кеширования ProxMox WriteThrough — существенно ускоряют чтение (в 100 раз), но замедляют запись (в 5-20 раз) по сравнению с режимами без кеширования и writeback.
• Возможно, на данной системе можно добиться более высоких результатов, если подключить cache SSD к SoC AHCI. Вот тут есть тестирование производительности разных контроллеров: http://www.thg.ru/storage/vliyaniye_kontrollera_na_skorost_ssd/print.html и ASMedia ASM1061 там далеко не лидер по производительности, а сам SSD по паспорту способен выдавать до 70000 IOPS. C PCI-E SSD результаты должны быть еще интереснее.

Скрипт для автоматического бэкапа виртуальных машин 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.

Other suggested pages

• Acpi setup
• Windows 2003 guest best practices
• Paravirtualized Network Drivers for Windows
• Paravirtualized Block Drivers for Windows

Fake Raid specific issues

If you have a physical PC to clone and you use a method that requires access to the file system (like with FSArchiver) from GNU/Linux, you can be in troubles if you have a so called «fake raid», that is a raid created using the motherboard bios configuration.
Let’s say we have a RAID1. In short GNU/Linux (i.e. SystemRescueCd) sees the device, sees that the disks have some Raid metadata, and when you try to mount them it uses the «mdadm» libraries, that can’t work since that raid is totally different.
To avoid this, you have to boot with the boot parameter ‘nodmraid’.
For example, if you boot with SystemRescueCd, at the menu where you can choose what to boot hit «tab» key
You will have something like:

ifcpu64.c32 rescue64 scandelay=1 -- rescue32 scandelay=1

modify it (on both sides of the «—» separator) like this:

ifcpu64.c32 rescue64 scandelay=1 nodmraid -- rescue32 scandelay=1 nodmraid

Physical Linux server to Container

Take a look at these links if you want to migrate something that is not a Linux server to containers:

Here we explain how to do a Physical-to-Virtual migration from a Linux installation into a Proxmox VE LXC container.

Log into the machine you want to migrate into a PVE container as root and first stop any running services such as web servers or databases e.g. `systemctl stop apache2`, `systemctl stop mysql` etc. You need to be root (or run with sudo) so that tar can access and archive all files correctly using commands such as:

# cd /
# tar -cvpzf backup.tar.gz --exclude=/backup.tar.gz /

The tar -p switch is critical for preserving file permissions. Copy this tarball into the container templates cache directory on the PVE server which defaults to /var/lib/vz/template/cache . You may then create a new container using this tarball as a template via the web UI or using pct. If you choose to use the PVE web UI to create the new container, be sure to uncheck the ‘Unprivileged Container’ option (under the General options tab) else you are likely to run into file ownership issues. Creating a new privileged i386 container on ZFS storage with container ID 101 using pct would look something like this:

# pct create 101 local:vztmpl/backup.tar.gz -arch i386 -hostname your.hostname.here -onboot 1 -rootfs local-zfs:300 -memory 4096 -cores 2

Note this command doesn’t configure networking. I enable networking after creating the container via the Proxmox web interface.

Move OpenVZ containers to Proxmox VE

OpenVZ is depreacated and was superseeded by the Linux Container (LXC) project — which is using mainline kernel features.

You can move existing OpenVZ containers (CT) with vzdump to Proxmox VE.
Then check out the Convert OpenVZ to LXC article.

Convert Windows to use (VirtIO) SCSI (KVM)

This procedure is required to get Windows to load and active the SCSI drivers, once active you can switch the disk and it should «Just Work».

Заключение

Я выполнил обновление Proxmox VE до 7-й версии на своем домашнем тестовом гипервизоре. Никаких проблем в процессе не возникло. Тем не менее, не рекомендую обновлять прод, пока не выйдет хотя бы версия 7.1. Торопиться в таких делах нет никакого смысла. Можно вообще не обновляться, если вам не нужны нововведения. Никаких проблем не будет, если вы останетесь на старой версии, пока она еще поддерживается.

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

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