Kvm где хранятся виртуальные машины
Подготовка сервера
Проверяем наличие поддержки со стороны процессора:
cat /proc/cpuinfo | egrep "(vmx|svm)"
Создадим каталоги, в которых будем хранить все, что касается виртуализации (предлагаемые по умолчанию не удобные):
* каталог /kvm/images для виртуальных дисков; /kvm/iso — для iso-образов.
Установка и запуск
Установка выполняется из репозитория следующей командой:
yum install qemu-kvm libvirt virt-install
* где qemu-kvm — сам гипервизор; libvirt — библиотека управления виртуализацией; virt-install — утилита для управления виртуальными машинами.
systemctl enable libvirtd
systemctl start libvirtd
Настройка сети
В данной инструкции рассмотрим использование сетевого моста.
Настраивая сетевой мост через удаленное подключение, внимательно проверяйте вводимые данные. В случае ошибки соединение будет прервано.
Устанавливаем пакет для работы с bridge:
yum install bridge-utils
Смотрим список сетевых интерфейсов и их настроек:
В моем примере были следующие данные:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp4s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:16:76:04:26:c6 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.24/24 brd 192.168.1.255 scope global enp4s0f0
valid_lft forever preferred_lft forever
inet6 fe80::216:76ff:fe04:26c6/64 scope link
valid_lft forever preferred_lft forever
3: enp5s5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:16:76:04:26:c7 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether 52:54:00:cd:86:98 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000
link/ether 52:54:00:cd:86:98 brd ff:ff:ff:ff:ff:ff
* из этого для нас важны enp4s0f0 — реальный сетевой интерфейс с настроенным IP-адресом 192.168.1.24, через который идет подключение сервера к локальной сети (из него мы будем делать мост); 00:16:76:04:26:c6 — mac-адрес реального ethernet адаптера; virbr0 — виртуальный сетевой адаптер.
Редактируем настройки реального адаптера:
Приводим его к виду:
ONBOOT=yes
BRIDGE=br0
TYPE=Ethernet
DEVICE=enp4s0f0
BOOTPROTO=none
Создаем интерфейс для сетевого моста:
DEVICE=br0
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.1.24
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
DNS1=8.8.8.8
DNS2=77.88.8.8
Перезапускаем сетевую службу:
systemctl restart network
Сетевые настройки должны измениться — в моем случае:
2: enp4s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
link/ether 00:16:76:04:26:c6 brd ff:ff:ff:ff:ff:ff
3: enp5s5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:16:76:04:26:c7 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether 52:54:00:cd:86:98 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000
link/ether 52:54:00:cd:86:98 brd ff:ff:ff:ff:ff:ff
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:16:76:04:26:c6 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.24/24 brd 192.168.1.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::216:76ff:fe04:26c6/64 scope link
valid_lft forever preferred_lft forever
В данной статье мы рассмотрим несколько вариантов резервного копирования виртуальных машин на гипервизоре KVM, а так сценарии восстановления из бэкапов. Хочется сразу отметить, что как таковых удобных инструментов для резервного копирования под KVM нет, и каждый администратор использует свои варианты, скрипты и костыли. Есть 2 сценария бэкапа ВМ в KVM: с остановкой ВМ (самый простой, но используется крайне редко) и без остановки виртуальной машины.
Прежде всего хочется отметить, что особенности резервного копирования в вашем KVM сильно зависят от типа используемых виртуальных дисков: LVM, RAW (IMG) или qcow2. На моих серверах KVM диски виртуальных машин имеют формат qcow2. Я считаю, что данный формат выигрывает у остальных по двум причинам:
- Размер диска всегда имеет размер по занимаемому пространству внутри машины, его достаточно просто увеличить и уменьшить;
- Данный формат поддерживает снапшоты.
Поэтому виртуальные диски в формате qcow2 для меня бэкапить проще всего.
Создание резервных копий в KVM с остановкой виртуальной машины
Если ваш проект допускает кратковременную остановку виртуальной машины, то можно воспользоваться самым простым способом создания резервной копии. Для того, чтобы у вас всегда под рукой были актуальные резервные копии, вам нужно скопировать файл диска и конфигурационный файл самой виртуальной машины (на случай если меняется конфигурация).
С помощью virsh выведем список виртуальных машин в KVM:
Так же у меня есть директория, куда я планирую сохранять резервные копии виртуальных машин:
Конфигурационный файл виртуальной машины, можно скопировать следующей командой:
Где VM – это имя вашей виртуальной машины.
Теперь, чтобы создать резервную копию диска виртуальной машины, нужно остановить виртуальную машину и скопировать образ диска в целевой каталог:
После того, как диск полностью скопировался, нужно запустить виртуальную машину:
Для каждой виртуальной машины, можно создавать отдельную директорию и автоматизировать процесс создания копий, добавив команды скрипт и настроить задания в cron. Ранее мы размещали статью о резервном копировании в Linux с помощью скриптов. Вы можете использовать скрипты под свои нужды, адаптировав их для KVM.
Либо можете воспользоваться небольшим и простым скриптом:
Добавьте данный скрипт в крон и выполняйте так часто, как вам это требуется. Скрипт автоматически останавливает виртуальную машину, бэкапит файл диска и файл конфигурации, после чего автоматически запускает виртуальную машину.
В результате выполнения скрипта, у вас будут созданы директории для каждой виртуальной машины и в них помещены файл диска и дамп конфигурации, а также удалены старые резервные копии (количество дней укажите сами):
KVM: резервное копирование без остановки виртуальной машины
Естественно, в большинстве случае администраторы хотят использовать вариант “живого” резервного копирования виртуальных машин KVM без остановки. Он немного сложнее первого варианта и требует дополнительных действий. В данном варианте используется создание снапшота и последующее его объединение с файлом диска виртуальной машины. В самом начале статьи я писал, что использую формат дисков qcow2 и как раз это и позволяет создать живой бэкап. Для того, чтобы вы могли корректно создать копию виртуальной машины, в ВМ должен быть добавлен Channel Device с именем org.qemu.guest_agent.0 (можно добавить через конфигурационный файл или virt-manager).
Совет. Если не установить настроить агент для гостевые ВМ, при создании снапшота будет появляться ошибка:Не забудьте добавить конфигурационный XML файл виртуальной машины следующий блок:
Добавляется он в секцию “Device”, после чего нужно сохранить конфигурацию и выполнить ребут машины.
Затем в гостевой ОС нужно установить пакет qemu-guest-agent (установите его через yum/dnf):
Для создания снашшотов ВМ с Windows нужно установить virtio-win.Для создания снапшота ВМ используется следующая команда:
Где VM — это имя виртуальной машины. Далее нужно создать бэкап файла диска:
Где vda – это результат выполнения команды:
Для хранения резервных копий вы можете использовать удаленные сервера (можно копировать данные через Rsync) или хранилища . В одной из статей мы настраивали подключения к популярным облачным сервисам, таким образом вы можете сэкономить дисковое пространство на своем сервере.
Некоторое время назад озаботился решением вопроса бэкапа виртуальных машин kvm. Когда стал разбираться в теме, с удивлением обнаружил, что каких-то удобных, устоявшихся решений для горячего бэкапа виртуальных машин без остановки работы в kvm нет. Ни коммерческих решений не увидел, ни бесплатных. Пришлось самому вникать в суть и разбираться в теме.
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти .Введение
С гипервизором kvm лично мне приходилось мало работать. Еще в первое мое знакомство с гипервизорами, когда я выбирал, какой использовать в своей работе, kvm мне не понравился вообще по следующим причинам:
- Нет удобного инструмента для управления гипервизором под Windows. Для меня это критично, так как моя основная рабочая система ОС Windows.
- Не увидел готового образа, который бы позволил быстро и без лишних движений развернуть гипервизор на новом железе.
В итоге я остановился на Xen там, где нужно поставить систему на программный рейд mdadm, и Hyper-V в тех случаях, где рейд либо не нужен совсем, либо он аппаратный. В своей работе так или иначе приходится сталкиваться с различными системами, поэтому разбираться приходится во всем, в том числе и в kvm.
Есть 2 различных способа сделать бэкап виртуальной машины kvm:
- С остановкой или заморозкой системы на короткий промежуток времени.
- Без остановки системы вообще.
Для первого случая все относительно просто, каких-то нюансов нет. Во втором случае возникают нюансы и вопросы. Просто взять и сделать горячий бэкап виртуальной машины в 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, а файл как был один, так и останется. Это очень неудобно, так как если у вас будет занят весь доступный для файла объем, вы гарантированно получите ошибку при старте вашей виртуалки. А контролировать объем диска, в котором находятся снепшоты трудно и неудобно. И бэкапы в таком случае делать тоже не получится. Хотя получится, но все равно не удобно. Нужно будет отдельными командами конвертировать состояние виртуальной машины до снепшота в отдельный файл и его уже забирать для бэкапа. Плюс ко всему машину в этом случае нужно будет заморозить на момент создания снимка. Заморозка будет кратковременной, но все равно без нее не обойтись. Я приведу для примера команды, которыми это можно делать, но сам я не стал использовать такой способ, потому что, во-первых, не смог найти команды на объединения снепшота и основного файла, во-вторых, меня не устраивает даже кратковременная заморозка системы.
Конвертируем снепшот в отдельный образ:
Преобразовываем raw обратно в qcow2:
После этого надо объединить снимок с остальным файлом. Я не стал искать, как это сделать, так как тут используется заморозка виртуальной машины, хоть и кратковременная, но я хочу обойтись без нее. Поэтому я стал дальше искать варианты.
Установка qemu-guest-agent
Мы будем делать снепшот средствами virsh. При этом остановки или заморозки системы не будет вообще. Чтобы этот вариант корректно работал, вам необходимо установить на виртуальную машину qemu-guest-agent. Для этого вам сначала нужно добавить Channel Device по имени org.qemu.guest_agent.0. Проще всего это сделать через virt-manager.
Затем в систему надо установить пакет qemu-guest-agent. Для debian и centos все просто:
Для windows надо с диска virtio-win установить пакет qemu-ga из папки guest-agent, которая находится в корне диска.
Подробнее об установке qemu-guest-agent можно прочитать в документации redhat. Теперь у нас все готово для выполнения живого бэкапа виртуальной машины в kvm без остановки этой виртуалки.
Выполняем снепшот виртуальной машины:
| vm-name | имя виртуальной машины |
| backup-snapshot | название снэпшота, может быть любым |
| vda | имя диска, для которого указываем адрес снепшота |
| /snapshot/vm-name-backup.qcow2 | путь и имя файла для снепшота |
Для того, чтобы узнать имена дисков виртуальной машины, воспользуйтесь командой:
Обращаю внимание на важный момент, который я сначала упустил и долго не мог разобраться в логике создания снепшота. Параметр diskspec не указывает для какого диска создается снепшот, а просто обозначает путь до снепшота. Если у вас несколько дисков, а в diskspec вы указали только один диск, то снепшоты все равно будут созданы для всех дисков. При этом для тех дисков, где вы указали путь, будет использоваться указанный, а для остальных будет по-умолчанию в той же папке, где лежит исходный файл ВМ. Этот нюанс серьезно меняет логику работы скриптов для автоматизации бэкапа в том случае, если у машин несколько дисков. Написав скрипт для бэкапа машин с одним диском, у меня не получилось его быстро оптимизировать для нескольких.После того, как сделали снимок, скопируйте куда вам нужно основной файл виртуальной машины. Я предпочитаю его сразу сжимать всеми ядрами процессора с помощью архиватора pigz:
Когда выполнение бэкапа завершено, объединим снапшот с основным файлом:
После этого файл снэпшота можно удалить:
Для полноты картины забэкапим еще и настройки виртуалки:
И на этом все. Мы сделали полный бэкап работающей виртуальной машины kvm без ее остановки. Сама она даже не поняла, что с ней что-то сделали. Работающие БД на ней не испытывают никаких проблем. Проверял на postgresql. Терминальные сессии в windows server тоже чувствуют себя отлично.
Скрипт для автоматического бэкапа виртуальных машин KVM
По мотивам всего написанного выше я набросал простенький скрипт для автоматического живого бэкапа всех дисков всех работающих в момент выполнения скрипта виртуальных машин. Обращаю внимание, что бэкапятся все диски. Скрипт привожу просто для примера, не используйте его, если вам не нужны полные бэкапы всех дисков. Лично я бэкаплю только небольшие системные диски. Все, что много весит, предпочитаю архивировать другими способами уже изнутри виртуальной машины. Если это базы данных, то делаю бэкапы нужных баз postgresql, если это файловый сервер, то использую rsync для создания инкрементных бэкапов. Ну и так далее. Каждый выбирает средства на свой вкус.
Обращаю внимание на несколько моментов:
vm_list может либо автоматически заполняться списком работающих виртуальных машин, либо можно вручную указать список только тех машин, которые нужно бэкапить. Для этого нужно раскомментировать соответствующую строку в начале скрипта при объявлении переменной. Затем выбрать подходящую строку для цикла for. Он будет немного разным, в зависимости от списка.
Снепшоты будут создаваться в той же папке, где хранится основной файл данных. На время отладки советую для начала закомментировать строку с удалением снепшота, на всякий случай. Рекомендую этот крипт прогнать сначала на тестовом сервере. Я его написал на примере одного гипервизора, больше нигде не проверял. Но работает он однозначно, я проверил несколько раз с разными списками VM. В итоге оставил его у себя на сервере в работе.
Для регулярной очистки бэкапов, если они у вас будут храниться где-то в доступном с этого сервера месте, можно добавить в самый конец условие очистки. Для полного бэкапа VM мне видится нормальной схема хранения бэкапов в несколько месяцев, с созданием архивов раз в неделю. Чаще бэкапить системные диски не вижу смысла, там редко бывают ежедневные изменения.
Данная команда удалит все файлы старше 90 дней в папках с названиями виртуальных машин, расположенных в /backup-vm.
Заключение
В начале статьи я сказал, что не встретил готового решения по живому бэкапу kvm. (upd. Уже после публикации статьи мне подсказали готовое решение kvmBackup.) На самом деле это не совсем верно. Есть хорошая готовая сборка на основе kvm - proxmox. Я подробно рассматривал ее в отдельном материале - Установка и настройка proxmox. Но все же это решение конкретного коллектива разработчиков со своими возможностями и ошибками. В проксмокс реализован живой бэкап виртуальных машин из коробки. К сожалению, я не смог быстро найти техническую реализацию их решения. Возможно, все было бы еще проще. Но так тоже ничего получилось.
Есть несколько способов управлять виртуальными машинами, запущенными в гипервизоре KVM, например с помощью популярного графического фронтенда virt-manager. Однако, если вы хотите использовать KVM на сервере, графические решения вряд ли будут хорошим выбором. В этом случае удобным инструментом будет virsh - утилита командной строки для управления гостевыми виртуальными машинами. Она работает со службой libvirtd, которая может управлять несколькими различными гипервизорами, включая KVM, Xen, QEMU, LXC и OpenVZ.
Интерфейс командной строки virsh также полезен в случае, если вы хотите автоматизировать инициализацию и управление виртуальными машинами. Кроме того, способность virsh работать с различными гипервизорами обеспечивает единый интерфейс для управления виртуальными машинами различных типов.
В этом руководстве я продемонстрирую вам, как запускать KVM из командной строки с использованием virsh в Debian или Ubuntu.
Этап 1: проверка аппаратной поддержки виртуализации
В качестве первого этапа проверьте, поддерживает ли ваш процессор аппаратную виртуализацию (то есть Intel VT или AMD-V), которая требуется для KVM. Это можно сделать с помощью команды:
Если в выводе нет флага vmx или svm, это значит, что процессор не поддерживает аппаратную виртуализацию, поэтому вы не сможете использовать KVM на этом хосте. После проверки самое время установить KVM.
Этап 2: Установка KVM
Установите KVM и соответствующие пользовательские утилиты с помощью apt-get:
Во время инсталляции будет создана группа libvirtd, и ваш userID будет автоматически добавлен в группу. Это позволит вам управлять виртуальными машинами от имени обычного пользователя. Вы можете проверить это с помощью команды id, которая выводит ваш group ID.
Если по каким-либо причинам в списке вашего groupID нет libvirtd, вы можете вручную добавить себя в эту группу.
Перезагрузите обновленную информацию о группе, как показано ниже. Когда появится запрос, введите свой пользовательский пароль.
Этап 3: Настройка сетевого моста
Один из способов получения доступа из виртуальной машины к внешним сетям - мост, встроенный в ваш хост Linux. Это называется сетевой мост. Ниже описано, как создать и настроить сетевой мост Linux br0 для мостового соединения с KVM.
Сначала установим необходимый для создания сетевого моста пакет.
Далее необходимо настроить сетевой мост в файле /etc/network/interfaces, чтобы он активировался при загрузке системы. Для использования файла /etc/network/interfaces необходимо отключить Network Manager (если он у вас используется). Как это сделать, описано здесь .
После отключения Network Manager настраиваем сетевой мост br0 в /etc/network/interfaces, как показано ниже.
Здесь предполагается, что главным сетевым интерфейсом, который имеет доступ к внешним сетям, является eth0. Кроме того, предполагается, что eth0 получает IP-адреса посредством DHCP. Обратите внимание, что в /etc/network/interface нет настроек для eth0, так как он подключается к сетевому мосту br0.
Перезагрузите сетевые службы и убедитесь, что сетевой мост настроен успешно. В этом случае br0 должен присвоить сетевой адрес интерфейса eth0, в свою очередь интерфейсу eth0 не должно быть присвоено сетевого адреса.
Этап 4: создание виртуальной машины из командной строки
В KVM настройки виртуальной машины хранятся в XML-файле домена. Поэтому сначала необходимо подготовить этот файл.
Ниже пример простого XML-файла для виртуальной машины. Вы можете использовать его, откорректировав в соответствии со своими потребностями.
Этот XML-файл определяет следующую виртуальную машину:
1 Гб оперативной памяти, один CPU и один жесткий диск.
Образ диска: /home/dev/images/alice.img.
Загрузка с CD: (/home/dev/iso/ubuntu-13.10-server-amd64.iso).
Сеть: сетевой мост br0.
Строка UUID между тегами <uuid></uuid> может быть сгенерирована случайным образом. Для этого используется утилита командной строки uuid.
Доменный XML-файл можно также создать, сделав дамп информации о домене существующей виртуальной машины:
Этап 5: запуск виртуальной машины из командной строки.
Перед запуском виртуальной машины необходимо создать образ диска для нее. Для этого можно воспользоваться командой qemu-img, входящей в пакет qemu-kvm.
Преимущество опции qcow2 в том, что создаваемый при ее использовании образ диска не резервирует сразу весь свой свой объем (5 Гб), а динамически увеличивается при наполнении в процессе работы виртуальной машины.
Теперь вы готовы к запуску виртуальной машины с использованием созданного ранее доменного XML-файла. Это делается с помощью приведенной ниже команды:
Проверьте, что домен создан успешно.
Кроме того, проверьте, что виртуальный сетевой интерфейс для виртуальной машины (то есть vnet0) успешно добавлен в созданный ранее сетевой мост br0.
Этап 6. Удаленный доступ к виртуальной машине.
Для удаленного доступа к консоли виртуальной машины вы можете использовать любой VNC-клиент.
Сначала определите номер порта VNC для виртуальной машины:
В этом примере номер порта для виртуальной машины alice 5900.
Затем запустите VNC-клиент и подключитесь к VNC-серверу, работающему по адресу KVM-host-IP:5900.
Управление виртуальной машиной с помощью virsh
Ниже список наиболее часто употребляемых команд virsh.
Для создания нового гостевого домена и запуска виртуальной машины:
Для остановки виртуальной машины и уничтожения гостевого домена:
Для выключения виртуальной машины (без уничтожения домена):
Для приостановки виртуальной машины:
Для возобновления работы виртуальной машины:
Для автозапуска виртуальной машины после загрузки хоста:
Для получения информации о домене виртуальной машины:
Вы можете также управлять виртуальными машинами из сессии virsh. Для создания новой сессии virsh и входа в нее, просто введите:
В командной строке вы можете использовать любые команды virsh.
Решение проблем
1. Я получил ошибку, когда попытался создать виртуальную машину:
Вы получите эту ошибку, если ваш процессор не поддерживает аппаратную виртуализацию (то есть Intel VT или AMD-V), которая требуется для работы KVM. Если же вы получили эту ошибку с процессором, поддерживающим Intel VT или AMD-V, возможные решения этой проблемы:
Во-первых, проверьте, загружены ли требуемые модули ядра.
Если модуль kvm не загружен, вам необходимо загрузить его:
Второе решение - добавление аргумента "--connect qemu:///system" к команде virsh, как показано ниже. Этот аргумент может потребоваться, если вы используете более одного гипервизора (то есть VMware, VirtualBox) на сервере.
2. Я получил ошибку, когда пытался запустить консоль своей виртуальной машины:
Эта ошибка возникает потому, что вы не определили устройство консоли в XML-файле виртуальной машины. Добавьте приведенные ниже строки в раздел "device" XML-файла.
Читайте также: