Установка kvm на freebsd

Обновлено: 02.07.2024

Вы заказали виртуальный сервер с системой виртуализации KVM и вам нужно знать как его запустить в работу.

Решение:

При заказе виртуального сервера VDS-KVM система не устанавливается автоматически. Нужно обязательно использовать VNC консоль панели управления для выполнения процедуры установки.

Вы можете использовать для создания виртуального сервера две возможности:

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

Виртуализация KVM

KVM можно считать относительной новинкой. В настоящее время существуют множество систем виртуализации - OpenVZ, Xen, VMWare, Virtualbox, но KVM считается наиболее перспективной системой. KVM отличается принципиальной простотой, малыми накладными расходами на работу гипервизора и рекордной производительностью.

Здесь речь идет о виртуальных серверах на Linux. Для Windows и FreeBSD смотрите отличия в описании шаблонов этих систем.

Пакеты программ

При создании шаблона операционной системы использован минимальный набор пакетов.

Используется стандартный набор репозиториев пакетов.

ssh - OpenSSH SSH сервер и клиент (программы для удаленной работы по защищенному каналу) wget - Не интерактивная программа для скачивания из сети. mc - Midnight Commander - Визуальная оболочка для Unix-подобных систем.

Разметка диска

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

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

Если вы используете размер диска более 20GB, то у вас после установки есть свободное место и возможности.

Сеть и защита

Для доступа по SSH используется нестандартный порт: 42222 При первом запуске системы производится регенерация индивидуальных ключей SSH для каждого виртуального сервера. Пароль переданный Вам по почте действует только для первого подключения и установки нового пароля. По вашему запросу мы можем ограничить ширину канала для вашего сервера (Traffic shaping).

Драйверы и производительность

По умолчанию используются драйверы эмуляции устройств:

NIC: Realtek RTL-8139 100Mb (доступен по запросу Intel Pro 1Gb)

По запросу доступны экспериментальные драйверы паравиртуализации virtio. Это может дать заметный прирост в производительности диска и сети, но может снизить надежность.

Замена NIC: Realtek RTL-8139 100Mb на Intel Pro 1Gb или Virtio дает заметный прирост, но не забудьте, что у вас лимит на месячный трафик и вероятно использование 100 мбит вполне достаточно.

Использование драйвера Virtio для диска, для некоторых систем, требует переустановки системы с инсталляционного ISO.

Установка Windows с драйвером диска virtio производится платно.

Стандартный шаблон при включении драйвера диска virtio может не видеть диск и работать не будет.

Ограничения

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

Вы сами следите за своим паролем.

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

Пароль

В почтовом уведомлении о создании сервера вы получили имя для логина и пароль, например vmuser123 Но это логин не для сервера, а в панель управления

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

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

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

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

Видеоинструкция

Первый запуск виртуального сервера и начальные действия пользователя.

Действия после запуска сервера в работу

Высокая изоляция виртуального сервера в KVM не позволяет выполнить любые действия из панели управления виртуальным сервером. Потому некоторые действия по настройке придется выполнить самостоятельно непосредственно через консоль сервера.

Примечание: Описанные ниже действия были проверены мной на Ubuntu Linux 14.04, но по идее будут во многом справедливы как для других версий Ubuntu, так и других дистрибутивов Linux. Все должно работать как на десктопе, так и на сервере, доступ к которому осуществляется по SSH.

Установка KVM

Проверяем, поддерживается ли Intel VT-x или AMD-V нашим процессором:

Если что-то нагреполось, значит поддерживается, и можно действовать дальше.

sudo apt-get update
sudo apt-get install qemu-kvm libvirt-bin virtinst bridge-utils

Что где принято хранить:

Теперь, когда KVM установлен, создадим нашу первую виртуалку.

Создание первой виртуалки

В качестве гостевой системы я выбрал FreeBSD. Качаем ISO-образ системы:

Управление виртуальными машинами в большинстве случаев производится при помощи утилиты virsh:

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

Смотрим список доступных сетей:

Просмотр информации о конкретной сети (с именем default):

Смотрим список доступных оптимизаций для гостевых ОС:

Итак, теперь создаем виртуальную машину с 1 CPU, 1 Гб RAM и 32 Гб места на диске, подключенную к сети default:

sudo virt-install \
--virt-type =kvm \
--name freebsd10 \
--ram 1024 \
--vcpus = 1 \
--os-variant =freebsd8 \
--hvm \
--cdrom = / var / lib / libvirt / boot / FreeBSD- 10.2 -RELEASE-amd64-disc1.iso \
--network network =default, model =virtio \
--graphics vnc \
--disk path = / var / lib / libvirt / images / freebsd10.img, size = 32 , bus =virtio

Вы можете увидеть:

WARNING Unable to connect to graphical console: virt-viewer not
installed. Please install the 'virt-viewer' package.

Domain installation still in progress. You can reconnect to the console
to complete the installation process.

Это нормально, так и должно быть.

Затем смотрим свойства виртуалки в формате XML:

Тут приводится наиболее полная информация. В том числе есть, к примеру, и MAC-адрес, который понадобятся нам далее. Пока что находим информацию о VNC. В моем случае:

Основные команды

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

Получение списка всех виртуалок:

Получение информации о конкретной виртуалке:

Жестко прибить виртуалку (несмотря на название, это не удаление):

sudo virt-clone -o freebsd10 -n freebsd10-clone \
--file / var / lib / libvirt / images / freebsd10-clone.img sudo virsh autostart freebsd10
sudo virsh autostart --disable freebsd10

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

Важно! Комментарии из отредактированного XML, к сожалению, удаляются.

Когда виртуалка остановлена, диск тоже можно ресайзить:

sudo qemu-img resize / var / lib / libvirt / images / freebsd10.img -2G
sudo qemu-img info / var / lib / libvirt / images / freebsd10.img

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

Резервное копирование и восстановление производятся довольно просто. Достаточно сохранить куда-то вывод dumpxml, а также образ диска, а потом восстановить их. На YouTube удалось найти видео с демонстрацией этого процесса, все и вправду несложно.

Настройки сети

import sys
import re
import os
import subprocess
from xml . etree import ElementTree

Скрипт работает как с default сетью, так и с bridged сетью, настройку которой мы рассмотрим далее. Однако на практике куда удобнее настроить KVM так, чтобы он всегда назначал гостевым системам одни и те же IP-адреса. Для этого правим настройки сети:

<dhcp >
<range start = '192.168.122.2' end = '192.168.122.254' />

<host mac = '52:54:00:59:96:00' name = 'freebsd10' ip = '192.168.122.184' />
</dhcp > sudo virsh net-destroy default
sudo virsh net-start default
sudo service libvirt-bin restart

Теперь перезагружаем несколько раз гостевую систему и убеждаемся, что она всегда получает адрес 192.168.122.184.

По умолчанию виртуальные машины могут ходить в интернет, а также к ним можно приконнектится из хост-системы. В общем и целом все выглядит так, словно гостевые системы находятся за NAT. На практике же часто бывает куда удобнее иметь bridged сеть. Как она настраивается на хост-системе ранее мы уже рассматривали в заметках Туториал по контейнеризации при помощи LXC и Контейнерная виртуализация при помощи OpenVZ.

После окончания настройки правим конфиг гостевой системы. Находим в нем что-то вроде:

Перезагружаем гостевую систему и проверяем, что она получила IP по DHCP от роутера. Если же вы хотите, чтобы гостевая система имела статический IP-адрес, это настраивается как обычно внутри самой гостевой системы.

Программа virt-manager

Вас также может заинтересовать программа virt-manager:

sudo apt-get install virt-manager
sudo usermod -a -G libvirtd USERNAME

Так выглядит ее главное окно:

Как видите, virt-manager представляет собой не только GUI для виртуалок, запущенных локально. С его помощью можно управлять виртуальными машинами, работающими и на других хостах, а также смотреть на красивые графички в реальном времени. Я лично нахожу особенно удобным в virt-manager то, что не нужно искать по конфигам, на каком порту крутится VNC конкретной гостевой системы. Просто находишь виртуалку в списке, делаешь двойной клик, и получаешь доступ к монитору.

Еще при помощи virt-manager очень удобно делать вещи, которые иначе потребовали бы трудоемкого редактирования XML-файлов и в некоторых случаях выполнения дополнительных команд. Например, переименование виртуальных машин, настройку CPU affinity и подобные вещи. Кстати, использование CPU affinity существенно снижает эффект шумных соседей и влияние виртуальных машин на хост-систему. По возможности используйте его всегда.

Если вы решите использовать KVM в качестве замены VirtualBox, примите во внимание, что хардверную виртуализацию они между собой поделить не смогут. Чтобы KVM заработал у вас на десктопе, вам не только придется остановить все виртуалки в VirtualBox и Vagrant, но и перезагрузить систему. Я лично нахожу KVM намного удобнее VirtualBox, как минимум, потому что он не требует выполнять команду sudo / sbin / rcvboxdrv setup после каждого обновления ядра, адекватно работает c Unity, и вообще позволяет спрятать все окошки.

Заключение

По традиции, немного ссылок по теме:

В целом, KVM произвел на меня исключительно положительное впечатление. Теперь я не понимаю, зачем все это время я мучился с Vagrant и VirtualBox, когда все уже есть в KVM и сделано куда лучше. Ну, почти. Кое-какие косяки все же имеются. Так, например, в htop гостевой системы вы можете видеть, что утилизируете CPU на 30%, хотя на хост-системе вы утилизируете все 100%. Однако мой опыт работы с виртуальными машинами свидетельствует о том, что такого рода проблемы и прочие шумные соседи возникают всегда, и еще один минорный баг в общем-то не делает в этом плане все сильно хуже.

Virtualizer: QEMU version 2.5.0.
OS: FreeBSD 9.3, 10.3.

В очередной раз столкнувшись с необходимостью протестировать сервисы на FreeBSD, с некоторым удивлением обнаружил, что легенды о полнейшей "невиртуализируемости" этой операционной системы живы даже среди весьма активных энтузиастов серверного и сетевого администрирования. Это не так, конечно же - FreeBSD отлично живёт в среде полной аппаратной виртуализации Hyper-V, VMware и Qemu-KVM. Как многолетний пользователь последней системы виртуализации напишу немного о работе FreeBSD в ней.

Гостевые драйверы поддержки "virtio" для FreeBSD версий старше 9.3 не были включены в базовое ядро, и распространялись в виде порта, как и вообще всё для этой замечательной ОС, а в более молодых релизах драйверы "virtio" оформлены в виде автоматически запускаемого стабильного модуля ядра. В общем, начиная с "FreeBSD 9.3" таковая запускается в среде виртуализации Qemu-KVM запросто, с указанием ряда параметров в конфигурационных файлах.

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

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

Disks: VirtIO Block Device (vtbd0).
Network: VirtIO Networking Adapter (vtnet0).

Предположим, на этапе инсталляции мы выбрали эмуляцию дисковых и сетевых устройств аналогичных физическим, а сейчас желаем перейти (или вообще хотим виртуализировать аппаратное решение, благо это делается простым: dd /storage/virt-ada0 bs=8M") на использование более скоростных драйверов "virtio". Исходя из того, что у нас есть дистрибутивные модули ядра, осуществляем поэтапный перевод ОС на работу с виртуальным оборудованием через драйверы "virtio".

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

Дистрибутивные модули ядра загружаются автоматически, так что никаких добавлений опций вроде "virtio_load=YES" в файл "/boot/loader.conf" не требуется.

В соответствии с изменением именования блочных устройств, правим параметры монтирования, подставляя зарезервированное для "virtio"-устройств имя "vtbd" вместо физических "ad", "da" или "acd":

Соответственно корректируем имена сетевых карт, подставляя зарезервированное для "virtio"-устройств имя "vtnet" вместо физических "dc", "fxp" или "em":

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

После сохранения конфигурации дисковой и сетевой подсистемы останавливаем виртуальную машину:

Теперь остаётся изменить параметры виртуального оборудования, указав типы устройств "virtio" в соответствии в приведённым в начале заметки рекомендациями.

[ уже посетило: 4682 ] [ интересно! / нет ]

Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )

Подготовить систему к использованию в качестве гипервизора можно, как с помощью ansible-ролей, так и вручную — путем установки и настройки необходимых пакетов. Ниже будут рассмотрены оба способа.

Установка необходимых пакетов.

Прежде, чем ис п ользовать сервер в качестве гипервизора, проверим включена ли в BIOS аппаратная виртуализация. Для Intel следующий вывод должен содержать инструкции “vmx”, для AMD — “svm”:

Можно так же проверить командой:

Для установки пакетов и использования системы в качестве гипервизора подойдет как серверный, так и desktop-дистрибутив. Ниже будет рассмотрена установка на Centos 7.x, Debian Stretch, Ubuntu 16.x, но в других версиях этих дистрибутивов установка может быть абсолютно идентична.

Ubuntu.

Debian.

Centos.

Для Centos пакеты лучше устанавливать из EPEL репозитория:

или из oVirt, где они новей:

Непосредственно сама установка пакетов:

Настройка Bridged Network.

По умолчанию, все создаваемые виртуальные машины будут в дефолтной сети KVM, которая находится за NAT’ом. Её можно удалить:

Список всех сетей для KVM можно получить командой:

Для того, чтобы создаваемые виртуальные машины находились в одной сети необходимо настроить network bridge.

Убедимся, загружен ли модуль bridge:

Если нет, то загрузим:

Ubuntu/Debian.

Устанавливаем пакет bridge-utils и редактируем настройки сетевых интерфейсов:

Для статических адресов:

Переподнимаем интерфейс и перегружаем daemon:

Centos.

Для конфигурации можно использовать текстово-графический интерфейс network manager’а:

Непосредственно сам bridge:

Для статических адресов:

Если интерфейс не управляется network manager’ом следует добавить строчку:

Переподнимаем интерфейс и перегружаем daemon:

Подготовка хоста виртуализации с помощью Ansible.

Перед тем как управлять хостами с помощью Ansible для Debian/Ubuntu дополнительно может потребоваться установить python (или python-minimal):

Нам понадобятся три роли: epel-repo для установки репозитория Epel, network — для создания network bridge и kvm — непосредственно для самой подготовки хоста виртуализации. Устанавливаем Ansible. Для Ubuntu/Debian:

Установку для других дистрибутивов смотрите в официальной документации. Указываем в конфиге путь к скачанным ролям — например, /home/username/ansible/roles:

Приводим файл inventory приблизительно к следующему виду:

И далее задаем в playbook’е, вызывающем роли kvm и network необходимые параметры — настройки сети (IP-адресс хоста не меняется), имя bridge-интерфейса:

В некоторых дистрибутивах (Centos) создание bridged interface может завершиться с ошибкой (bug пока что не исправлен), поэтому лучше явно указать, к какому интерфейсу подключать bridge. Задаем его имя, исправляя перед запуском playbook’а:

Управление гипервизором проще всего осуществлять через virt-manager. Устанавливаем в локальной системе:

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

Для того, чтобы пользователь имел возможность управлять libvirt’ом его нужно добавить в соответствующую группу: в Centos — это группа libvirt, в Ubuntu — libvirtd. Проверим:

Следовательно, добавляем пользователя user в группу libvirtd:

В некоторых дистрибутивах (Debian 9.x) пользователя так же необходимо будет добавить в группу “libvirt-qemu”. Просмотреть список групп можно:

Теперь необходимо сгенерировать ключ ssh и установить его на сервер, к которому будем подключаться через libvirt. Поскольку virt-manager по умолчанию запускается от обычного пользователя (не из под root), то и ключ генерируем не из под root’а. Обычно ключи лежат в папке /home/user/.ssh/id_rsa. Если их нет, то создаем:

и устанавливаем на сервер с libvirt:

Далее подключаемся в virt-manager к серверу виртуализации (рис. 1).

Помимо графического интерфейса virt-manager возможно так же подключение из консоли (virsh). Подробную инструкцию можно найти на сайте libvirt.

Создание и управление виртуальными машинами.

Создание виртуальных машин из virt-manager’а тривиально и в дополнительном описании не нуждается. Что касаемо CLI, то создание виртуальной машины с именем “ubuntu-vm” ОС Ubuntu с 1024 килобайтами RAM и 1 ядром CPU будет выглядеть:

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

Завершить работу ВМ можно командой:

Завершить работу принудительно (hard power-off):

Просмотреть список всех виртаульных машин можно командой:

а только запущенных (running):

“Заморозить” (suspend) и запустить далее (resume) виртуальную машину можно командами:

Сохранить состояние машины можно командой:

По умолчанию все конфигурации виртуальных машин находятся в xml-формате папке /etc/libvirt/qemu. Можно открыть их на редактирование любым привычным редактором, а можно выполнить команду (откроется в vi):

Просмотреть конфигурацию в более читаемом виде можно командой:

Отобразить потребляемые ресурсы (CPU и Memory) можно командой:

Если пакет не установлен в системе, то:

Клонирование виртуальных машин может быть осуществлено через графический интерфейс virt-manager’а, или через консольный virt-clone. Следующая команда создаст клон оригинальной <vm-name> и автоматически сгенерирует образ диска:

Принудительно задать имя клона:

Задать имена виртуальных дисков (например, если клонируемая ВМ имеет два диска):

Если в качестве носителей ВМ используется LVM:

Подключение к консоли.

Spice.

Для подключения через virt-manager достаточно, чтобы в качестве сервера был выбран Spice (см. настройки на рис. 2), а в качестве дисплей адаптеров виртуальной машины — QXL, или VGA. Подключение через virt-manager необходимо осуществлять по SSH-ключу (не по паролю). В большинстве случаев дефолтные конфиги libvirt уже пригодны для подключения к Spice, в противном случае стоит сверить следующие настройки:

Все остальные параметры Spice должны быть дефолтными (обычно закомментированы).

VNC.

Для подключения по VNC аналогично достаточно в virt-manager выбрать “VNC Server” (рис. 3), а в качестве display-адаптеров в гостевых системах использовать QXL, или VGA.

Можно так же отредактировать настройки видео через CLI:

Приведенный пример будет слушать подключения на всех IP-адресах KVM сервера и при подключении запрашивать пароль “yourpassword”. Если убрать параметр passwd, то можно будет подключиться без пароля. Для того, чтобы определить IP-адрес и порт для подкючения к виртуальной машины по VNC выполните команду:

К полученному значению порта нужно прибавить 5900. Таким образом, в приведенном примере, подключение возможно с любого IP-адреса по порту 5901.

tty.

Подключение к текстовой консоли так же возможно напрямую через CLI. Но для этого предварительно нужно указать некоторые параметры загрузки. Для Centos/RHEL:

Альтернативно можно дописать в /etc/grub следующие параметры:

Подключаемся к консоли:

Использование NUMA.

По умолчанию libvirt использует дефолтную политику гипервизора, которая в свою очередь подразумевает запуск виртуальной машины на любых свободных вычислительных ресурсах (процессорах и ядрах). Но бывают случаи, когда явное задание ресурсов процессора бывает рациональней, особенно для систем с архитектурой NUMA (Non-Uniform Memory Access). Рассмотрим пример конфига, когда нужно назначить виртуальной машины определенные ядра процессора. Но для начала просмотрим информацию о процессорных ресурсах:

Таким образом видим, что установлен два процессора с 4 ядрами и двумя потоками на каждом ядре. Из вывода так же видим, что имеется две NUMA-ноды. Дополнительные параметры CPU можно получить командой:

Но назначение ресурсов CPU конкретной ноде не даст никакой пользы, если у этой NUMA-ноды недостаточно памяти. libvrit хранит информацию о доступной памяти на каждой NUMA-ноде. Получить информацию можно:

Таким образом видим, что для запуска ВМ с 3Гб оперативной памяти лучше использовать первую NUMA-ноду (cell 1). Просмотреть информацию можно так же через numactl. Устанавливаем:

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

Просмотреть результат CPU affintiy можно командой:

Подробней об использовании NUMA можно узнать на сайте Fedora и RedHat.

Проброс устройств (Passthrough).

Рассмотрим проброс устройств на примере проброса Ethernet-порта с хоста гипервизора внутрь гостевой системы в режиме PCI Passthrough. Вообще, Network адаптеры создаваемые для виртуальных машин в KVM можно так же назначать (assign) к любому ethernet-интерфейсу, но тогда теряется часть функционала hardware, а трафик пойдет через ядро хостовой системы. Для работы PCI Passthrough нужно чтобы процессор и чипсет поддерживали технологию виртуализации (в Intel — это VT-d, в AMD — AMD-Vi) и была активирована опция intel_iommu/amd_iommu. В первую очередь необходимо проверить, активированы ли данные опции в BIOS. Далее проверяем доступна ли IOMMU в самой ОС. Для AMD:

Обновляем grub и перезагружаемся:

Ubuntu/Debian:

Centos:

Теперь необходимо добавить адрес PCI-устройства:

Соответственно, адрес устройства 01:00.0, или 01:00.1. Находим его в virt-manager’е в настройках ВМ:

или добавляем через CLI при создании машины, добавив следующую строчку:

Работа со snapshots.

Наиболее простой способ управления snapshots — это virt-manager, который в свою очередь использует команды qemu. “Замораживаем” виртуальную машину, создаем snapshot и по завершении “размораживаем” виртуальную машину:

QEMU также поддерживает временные снимки, в которых пользователю не нужно создавать отдельный img-файл: флаг “-snapshot” позволяет создавать временные файлы пока виртуальная машина включена и, как только она будет выключена, все изменения удалятся:

Но QEMU в отличие от virsh не может создавать snapshot виртуальных машин “на ходу”, но для того, чтобы воспользоваться этой возможностью необходимо в гостевой системе установить qemu-guest-agent и добавить для этой виртуальной машины устройство “QEMU channel device”. Заходим в свойства виртуальной машины в virt-manager (рис. 4) и добавляем устройство:

Или через консоль:

Устройство так же может быть добавлено и для запущенной виртуальной машины. Создаем xml:

Теперь на виртуальной машине <vm-name> (так же еще называют “dom name”) необходимо установить “гостевой агент”. Ubuntu/Debian:

Centos/RHEL:

Запускаем агент и добавляем в автозагрузку:

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

Получим следующий вывод:

Но по факту, для создания snapshots нам потребуется поддержка “заморозки” гостевой файловой системы (fsreeze). Проверяем, выполнив команду с хоста гипервизора:

Если получим вывод вида:

Дампим настройки машины в xml:

Создаем snapshot непосредственно с самими данными:

В последствии подобные snapshots, содержащие только состояние дисков, удобно использовать для backup’ов (за счет использования опции blockcommit). Во всех остальных случаях удобней пользоваться полными снимками виртуальных машин. Создадим полный snapshot:

Как видно, можно так же задать имя (ключ “name”) и описание (ключ “description). За списком остальных ключей следует обратиться к документации на сайте RedHat.

Просмотреть список всех snapshots для виртуальной машины можно командой:

В результате получите список полных snapshots. Snapshot’ы содержащие только блочные устройства (ключи “--disk-only --quiesce --no-metadata”) можно получить командой:

Получить информацию о каком-либо конкретном snapshot’e:

Получим примерно следующий вывод:

Откатить состояние ВМ к определенному snapshot’у можно командой:

Иногда snapshot может быть случайно удален. Если виртуальная машина не остановлена, то snapshot можно восстановить: на Stackoverflow есть post, описывающий пошаговое восстановление образов/snapshots виртуальных машин.

Работа со Storage Pools.

Образы жестких дисков виртуальных машин располагаются в так называемых Storage Pools. libvirt поддерживает различные типы storage pool’ов — от обычной локальной папки (local storage, или filesystem pool), или LVM-based до NFS, iSCSI, CEPH и тд. По умолчанию libvirt хранит образы дисков в локальном filesystem pool, который располагается в /var/lib/libvirt/images. Как обычно, большую часть операций со storage pools можно производить из virt-manager:

Что касаемо, консоли, то получить список доступных для хоста pool’ов можно командой:

Если требуется вывести так же список неактивных pool’ов, то следует воспользоваться ключом “--all”:

Информацию о конкретном pool’е можно получить:

Обновить имеющиеся образы в storage pool’е:

К примеру, если требуется создать дополнительный storage pool, расположенный локально в папке /mnt/somefolder, то для начала требуется создать xml:

Создаем pool из этого xml, проверяем результат и запускаем:

Если по каким-то причинам Pool неактивен, можно активировать командой:

Или даже добавить в автозапуск:

Если требуется удалить Pool, то для того, чтобы избежать проблем с виртуальными машинами использующими этот Pool, требуется вначале выполнить:

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

Удалить предопределяющие Pool данные можно командой:

Операции с образами дисков.

Операции с образами виртуальных дисков обеспечивает пакет QEMU, который в свою очередь поддерживает множество различных форматов: qcow, qcow2, raw, vdi, vmdk, vhdx и тд (более полный список опубликован здесь). Проще всего управлять образами через virt-manager, однако функционал QEMU будет несколько ограничен (например, нельзя изменить размер образа, или сконвертировать образ из одного формата в другой). Через консоль создание образа диска в нативном для KVM формате qcow2:

с последующим attach’ем к виртуальной машине <vm-name> как устройство vdb будет выглядеть следующим образом:

В целом интерфейс virsh c функцией attach-disk используется в следующем формате:

В качестве driver’а в большинстве случаев указывается “qemu”, в качестве cache можно указать “writethrough”. Подробней о режимах дискового кэширования можно ознакомиться здесь. Если параметр кэширования не задан, то используются параметры “Hypervisor defaults”.

Альтернативным способом будет добавление уcтройства через его xml-конфиг:

Изменим размер образа (увеличим на 10Гб):

Но при этом в virt-manager’е не отображается ни одного снимка, а команда:

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

которая, к примеру, выдает:

Как видим, перед расширением образа необходимо удалить snapshot по его ID:

Смотрим информацию об образе можно командой:

Зачастую бывает нужно сконвертировать образ из одного формата в другой (например, для того, чтобы native-формат qcow2 работал быстрей, чем vmdk от VMware). Для этого можно воспользоваться пакетом qemu-img:

Пакет qemu-img поддерживает vmdk, qcow2, vhd, vhdx, raw, vdi. По факту нужно указать исходный и конечный формат. Сконвертируем vdi в qcow2:

Возможно использовать следующие опции:

Многое (за исключением специфических для RedHat компонентов) можно так же почерпнуть по следующим ссылкам:

Информацию по распоространенным проблемам при работе с livbirt можно найти в отдельном разделе сайта RedHat:

Читайте также: