Глава 2. Применение libvirt для управления KVM

Содержание

В данной главе мы рассмотрим такие темы:

Установку и настройку libvirt
Определение экземпляров KVM
Запуск, останов и удаление экземпляров KVM
Инспектирование и изменение настроек KVM
Построение нового экземпляра с помощью virt-install и применения консоли
Управление ресурсами ЦПУ и оперативной памяти в KVM
Подключение блочных устройств к виртуальным машинам
Совместное использование каталогов между исполняемыми ВМ и самой ОС хоста
Автоматический запуск экземпляров KVM
Работа с пулами хранения
Управление томами
Управление секретными кодами

Введение

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

В этой главе мы намерены поработать с набором инструментов libvirt. Libvirt предоставляет различные команды пространства пользователя и врезки в языки программирования для построения, настройки, запуска, останова миграции, прекращения и прочих функций управления вашими виртуальными машинами. Она предоставляет поддержку для различных технологий виртуализации, таких как QEMU/KVM, XEN, а также контейнеров с LXC.

Мы начнём с установки и настройки инструментов libvirt, затем перейдём к созданию виртуальных машин при помощи файлов настройки XML, поддерживаемых libvirt, а также изучим множество функций, предоставляемых этим набором инструментария для управления самим жизненным циклом экземпляров KVM. Все рецепты из данной главы предназначены для присутсвтия в контексте сред с высокой доступностью и множеством арендаторов.

Установка и настройка libvirt

В этом рецепте мы намерены установить libvirt из пакетов, предоставляемых дистрибутивом Linux по вашему выбору и рассмотреть файлы настроек и те варианты, которые доступны для его конфигурации. Как и в отношении прочих готовых к промышленному применению инструментов, мы рекомендуем применять пакеты для вашей промышленной среды для простоты и согласованности развёртывания; хотя компиляция самой последней версии из её исходного кода также некий вариант если имеющиеся у вашего производителя Linux пакеты старше.

Приготовление

В зависимости от вашего дистрибутива Linux будут различаться само название пакета и команды установки. Вы можете применять свой диспетчер пакетов системы, такой как apt, yum или dnf для поиска каких- либо пакетов, содержащих строку libvirt и ознакомиться с тем, что именно доступно для вашего конкретного варианта Linux. Исходный код может быть выгружен с официального вебсайта проекта libvirt.

Как это сделать...

Для установки libvirt из пакетов и исходного кода следуйте таким этапам:

В Ubuntu установите необходимый пакет выполнив:
```
root@kvm:~# apt update && apt install libvirt-bin
root@kvm:~#
 	   
```
Убедитесь что необходимый демон libvirt запущен и исполняется:
```
root@kvm:~# pgrep -lfa libvirtd
36667 /usr/sbin/libvirtd
root@kvm:~#
 	   
```

Изучите установленную по умолчанию конфигурацию:


root@kvm:~# cat /etc/libvirt/libvirtd.conf | grep -vi "#" | sed '/^$/d'
  unix_sock_group = "libvirtd"
  unix_sock_ro_perms = "0777"
  unix_sock_rw_perms = "0770"
  auth_unix_ro = "none"
  auth_unix_rw = "none"
  root@kvm:~#

Отключите имеющийся драйвер безопасности QEMU измениы файл настройки qemu следующим образом:
```
root@kvm:~# vim /etc/libvirt/qemu.conf
...
security_driver = "none"
...
root@kvm:~#
 	   
```

Перезапустите демон libvirt:


oot@kvm:~# /etc/init.d/libvirt-bin restart
libvirt-bin stop/waiting
libvirt-bin start/running, process 1158
root@kvm:~#

	Замечание
	В зависимости от имеющегося у вас дистрибутива Linux название для конкретной службы `libvirt` может отличаться. В RHEL/ CentOS названием этой службы является `libvirtd`; для её перезапуска исполните `service libvirtd restart`.

Изучите все файлы настроек в своём каталоге libvirt:


root@kvm:~# ls -la /etc/libvirt/
total 76
drwxr-xr-x 5 root root 4096 Mar 22 14:27 .
drwxr-xr-x 90 root root 4096 Mar 21 23:17 ..
drwxr-xr-x 2 root root 4096 Feb 5 2016 hooks
-rw-r--r-- 1 root root 518 Feb 5 2016 libvirt.conf
-rw-r--r-- 1 root root 13527 Feb 5 2016 libvirtd.conf
-rw-r--r-- 1 root root 1176 Feb 5 2016 lxc.conf
drwxr-xr-x 2 root root 4096 Mar 21 23:16 nwfilter
drwxr-xr-x 3 root root 4096 Mar 21 23:57 qemu
-rw------- 1 root root 16953 Mar 21 23:18 qemu.conf
-rw-r--r-- 1 root root 2170 Feb 5 2016 qemu-lockd.conf
-rw-r--r-- 1 root root 2213 Feb 5 2016 virtlockd.conf
-rw-r--r-- 1 root root 1217 Feb 5 2016 virt-login-shell.conf
root@kvm:~#

Как это работает...

На шаге 1 мы установили соответствующий пакет в Ubuntu. Соответствующий сценарий постустановки запустил демон libvirt по окончанию успешной установки всего пакета. Мы проверяем это на шаге 2.

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

На шаге 4 мы отключаем имеющийся драйвер безопасности для QEMU. По умолчанию в системах RHEL/CentOS QEMU настроен на применение SELinux. Дистрибутивы Ubuntu применяют AppArmor. Для упрощения мы запрещаем эту функциональность на данном этапе; тем не менее, в промышленности вам следует воспользоваться преимуществами такой дополнительной безопасности как система принудительного контроля доступа, например, предоставляемой SELinux.

Любые изменения в файле настроек libvirt требуют его перезапуска. На шаге 5 мы выполняем такой перезапуск libvirt.

Существует ряд важных файлов настройки, с которыми нам необходимо ознакомиться и которые перечислены на шаге 6:

libvirt.conf: является файлом настроек стороны клиента для команды virsh, которую мы намерены применять в данном рецепте. В нём мы можем определить сокращения URI. Имеющихся пао умолчанию может быть вполне достаточно.
libvirtd.conf: является файлом настроек стороны сервера, как мы это видели на шаге 3. Он предоставляет различные параметры безопасности, пределы запросов и управление регистрациями. Для целей данной книги нам будет достаточно установок по умолчанию.
qemu.conf является основным файлом настроек для того драйвера QEMU, который применяет libvirt. Мы можем настраивать такие параметры как необходимый адрес сервера VNC, тот драйвер безопасности, который мы видели на шаге 4, а также пользователя и группу для соответствующего процесса QEMU.
После того как мы создали некую виртуальную машину QEMU/ KVM, наш каталог /etc/libvirt/qemu/ будет содержать соответствующие определения настроек XML для такого экземпляра, которые мы намерены рассмотреть в своих последующих рецептах.
Наконец, наш каталог /etc/libvirt/qemu/networks/ содержит файлы настроек для сетевой среды. Мы собираемся также более подробно изучить их позднее в этой главе.

Определение экземпляров KVM

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

Приготовление

Для данного рецепта нам потребуется следующее:

Двоичные файлы QEMU, предоставляемые после Установки и настройка QEMU из Главы 1.
Некий индивидуальный сырой образ Debian, который мы построили в соответствующем рецепте Установка пользовательской ОС в образ при помощи debootstrap также из предыдущей главы.

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

Как это сделать...

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

Перечислите все виртуальные машины в данном хосте:


root@kvm:~# virsh list --all
 Id Name State
----------------------------------------------------

root@kvm:~#

Создайте следующий файл определений XML:


root@kvm:~# cat kvm1.xml
<domain type='kvm' id='1'>
 <name>kvm1</name>
 <memory unit='KiB'>1048576</memory>
 <vcpu placement='static'>1</vcpu>
 <os>
   <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
   <boot dev='hd'/>
 </os>
 <on_poweroff>destroy</on_poweroff>
 <on_reboot>restart</on_reboot>
 <on_crash>restart</on_crash>
 <devices>
   <emulator>/usr/bin/qemu-system-x86_64</emulator>
   <disk type='file' device='disk'>
     <driver name='qemu' type='raw'/>
     <source file='/tmp/debian.img'/>
     <target dev='hda' bus='ide'/>
     <alias name='ide0-0-0'/>
     <address type='drive' controller='0' bus='0' target='0' unit='0'/>
   </disk>
   <interface type='network'>
     <source network='default'/>
     <target dev='vnet0'/>
     <model type='rtl8139'/>
     <alias name='net0'/>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
   </interface>
   <graphics type='vnc' port='5900' autoport='yes' listen='146.20.141.158'>
     <listen type='address' address='146.20.141.158'/>
   </graphics>
 </devices>
 <seclabel type='none'/>
</domain>
root@kvm:~#

Определите свою виртуальную машину:


root@kvm:~# virsh define kvm1.xml
Domain kvm1 defined from kvm1.xml

root@kvm:~#

Выведите список всех экземпляров во всех состояниях:


root@kvm:~# virsh list --all
 Id Name State
----------------------------------------------------
 - kvm1 shut off

root@kvm:~#

Как это работает...

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

На шаге 2 мы создали некий файл определений для нового экземпляра KVM. Мы применяем небольшой подраздел из всех возможных атрибутов имеющейся схемы XML для установки таких параметров:

Элемент корня соответствующего файла XML необходим для всехопределений виртуальной машины и он именуется domain. В нём имеется два атрибута -- type и id. В качестве type мы определяем kvm , а для id устанавливаем 1, поскольку это наша самая первая виртуальная машина KVM. Все прочие атрибуты определяются под данным элементом корня domain.
Под данным элементом корня domain мы определяем некое название для своего экземпляра.
Соответствующий атрибут памяти определяет объём доступной памяти для данной ВМ, в нашем случае это 1 GB.
Элемент vcpu определяет значение максимального числа виртуальных ЦПУ выделяемых вашей гостевой ОС. Мы определяем 1 и мы используем имеющийся необязательный атрибут размещения, который указывает соответствующий режим размещения данного ЦПУ; в данном примере статический. Статическое размещение указывает что данный виртуальный экземпляр будет прикреплён ко всем доступным физическим ЦПУ.
Элемент ОС определяет значение архитектуры данной ВМ при помощи соответствующего элемента типа. Параметр hvm указывает что мы намерены применять полную виртуализацию, которая намерена представлять KVM, как это определено в соответствующем типе атрибута, который мы видели ранее. Мы определяем что необходимое устройство загрузки данной ВМ будет запущено из соответствующего элемента <boot dev>.
Следующие три элемента определяют то действие, которое будет предпринято когда данный гость запросит отключение питания, перезагрузку или в случае его падения. В нашем экземпляре данная ВМ будет уничтожена при выключении питания в гостевой ОС и перезапущена при перезагрузках гостя или его крушенийях.
Самый последний раздел нашего определения XML это раздел устройств, в котором мы применяем различные элементы XML для описания устройств, поставляемых в данную гостевую ОС. Соответствующий элемент эмулятора определяет путь к исполняемому файлу самого эмулятора. Мы намерены применять тот же самый двоичный эмулятор QEMU qemu-system-x86_64, который мы применяли в Главе 1, Начало работы с QEMU и KVM. В самых последних разделах атрибутов устройств мы определяем соответствующий тип применяемого нами виртуального диска, в данном примере, сырого образа, который мы построили в своей предыдущей главе. Аналогичным образом мы описываем соответствующий сервер VNC, который следует запустить данному гостю и необходимый сетевой интерфейс внутри данной гостевой ОС.

Получив в нужном месте необходимый нам файл config на шаге 3 мы определили свой экземпляр при помощи созданного ранее в /tmp необходимого образа.

Когда новый экземпляр определён, по умолчанию он не будет автоматически запущен. На шаге 4 мы можем видеть что имеющееся состояние нашего нового экземпляра shut off.

	Замечание
	Для получения сведений относительно всех доступных элементов и их атрибутов обращайтесь, пожалуйста, к официальной документации libvirt.

Также ознакомьтесь...

Настройка некоторой виртуальной машины через написание её файла XML может быть достаточно нудной и подверженной ошибкам. Неким простым способом создания соответствующей ВМ из имеющегося образа или из какого- то установочного носителя (который может быть физическим, виртуальным или расположенным в сети), это применение инструмента virt-install. Давайте посмотрим некий образец создания того же самого экземпляра KVM при помощи этого инструмента.

Мы начинаем с установки самого пакета:
```
root@kvm:~# apt install virtinst
...
root@kvm:~#
 	   
```
Затем мы определяем и запускаем новый экземпляр путём вызова соответствующей команды virt-install (если некий экземпляр имеет то же самое название, которое уже имеется, вам потребуется вначале удалить и переопределить его):
```
root@kvm:~# virt-install --name kvm1 --ram 1024 --disk path=/tmp/debian.img,format=raw --graphics vnc,listen=146.20.141.158 --noautoconsole --hvm --import

Starting install...
Creating domain... | 0 B 00:00
Domain creation completed. You can restart your domain by running:
 virsh --connect qemu:///system start kvm1
root@kvm:~#
 	   
```

Эта новая ВМ теперь была создана и запущена. Для подтверждения исполните:


root@kvm:~# virsh list --all
 Id Name State
----------------------------------------------------
 10 kvm1 running

root@kvm:~#

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


root@kvm:~# cat /etc/libvirt/qemu/kvm1.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
 virsh edit kvm1
or other application using the libvirt API.
-->

<domain type='kvm'>
 <name>kvm1</name>
 <uuid>c3892cbf-812a-2448-7ad2-098ea8381066</uuid>
 <memory unit='KiB'>1048576</memory>
 <currentMemory unit='KiB'>1048576</currentMemory>
 <vcpu placement='static'>1</vcpu>
 <os>
   <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
    <boot dev='hd'/>
 </os>
 <features>
   <acpi/>
   <apic/>
   <pae/>
 </features>
 <clock offset='utc'/>
 <on_poweroff>destroy</on_poweroff>
 <on_reboot>restart</on_reboot>
 <on_crash>restart</on_crash>
 <devices>
   <emulator>/usr/bin/qemu-system-x86_64</emulator>
   <disk type='file' device='disk'>
     <driver name='qemu' type='raw'/>
     <source file='/tmp/debian.img'/>
     <target dev='hda' bus='ide'/>
     <address type='drive' controller='0' bus='0' target='0' unit='0'/>
   </disk>
   <controller type='usb' index='0'>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
   </controller>
   <controller type='pci' index='0' model='pci-root'/>
   <controller type='ide' index='0'>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
   </controller>
   <interface type='network'>
     <mac address='52:54:00:59:e3:4e'/>
     <source network='default'/>
     <model type='rtl8139'/>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
   </interface>
   <serial type='pty'>
     <target port='0'/>
   </serial>
   <console type='pty'>
     <target type='serial' port='0'/>
   </console>
   <input type='mouse' bus='ps2'/>
   <input type='keyboard' bus='ps2'/>
   <graphics type='vnc' port='-1' autoport='yes' listen='146.20.141.158'>
     <listen type='address' address='146.20.141.158'/>
   </graphics>
   <video>
     <model type='cirrus' vram='9216' heads='1'/>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
   </video>
   <memballoon model='virtio'>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
   </memballoon>
 </devices>
</domain>
root@kvm:~#

Запуск, останов и удаление экземпляров KVM

В своём предыдущем рецепте мы увидели как определять новую виртуальную машину KVM либо вручную выписывая соответствующий файл определений XML, либо при помощи инструмента virt-install для определения такого экземпляра нам.

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

Приготовление

Для данного рецепта нам потребуется следующее:

Исполняемые файлы, предоставленные после того как мы проследовали рецептом Установки и настройка QEMU из Главы 1.
Пользовательский сырой образ Debian, который мы построили в соответствующем рецепте Установка пользовательской ОС в образ при помощи debootstrap из предыдущей главы.
Инструментарий virsh, предоставленный выполнением рецепта Установка и настройка libvirt.
Уже определённый экземпляр из нашего рецепта Определение экземпляров KVM в состоянии shut off.

Как это сделать...

Приводимые ниже шаги приводят соответствующий процесс перечисления, запуска и останова экземпляров KVM при помощи команды virsh:

Перечислим все экземпляры во всех состояниях:


root@kvm:~# virsh list --all
 Id Name State
----------------------------------------------------
 - kvm1 shut off
root@kvm:~#

Запустим вновь определённый экземпляр и проверим его состояние:


root@kvm:~# virsh start kvm1
Domain kvm1 started

root@kvm:~#
root@kvm:~# virsh list --all
 Id Name State
----------------------------------------------------
 1 kvm1 running

root@kvm:~#

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


root@kvm:~# pgrep -lfa qemu
1686 /usr/bin/qemu-system-x86_64 -name kvm1 -S -machine pc-i440fx-trusty,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid a9dfd1a1-7dd1-098e-a926-db9526785a9e -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/kvm1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/tmp/debian.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:ce:dd:f2,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 146.20.141.158:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
root@kvm:~#

Остановим данную ВМ и убедимся что её состояние изменилось на shut off:


root@kvm:~# virsh destroy kvm1
Domain kvm1 destroyed

root@kvm:~# virsh list --all
 Id Name State
----------------------------------------------------
 - kvm1 shut off

root@kvm:~#

Удалим определений данного экземпляра:


root@kvm:~# virsh undefine kvm1
Domain kvm1 has been undefined

root@kvm:~# virsh list --all
 Id Name State
----------------------------------------------------

root@kvm:~#

Как это работает...

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

На шаге 2 мы запустили эту виртуальную машину и убедились что её состояние изменилось на исполняемая.

Если вы выполняли рецепт Главы 1 Выполнение ВМ при помощи qemu-system-*, вы можете заметить, что имеющееся определение XML для данной ВМ очень похоже на все параметры командной строки, которую мы применяли для запуска всоего экземпляра QEMU. Мы можем наблюдать аналогичность того как наш новый экземпляр был запущен на шаге 3. Основное отличие состоит в большем числе параметров libvirt, передаваемых для исполнения данного QEMU.

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

Осмотр и изменение настроек KVM

В этом рецепте мы намерены воспользоваться инструментом virsh для инспекции и изменения настроек некоторой имеющейся виртуальной машины. Как мы уже видели ранее, после того как мы определили и запустили некий экземпляр KVM, libvirt создаёт соответствующий файл определений XML в своём каталоге /etc/libvirt/qemu/. Мы можем выполнить дамп таких гостевых настроек на диск для их осмотра или обратно для запуска. При помощи данной команды virsh мы также можем выполнять обновления имеющейся настройки прямо на месте, как мы увидим позднее в данном рецепте.

Приготовление

Для данного рецепта нам потребуется следующее:

Исполняемые файлы, предоставленные после того как мы проследовали рецептом Установки и настройка QEMU из Главы 1.
Пользовательский сырой образ Debian, который мы построили в соответствующем рецепте Установка пользовательской ОС в образ при помощи debootstrap из предыдущей главы.
Инструментарий virsh, предоставленный выполнением рецепта Установка и настройка libvirt.
Запущенный экземпляр KVM libvirt.

Как это сделать...

Приводимые ниже шаги отображают весь процесс инспекции и изменения соответствующего определения XML для некоторого экземпляра KVM:

Убедитесь что у вас имеется запущенный при помощи libvirt экземпляр KVM, если нет, повторите шаги предыдущего рецепта:
```
root@kvm:~# virsh list
 Id Name State
----------------------------------------------------
 11 kvm1 running

root@kvm:~#
 	   
```

Выдайте дамп файла настроек данного экземпляра в стандартный вывод (stdout). Для ознакомления со стандартным выводом отсылаем вас к en.wikipedia.org:


root@kvm:~# virsh dumpxml kvm1
<domain type='kvm' id='11'>
 <name>kvm1</name>
 <uuid>9eb9a2e9-abb2-54c5-5cb3-dc86728e70fc</uuid>
 <memory unit='KiB'>1048576</memory>
 <currentMemory unit='KiB'>1048576</currentMemory>
 <vcpu placement='static'>1</vcpu>
 <resource>
   <partition>/machine</partition>
 </resource>
 <os>
   <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
   <boot dev='hd'/>
 </os>
 <features>
   <acpi/>
   <apic/>
 <pae/>
 </features>
 <clock offset='utc'/>
 <on_poweroff>destroy</on_poweroff>
 <on_reboot>restart</on_reboot>
 <on_crash>restart</on_crash>
 <devices>
   <emulator>/usr/bin/qemu-system-x86_64</emulator>
   <disk type='file' device='disk'>
     <driver name='qemu' type='raw'/>
     <source file='/tmp/debian.img'/>
     <target dev='hda' bus='ide'/>
     <alias name='ide0-0-0'/>
     <address type='drive' controller='0' bus='0' target='0' unit='0'/>
   </disk>
   <controller type='usb' index='0'>
     <alias name='usb0'/>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
   </controller>
   <controller type='pci' index='0' model='pci-root'>
     <alias name='pci.0'/>
   </controller>
   <controller type='ide' index='0'>
     <alias name='ide0'/>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
   </controller>
   <interface type='network'>
     <mac address='52:54:00:d1:70:df'/>
     <source network='default'/>
     <target dev='vnet0'/>
     <model type='rtl8139'/>
    <alias name='net0'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
   </interface>
   <serial type='pty'>
     <source path='/dev/pts/0'/>
     <target port='0'/>
     <alias name='serial0'/>
   </serial>
   <console type='pty' tty='/dev/pts/0'>
     <source path='/dev/pts/0'/>
     <target type='serial' port='0'/>
     <alias name='serial0'/>
   </console>
   <input type='mouse' bus='ps2'/>
   <input type='keyboard' bus='ps2'/>
   <graphics type='vnc' port='5900' autoport='yes' listen='146.20.141.158'>
     <listen type='address' address='146.20.141.158'/>
   </graphics>
   <video>
     <model type='cirrus' vram='9216' heads='1'/>
     <alias name='video0'/>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
   </video>
   <memballoon model='virtio'>
     <alias name='balloon0'/>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
   </memballoon>
 </devices>
 <seclabel type='none'/>
</domain>

root@kvm:~#

Сохраним полученные настройки в новый файл следующим образом:


root@kvm:~# virsh dumpxml kvm1 > kvm1.xml
root@kvm:~# head kvm1.xml
<domain type='kvm' id='11'>
 <name>kvm1</name>
 <uuid>9eb9a2e9-abb2-54c5-5cb3-dc86728e70fc</uuid>
 <memory unit='KiB'>1048576</memory>
 <currentMemory unit='KiB'>1048576</currentMemory>
 <vcpu placement='static'>1</vcpu>
 <resource>
   <partition>/machine</partition>
 </resource>
 <os>
root@kvm:~#

Измените эти настройки прямо на месте и поменяйте доступную этой ВМ память:
```
root@kvm:~# virsh edit kvm1
Domain kvm1 XML configuration edited.

root@kvm:~#
 	   
```

Как это работает...

Libvirt предоставляет два основных способа манипуляции имеющимися определениями настроек для своих виртуальных машин. Мы можем либо выводить дамп имеющейся конфигурации из некого имеющегося экземпляра, как мы это сделали на шагах 2 и 3, либо изменять имеющееся определение XML на месте, как это сделано на шаге 4.

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

При осуществлении изменений прямо на месте, как это показано на шаге 4, будет использован определённый по умолчанию в системе $EDITOR. Находясь в режиме изменения, заметьте, что ваш файл XML содержит информацию относительно текущего состояния вашего виртуального экземпляра. Соответствующие атрибуты <uuid> и <currentMemory> являются примерами этого. Если вы желаете изменить доступную этой ВМ память после обновления соответствующего атрибута <memory>, вам понадобится также удалить имеющуюся строфу <currentMemory>. Если при редактировании возникли некие проблемы, libvirt пожалуется сообщением об ошибке и предоставит следующие варианты:


root@kvm:~# virsh edit kvm1
error: XML error: current memory '1048576k' exceeds maximum '524288k'
Failed. Try again? [y,n,f,?]:n
Domain kvm1 XML configuration not changed.
root@kvm:~#

Кроме того имейте в виду, что если вы желает создать некий новый экземпляр из своего дампа некоторого уже имеющегося экземпляра, вам понадобится изменить имеющееся <name> и удалить существующие атрибуты <uuid>, которые впоследствии создадутся автоматически после определения нового экземпляра.

Построение новых экземпляров KVM при помощи virt-install и с применением консоли

В нашем рецепте Подключение к исполняемому экземпляру при помощи VNC из Главы 1 вы изучили как подключаться к виртуальной машине QEMU/KVM, в которой запущен сервер VNC. Это прекрасный способ подключения к некоторому экземпляру, который был уже установлен или в пребывает в процессе загрузки для взаимодействия с ним.

До сих пор мы пользовались неким индивидуальным сырым образом, который мы создали ранее и содержит некую установку Debian. Вспомни те Главу 1, Начало работы с QEMU и KVM, в которой мы применяли команду debootstrap для установки такой ОС внутри имеющегося файла образа. В этом рецепте мы намерены воспользоваться инструментом virt-install для установки нового дистрибутива Linux при помощи восходящего потока репозитория Интернета в качестве источника такой установки и затем применить команду virsh для подключения к запущенному экземпляру с помощью имеющейся консоли.

Приготовление

Для данного рецепта нам потребуется следующее:

Сама команда virsh
Команда virt-install
Подключение к Интернету для выгрузки необходимых файлов установки

Как это сделать...

Для построения некоего нового экземпляра KVM и подключения к нему при помощи имеющейся консоли осуществите следующие шаги:

Установите новую виртуальную машину KVM воспользовавшись официальным репозиторием Debian:


root@kvm:~# virt-install --name kvm1 --ram 1024 --extra-args="text console=tty0 utf8 console=ttyS0,115200" --graphics vnc,listen=146.20.141.158 --hvm --location=http://ftp.us.debian.org/debian/dists/stable/main/installer-amd64/ --disk path=/tmp/kvm1.img,size=8

Retrieving file MANIFEST... | 3.3 kB 00:00 ...
Retrieving file linux... | 6.0 MB 00:00 ...
Retrieving file initrd.gz... | 29 MB 00:00 ...
Creating storage file kvm1.img | 8.0 GB 00:00
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.
root@kvm:~#

Подключитесь к своей консоли для выполнения установки путём запуска следующего кода:
```
root@kvm:~# virsh console kvm1
Connected to domain kvm1
Escape character is ^]
 	   
```
После подключения к имеющейся консоли вам должен быть представлен некий экран, подобный следующему:

Рисунок 2-1
Выполните установку следуя за приглашениями соответствующего текстового меню.

Запустите вновь предоставленную ВМ:


root@kvm:~# virsh start kvm1
Domain kvm1 started

root@kvm:~#

Воспользовавшись своим любимым клиентом VNC подключитесь к этому экземпляру, зарегистрируйтесь при помощи созданных вами в процессе установки на шаге 3 имени пользователя и пароля и разрешите доступ последовательной консоли выполнив такую команду:
```
root@debian:~# systemctl enable serial-getty@ttyS0.service
root@debian:~# systemctl start serial-getty@ttyS0.service
root@debian:~#
 	   
```

Закройте свой сеанс VNC и подключитесь к своему виртуальному экземпляру со своего хоста ОС при помощи virsh:


root@kvm:~# virsh console kvm1
Connected to domain kvm1
Escape character is ^]

Debian GNU/Linux 8 debian ttyS0

debian login: root
Password:
Last login: Wed Mar 22 16:38:10 CDT 2017 on tty1
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@debian:~# free -m
 total used free shared buffers cached
Mem: 1000 98 902 4 9 43
-/+ buffers/cache: 44 956
Swap: 382 0 382
root@debian:~#

Отключитесь от своей консоли воспользовавшись с клавиатуры комбинацией Ctrl + ].

Проверьте свой файл image, созданный после установки:


root@kvm:~# qemu-img info /tmp/kvm1.img
image: /tmp/kvm1.img
file format: raw
virtual size: 8.0G (8589934592 bytes)
disk size: 1.9G
root@kvm:~#

Совет

	Совет
Если вы пользуетесь в своём дистрибутиве для создаваемой машины KVM системой на основе systemd `init`, для допуска доступа к имеющейся последовательной консоли её экземпляра вам потребуется изменить файл `/etc/securetty` или `/etc/inittab`.

Если вы пользуетесь в своём дистрибутиве для создаваемой машины KVM системой на основе systemd init, для допуска доступа к имеющейся последовательной консоли её экземпляра вам потребуется изменить файл /etc/securetty или /etc/inittab.

Как это работает...

Много чего сделано в данном рецепте, поэтому давайте подробнее пройдём по его шагам.

На шаге 1 мы запустили свой процесс установки для какого- то нового экземпляра воспользовавшись утилитой virt-install. С помощью параметра --extra-args мы определили включённой необходимую последовательную консоль на протяжении процесса установки. Также мы воспользовались флагом --location чтобы сообщить своему libvirt необходимое местоположение всех файлов установки самого последнего дистрибутива Debian. Затем мы определяем местоположение и размер своего файла образа, который будет содержать получаемую файловую систему гостевой ОС. Так как этот файл не существует, virt-install создаёт его как некий сырой образ, что показано на шаге 9.

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

По завершению установки имеющийся сеанс консоли был прекращён и наш новый экземпляр KVM готов к запуску. На шаге 5 мы запускаем этот экземпляр.

Чтобы включить доступ к консоли через имеющийся последовательный порт на шаге 6 мы вначале подключаемся к запущенной ВМ с помощью некого клиента VNC и предписываем systemd запустить службу консоли.

При включённом доступе к консоли у нас есть возможность на шаге 7 подключиться к своей последовательной консоли с помощью инструмента virsh.

После того как это всё выполнено, у нас теперь есть два способа подключения к запущенному экземпляру KVM: либо через VNC, либо через консоль.

В своём идущем далее рецепте мы включим в гостевой ОС сетевую среду и предоставим третий способ подключения с помощью SSH.

Управление ресурсами ЦПУ и памяти в KVM

Изменение объёма выделяемой памяти или числа ЦПУ может быть осуществлено либо путём редакции имеющегося определения XML для конкретной ВМ, или при помощи набора инструментов libvirt. В данном рецепте мы собираемся рассмотреть примеры изменения как памяти, так и числа ЦПУ для некоего экземпляра KVM.

Приготовление

Для данного рецепта нам потребуется следующее:

Исполняемый экземпляр KVM с выделенными ему 1 ГБ памяти и 1 ЦПУ, а также с консольным доступом
Пакет libvirt
Некая гостевая ОС с по крайней мере 4 ГБ доступной памяти и минимум 4 ЦПУ

Как это сделать...

Чтобы проинспектировать и изменить имеющиеся ресурсы памяти и ЦПУ в какой- то виртуальной машине следуйте приводимому ниже процессу:

Получите статистические данные памяти для своего исполняемого экземпляра:
```
root@kvm:~# virsh dommemstat kvm1
actual 1048576
swap_in 0
rss 333644

root@kvm:~#
 	   
```
Обновите значение доступной памяти для этой машины до 2 ГБ:
```
root@kvm:~# virsh setmem kvm1 --size 1049000

root@kvm:~#
 	   
```

Остановите исполняемый экземпляр:


root@kvm:~# virsh destroy kvm1
Domain kvm1 destroyed

root@kvm:~#

Установите значение максимума использования памяти в 2 ГБ:
```
root@kvm:~# virsh setmaxmem kvm1 --size 2097152

root@kvm:~#
 	   
```

Запустите это экземпляр:


root@kvm:~# virsh start kvm1
Domain kvm1 started

root@kvm:~#

Проверьте объём выделенной в настоящее время памяти:
```
root@kvm:~# virsh dommemstat kvm1
actual 2097152
swap_in 0
rss 214408

root@kvm:~#
 	   
```

Подключитесь к этому экземпляру KVM и проверьте память гостевой ОС:


root@kvm:~# virsh console kvm1
Connected to domain kvm1
Escape character is ^]

Debian GNU/Linux 8 debian ttyS0

debian login: root
Password:
...
root@debian:~# free -m
                     total used  free  shared  buffers cached
Mem:                  2010   93  1917        5       8     40
-/+ buffers/cache:      43 1966
Swap:                  382    0  3 82
root@debian:~#
root@kvm:~#

Проверьте настройки памяти в определении XML данного экземпляра:
```
root@kvm:~# virsh dumpxml kvm1 | grep memory
 2097152
root@kvm:~#
 	   
```

Получите информацию относительно ЦПУ гостевой ОС:


root@kvm:~# virsh vcpuinfo kvm1
VCPU: 0
CPU: 29
State: running
CPU time: 9.7s
CPU Affinity: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

root@kvm:~#

Перечислите общее число виртуальных ЦПУ, используемых этой гостевой ОС:
```
root@kvm:~# virsh vcpucount kvm1
maximum config 1
maximum live 1
current config 1
current live 1

root@kvm:~#
 	   
```

Измените для данной ВМ число выделяемых ЦПУ на 4:


root@kvm:~# virsh edit kvm1
...
<vcpu placement='static'>4</vcpu>
...
Domain kvm1 XML configuration edited.

root@kvm:~#

Убедитесь что установленное обновление числа ЦПУ вступило в действие:


root@kvm:~# virsh vcpucount kvm1
maximum config 4
maximum live 4
current config 4
current live 4

root@kvm:~# virsh dumpxml kvm1 | grep -i cpu
 <vcpu placement='static'>4</vcpu>
root@kvm:~#

Как это работает...

На шаге 1 мы получили некие статистические сведения для своего исполняемого экземпляра KVM. Из этого вывода мы можем видеть, что наша ВМ настроена с 1 ГБ памяти, указанным как действующий параметр и в настоящее время использующей 333644 кБ памяти.

На шаге 2 мы обновили доступную память до 2 ГБ и затем продолжили на 4 шаге обновлением значения максимальной памяти, которое может быть выделено для данного экземпляра. Для выполнения этой операции данный экземпляр вначале следует остановить, что показано на шаге 3.

На шагах 5, 6 и 7 мы убедились что эти обновления вступили в действие вначале выполнив субкоманду dommemstat, затем подключившись к консоли этой ВМ и, наконец, проверив текущие настройки выводом дампа определений данного экземпляра.

Команда virsh предоставляет несколько субкоманд для инспекции состояния ЦПУ некоторой запущенной ВМ. На шагах 9 и 10 мы перечислили выделенные виртуальные ЦПУ для своего экземпляра kvm1, в данном случае он у нас всего один, а также его текущее состояние, загруженность и степень родства.

Наконец, на шагах 11 и 12 мы обновили имеющееся определение XML своего экземпляра, выделив четыре ЦПУ и перечисли новое количество.

Также ознакомьтесь...

В этом рецепте мы пользовались имеющейся командой virsh с различными субкомандами в единой строке. Это в частности полезно если вам следует запускать такие команды из некого сценария. Данная команда virsh также предоставляет некий интерактивный терминал, который сохраняет некий набор и предоставляет контекстную помощь. Чтобы запустить такой терминал интерактивной виртуализации выполните следующий код:


root@kvm:~# virsh
Welcome to virsh, the virtualization interactive terminal.

Type: 'help' for help with commands
 'quit' to quit

virsh #

Набрав help вы получите перечень всех доступных субкоманд с их кратким описанием. Для получения дополнительной информации по конкретной субкоманде наберите:


virsh # help vcpucount
 NAME
   vcpucount - domain vcpu counts

 SYNOPSIS
   vcpucount  [--maximum] [--active] [--live] [--config] [--current] [--guest]

 DESCRIPTION
   Returns the number of virtual CPUs used by the domain.

 OPTIONS
   [--domain]  domain name, id or uuid
   --maximum get maximum count of vcpus
   --active get number of currently active vcpus
   --live get value from running domain
   --config get value to be used on next boot
   --current get value according to current domain state
   --guest retrieve vcpu count from the guest instead of the hypervisor

virsh #

Все те шаги, которые мы выполнили в этом рецепте могут быть осуществлены в соответствующем интерактивном терминале.

Подключение блочных устройств к виртуальным машинам

В данном рецепте мы намерены изучить несколько различных способов добавления новых блочных устройств к какому- то экземпляру KVM. Такое новое блочное устройство затем может быть снабжено разделами, отформатировано и применяться как обычное блочное устройство внутри вашей гостевой ОС. Мы можем добавлять диски для работающих в реальном масштабе времени экземпляров или же можем подключать их на постоянной основе создавая определения XML для таких индивидуальных блочных устройств в отключённом режиме. Из ОС своего хоста мы можем представлять любые типы файлов блочных устройств в его гостевые, в том числе, целевые iSCSI, логические тома LVM или файлы образа.

Приготовление

В данном рецепте на понадобятся:

Некий исполняемый экземпляр KVM с консольным доступом
Утилита dd

Как это сделать...

Для подключения нового блочного устройства к гостевой KVM выполните следующее:

Создайте некий новый файл образа с размером 1 ГБ:


root@kvm:~# dd if=/dev/zero of=/tmp/new_disk.img bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.670831 s, 1.6 GB/s
root@kvm:~#

Подключите этот файл в качестве нового диска к своему экземпляру KVM:
```
root@kvm:~# virsh attach-disk kvm1 /tmp/new_disk.img vda --live
Disk attached successfully

root@kvm:~#
 	   
```

Присоединитесь к этому экземпляру KVM через консоль:


root@kvm:~# virsh console kvm1
Connected to domain kvm1
Escape character is ^]

Debian GNU/Linux 8 debian ttyS0

debian login: root
Password:
...
root@debian:~#

Выведите на печать буфер кольца ядра и проверьте своё новое блочное устройство:


root@debian:~# dmesg | grep vda
[ 3664.134978] sd 2:0:2:0: [vda] 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB)
[ 3664.135248] sd 2:0:2:0: [vda] Write Protect is off
[ 3664.135251] sd 2:0:2:0: [vda] Mode Sense: 63 00 00 08
[ 3664.135340] sd 2:0:2:0: [vda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 3664.138254] vda: unknown partition table
[ 3664.139008] sd 2:0:2:0: [vda] Attached SCSI disk
root@debian:~#

Изучите это новое блочное устройство:


root@debian:~# fdisk -l /dev/vda

Disk /dev/vda: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
root@debian:~#

Выведите дамп настроек данного экземпляра из ОС её хоста:


root@kvm:~# virsh dumpxml kvm1
<domain type='kvm' id='23'>
...
 <devices>
   <emulator>/usr/bin/qemu-system-x86_64</emulator>
   <disk type='file' device='disk'>
     <driver name='qemu' type='raw'/>
     <source file='/tmp/kvm1.img'/>
     <target dev='hda' bus='ide'/>
     <alias name='ide0-0-0'/>
     <address type='drive' controller='0' bus='0' target='0' unit='0'/>
   </disk>
   <disk type='file' device='disk'>
     <driver name='qemu' type='raw'/>
     <source file='/tmp/new_disk.img'/>
     <target dev='vda' bus='scsi'/>
     <alias name='scsi0-0-2'/>
     <address type='drive' controller='0' bus='0' target='0' unit='2'/>
   </disk>
 </devices>
</domain>

root@kvm:~#

Получите информацию о своём новом диске:


root@kvm:~# virsh domblkstat kvm1 vda
vda rd_req 119
vda rd_bytes 487424
vda wr_req 0
vda wr_bytes 0
vda flush_operations 0
vda rd_total_times 29149092
vda wr_total_times 0
vda flush_total_times 0

root@kvm:~#

Отсоедините этот диск:


root@kvm:~# virsh detach-disk kvm1 vda --live
Disk detached successfully

root@kvm:~#

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


root@kvm:~# cp /tmp/new_disk.img /tmp/other_disk.img
root@kvm:~#

Запишите следующий файл config:


root@kvm:~# cat other_disk.xml
<disk type='file' device='disk'>
 <driver name='qemu' type='raw' cache='none'/>
 <source file='/tmp/other_disk.img'/>
 <target dev='vdb'/>
</disk>
root@kvm:~#

Подключите полученное новое блочное устройство:


root@kvm:~# virsh attach-device kvm1 --live other_disk.xml
Device attached successfully

root@kvm:~#

Отключите это новое блочное устройство:


root@kvm:~# virsh detach-device kvm1 other_disk.xml --live
Device detached successfully

root@kvm:~#

Как это работает...

Подключение дополнительных дисков к запущенным экземплярам KVM может быть достаточно полезным, в особенности при использовании LVM внутри его гостевой ОС, поскольку это позволяет расширять имеющиеся логические тома, тем самым добавляя дополнительное дисковое пространство на ходу. Libvirt предоставляет два различных метода для этого, как мы это уже видели в отображённых ранее шагах. Мы можем воспользоваться командой virsh attach-disk передавая местоположение соответствующего файла образа и само название такого нового блочного устройства для имеющейся гостевой ВМ, как мы это наблюдали на шаге 2.

На шаге 1 мы создали некий новый сырой образ воспользовавшись командой dd; однако мы можем применять и инструментарий qemu-img, как мы это видели в своём рецепте Управление образами дисков при помощи qemu-img из Главы 1.

После подключения такого нового диска на шаге 2, на шагах 3, 4 и 5 мы подключаемся к ВМ и проверяем что новое блочное устройство и в самом деле присутствует. Это также отражается в определении соответствующего XML для данного экземпляра на шаге 6.

	Замечание
	Чтобы сделать такое новое устройство доступным после перезапуска ВМ и постоянно присутствующим в изменениях определения XML передайте надлежащий параметр `--persist` в свою команду `virsh attach-disk`.

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

На шаге 8 мы отключаем этот диск от своего запущенного экземпляра KVM. Если вы выведете дамп определения этого экземпляра в этот момент, вы отметите отсутствие своего дополнительного диска.

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

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

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

Совместное применение каталогов исполняемыми ВМ и самой ОС хоста

В своём предыдущем рецепте мы видели два примера того как подключать диски к некому исполняемому экземпляру KVM. В этом рецепте мы намерены разделять некий каталог из своего хоста делать его доступным в его виртуальных машинах. Однако мы можем это делать только с неким остановленным экземпляром. Если вы следуете за нами, у вас уже должен иметься некий экземпляр KVM libvirt, которым вы можете воспользоваться.

Приготовление

Предварительные требования для данного рецепта таковы:

Остановленный экземпляр KVM libvirt с консольным доступом
Некая гостевая ОС с модулями ядра 9p и virtio (доступными по умолчанию в большинстве дистрибутивов)

Как это сделать...

Для совместного использования некоторого каталога из ОС вашего хоста для имеющихся гостевых KVM выполните следующее:

Создайте некий новый каталог в ОС своего хоста и добавьте к него какой- нибудь файл:
```
root@kvm:~# mkdir /tmp/shared
root@kvm:~# touch /tmp/shared/file
root@kvm:~#
 	   
```

Добавьте следующее определение для останова экземпляра KVM:


root@kvm:~# virsh edit kvm1
 ...
 <devices>
   ...
   <filesystem type='mount' accessmode='passthrough'>
     <source dir='/tmp/shared'/>
     <target dir='tmp_shared'/>
   </filesystem>
   ...
 </devices>
 ...
Domain kvm1 XML configuration edited.

root@kvm:~#

Запустите эту ВМ:


root@kvm:~# virsh start kvm1
Domain kvm1 started

root@kvm:~#

Подключитесь к его консоли следующим образом:


root@kvm:~# virsh console kvm1
Connected to domain kvm1
Escape character is ^]

Debian GNU/Linux 8 debian ttyS0

debian login: root
Password:
...
root@debian:~#

Убедитесь что загружены необходимые модули ядра 9p и virtio:


root@debian:~# lsmod | grep 9p
9pnet_virtio 17006 0
9pnet 61632 1 9pnet_virtio
virtio_ring 17513 3 virtio_pci,virtio_balloon,9pnet_virtio
virtio 13058 3 virtio_pci,virtio_balloon,9pnet_virtio
root@debian:~#

Смонтируйте ваш разделяемый каталог /mnt:


root@debian:~# mount -t 9p -o trans=virtio tmp_shared /mnt
root@debian:~#

Перечислите своё новое монтирование:


root@debian:~# mount | grep tmp_shared
tmp_shared on /mnt type 9p (rw,relatime,sync,dirsync,trans=virtio)
root@debian:~#

Убедитесь что ваш совместно используемый файл виден в ОС вашего хоста:


root@debian:~# ls -la /mnt/
total 8
drwxr-xr-x 2  root root 4096 Mar 23 11:25 .
drwxr-xr-x 22 root root 4096 Mar 22 16:28 ..
-rw-r--r-- 1  root root 0    Mar 23 11:25 file
root@debian:~#

Как это работает...

Давайте пройдёмся по всем шагам и рассмотрим более подробно что было выполнено в нашем предыдущем разделе.

На шаге 1 мы создали некий каталог и какой- то файл, который мы желаем разделять в своей гостевой ОС. Затем в своём остановленном экземпляре KVM мы добавили на шаге 2 требуемое определение новой <filesystem>. Мы применяем такой тип монтирования, поскольку мы монтируем некий каталог и определяем соответствующий accessmode, который определяет необходимый режим безопасности для доступа к этому совместному ресурсу. Существует три режима доступа:

passthrough: Это устанавливаемый по умолчанию режим, который осуществляет доступ к совместному каталогу с применением установленных полномочий для имеющегося внутри самой гостевой ОС пользователя
mapped: В этом режиме данный разделяемый каталог и его файлы доступны при помощи установленных полномочий самого пользователя QEMU, наследуемого из основного хоста
squash: Этот режим аналогичен режиму passthrough; однако игнорируются все отказы привилегированных операций, таких как chmod

Расставив всё по своим местам мы запускаем свою ВМ на шаге 3 и подключаемся к ней на шаге 4.

В той виртуальной машине Debian, которую мы применяли, требующиеся нам модули ядра были загружены при запуске этой ВМ. Если для вашей ВМ это не так, загрузите эти модули, исполнив:


root@debian:~# modprobe 9p virtio
root@debian:~#

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

Также ознакомьтесь...

В этой главе мы запускали виртуальные машины KVM при помощи команды virsh, предоставляемой набором инструментов и библиотек libvirt. Если вы проверите имеющееся дерево процессов после запуска некого гостя, вы обнаружите что команда virsh на самом деле вызывает исполняемый файл /usr/bin/qemu-system-x86_64. Если вы вспомните наш рецепт Выполнение ВМ при помощи qemu-system-* из Главы 1, именно он в точности применялся для запуска виртуальных машин QEMU/ KVM.

Отметим тот процесс, который запускает демон libvirt когда мы запускали в этом рецепте свой экземпляр KVM:


root@kvm:~# pgrep -lfa qemu
6233 /usr/bin/qemu-system-x86_64 -name kvm1 -S -machine pc-i440fx-trusty,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 6ad84d8a-229d-d1f6-ecfc-d29a25fcfa03 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/kvm1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device lsi,id=scsi0,bus=pci.0,addr=0x5 -drive file=/tmp/kvm1.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -fsdev local,security_model=passthrough,id=fsdev-fs0,path=/tmp/shared -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=tmp_shared,bus=pci.0,addr=0x6 -netdev tap,fd=25,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:c5:c8:9d,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 146.20.141.158:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
root@kvm:~#

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


root@kvm:~# qemu-system-x86_64 -name debian -fsdev local,id=tmp,path=/tmp/shared,security_model=passthrough -device virtio-9p-pci,fsdev=tmp,mount_tag=tmp_shared -enable-kvm -usbdevice tablet -vnc 146.20.141.158:0 -m 1024 -drive format=raw,file=/tmp/kvm1.img -daemonize
root@kvm:~#

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

Автоматический запуск экземпляров KVM

После того как некий экземпляр KVMбул определён и запущен, он будет работать пока поднята ОС самого хоста. После перезапуска ОС самого хоста построенные при помощи libvirt экземпляры не будут запускаться автоматически после подъёма этого хоста и запуска соответствующего демона libvirt. В этом рецепте мы намерены изменить такое поведение и гарантировать запуск виртуального экземпляра при старте самого демона libvirt.

Приготовление

Для данного рецепта нам понадобится отдельный экземпляр KVM построенный при помощи libvirt.

Как это сделать...

Для настройки автоматического запуска некого гостя KVM после перезапуска сервера или libvirtd, исполните следующее:

Включите autostart своей ВМ:


root@kvm:~# virsh autostart kvm1
Domain kvm1 marked as autostarted

root@kvm:~#

Получите информацию для этого экземпляра:


root@kvm:~# virsh dominfo kvm1
Id: 31
Name: kvm1
UUID: 6ad84d8a-229d-d1f6-ecfc-d29a25fcfa03
OS Type: hvm
State: running
CPU(s): 2
CPU time: 10.9s
Max memory: 2097152 KiB
Used memory: 1048576 KiB
Persistent: yes
Autostart: enable
Managed save: no
Security model: none
Security DOI: 0

root@kvm:~#

Остановите свой исполняемый экземпляр и убедитесь что он находится в состоянии shut off:


root@kvm:~# virsh destroy kvm1
Domain kvm1 destroyed

root@kvm:~# virsh list --all
 Id  Name  State
----------------------------------------------------
 -   kvm1  shut off

root@kvm:~#

Остановите свой демон libvirt и убедитесь что он не исполняется:


root@kvm:~# /etc/init.d/libvirt-bin stop
libvirt-bin stop/waiting
root@kvm:~# pgrep -lfa libvirtd
root@kvm:~#

Запустите снова своего демона libvirt:


root@kvm:~# /etc/init.d/libvirt-bin start
libvirt-bin start/running, process 6639
root@kvm:~#

Перечислите все исполняемые экземпляры:


root@kvm:~# virsh list --all
 Id Name State
----------------------------------------------------
 2  kvm1 running

root@kvm:~#

Запретите параметр autostart:


root@kvm:~# virsh autostart kvm1 --disable
Domain kvm1 unmarked as autostarted

root@kvm:~#

Проверьте это изменение:


root@kvm:~# virsh dominfo kvm1 | grep -i autostart
Autostart: disable
root@kvm:~#

Как это работает...

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

На шаге 1 мы включили autostart и на шаге проверили что оно включено.

Далее для имитации перезапуска сервера мы вначале на шаге 3 остановили свой запущенный экземпляр, а сам демон libvirt на шаге 4.

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

Наконец, на шагах 7 и 9 мы отключили свойство autostart и проверили что оно на самом деле было отключено.

Работа с пулами хранения

Libvirt предоставляет некий централизованный способ управления томами экземпляра (будь это файлы образа или каталоги) через определение пулов хранения. Некий пул хранения это какая- то коллекция томов, которая затем может назначаться виртуальным машинам и применяться для размещения их файловых систем и добавления в качестве дополнительных блочных устройств. Самыми основными преимуществами использования пулов хранения является наличие возможности для libvirt представлять конкретный тип хранения для ВМ неким централизованным образом и управлять им.

На момент написания данного текста доступны такие основы пулов хранения:

Каталоги
Локальные файловые системы
Сетевые файловые системы
Логические основы
Диски
iSCSI
SCSI
Основы со множеством путей
Блочные устройства RADOS
Sheepdog
Gluster
ZFS
Хранилище Virtuozzo

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

Приготовление

Для данного рецепта нам понадобится следующее:

Сырой образ, который мы создали в рецепте Построение новых экземпляров KVM при помощи virt-install и с применением консоли
Пакет libvirt

Как это сделать...

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

Скопируйте тот файл сырого образа Debian, который мы создали ранее в данной главе в рецепте Построение новых экземпляров KVM при помощи virt-install и с применением консоли:
```
root@kvm:~# cp /tmp/kvm1.img /var/lib/libvirt/images/
root@kvm:~#
 	   
```

Создайте определение следующего пула хранения:


root@kvm:~# cat file_storage_pool.xml
<pool type="dir">
 <name>file_virtimages</name>
 <target>
   <path>/var/lib/libvirt/images</path>
 </target>
</pool>

Определите свой новый пул хранения:


root@kvm:~# virsh pool-define file_storage_pool.xml
Pool file_virtimages defined from file_storage_pool.xml

root@kvm:~#

Выведите перечень всех пулов хранения:


root@kvm:~# virsh pool-list --all
 Name            State    Autostart
-------------------------------------------
 file_virtimages inactive no

root@kvm:~#

Запустите свой новый пул хранения и убедитесь что он активен:


root@kvm:~# virsh pool-start file_virtimages
Pool file_virtimages started

root@kvm:~# virsh pool-list --all
 Name            State  Autostart
-------------------------------------------
 file_virtimages active no

root@kvm:~#

Включите свойство autostart в данном пуле хранения:


root@kvm:~# virsh pool-autostart file_virtimages
Pool file_virtimages marked as autostarted

root@kvm:~# virsh pool-list --all
 Name            State  Autostart
-------------------------------------------
 file_virtimages active yes

root@kvm:~#

Получите дополнительные сведения об этом пуле хранения:


root@kvm:~# virsh pool-info file_virtimages
Name: file_virtimages
UUID: d51d500b-8885-4c26-8000-2ae46ffe9018
State: running
Persistent: yes
Autostart: yes
Capacity: 219.87 GiB
Allocation: 7.99 GiB
Available: 211.88 GiB

root@kvm:~#

Перечислите все тома, которые являются частями данного пула хранения:


root@kvm:~# virsh vol-list file_virtimages
 Name     Path
----------------------------------------------------
 kvm1.img /var/lib/libvirt/images/kvm1.img

root@kvm:~#

Получите информацию об этом томе:


root@kvm:~# virsh vol-info /var/lib/libvirt/images/kvm1.img
Name: kvm1.img
Type: file
Capacity: 8.00 GiB
Allocation: 1.87 GiB

root@kvm:~#

Запустите новый экземпляр KVM при помощи данных пула хранения и тома, затем убедитесь что всё работает:


root@kvm:~# virt-install --name kvm1 --ram 1024 --graphics vnc,listen=146.20.141.158 --hvm --disk vol=file_virtimages/kvm1.img --import

Starting install...
Creating domain... | 0 B 00:00
Domain creation completed. You can restart your domain by running:
 virsh --connect qemu:///system start kvm1
root@kvm:~#

root@kvm:~# virsh list --all
 Id Name State
----------------------------------------------------
 3  kvm1 running

root@kvm:~#

Как это работает...

Мы начали этот рецепт с неким образом ОС Debian, который мы устанавливали и ранее в данной книге; однако, вы можете применять и образ empty, raw или qcow2, добавить его в этот пул хранения и установить ОС своей виртуальной машины в нём почти без каких либо изменений во всех шагах данного рецепта если у вас ещё пока нет ещ данного образа.

На шаге 1 мы скопировали необходимый образ ВМ в местоположение пула хранилища libvirt по умолчанию в /var/lib/libvirt/images/, но вы можете создать и свой собственный каталог, его местоположение не важно, поскольку оно определяется в соответствующем файле настроек этого пула хранения. Мы делаем это на шаге 2.

На шаге 2 мы определяем этот новый пул хранения устанавливая некие название, целевой каталог и тип самого пула, в данном случае пул на основе каталога. Затем мы продолжаем списком своего нового пула на шаге 4. Отметим, что после его определения нам всё ещё требцется запустить его, в точности как и при определении некого нового экземпляра из какого- то файла XML. По умолчанию параметр autostart в неком новом пуле хранения отключён.

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

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

На шаге 8 мы перечисляем все тома, которые являются частями нашего нового пула хранения и получаем дополнительную информацию относительно нашего отдельного тома на шаге 9.

Наконец, на шаге 10 мы запускаем некий новый экземпляр KVM применяя свой пул хранения и том, передавая названия этого пула хранения и тома в соответствующий тип диска vol.

Также ознакомьтесь...

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

За рамки данного рецепта выходят создание некоторой цели iSCSI и регистрации их в соответствующем инициаторе, поэтому допустим что у вас уже имеется некая цель iSCSI готовая к использованию с какого- то удалённого сервера. Соответствующие определения нового пула хранения таковы:


<pool type='iscsi'>
 <name>iscsi_virtimages</name>
 <source>
   <host name='iscsi-target.linux-admins.net'/>
   <device path='iqn.2004-04.ubuntu:ubuntu16:iscsi.libvirtkvm'/>
 </source>
 <target>
   <path>/dev/disk/by-path</path>
 </target>
</pool>

Этот файл очень похож на пул хранения на основе каталога, а основное отличие заключается в следующих атрибутах:

Атрибут <host> определяет название хоста соответствующего сервера цели iSCSI, который экспортирует данный iSCSI LUN
<device> определяет само название того iSCSI LUN, к которому мы намерены подключиться
После того как выполена регистрация какого- то нового блочного устройства iSCSI, оно появится в том местоположении, которое определено в <path>, для большинства дистрибутивов Linux это каталог /dev/disk/by-path

Мы определили и запустили некий новый пул хранения тем же самым образом, как мы это делали в шагах 3 и 5 ранее в этом рецепте. После того как этот пул стал активным, libvirt зарегистрирует эти целевые LUN iSCSI. Мы можем перечислить все доступные тома iSCSI как обычно:


root@kvm:~# virsh vol-list iscsi_virtimages
Name Path
-----------------------------------------
10.0.0.1 /dev/disk/by-path/ip-10.184.226.106:3260-iscsiiqn.2004-04.ubuntu:ubuntu16:iscsi.libvirtkvm-lun-1
root@kvm:~#

Чтобы запустить некий новый процесс установки при помощи такого тома iSCSI в качестве основной цели для фаловой системы вашей гостевой ОС исполните такой код:


root@kvm:~# virt-install --name kvm1 --ram 1024 --extra-args="text console=tty0 utf8 console=ttyS0,115200" --graphics vnc,listen=146.20.141.158 --hvm --location=http://ftp.us.debian.org/debian/dists/stable/main/installer-amd64/ --disk vol=iscsi_virtimages/10.0.0.1
Starting install...
...
root@kvm:~#

	Замечание
	Для получения дополнительной информации относительно соответствующего определения XML для прочих типов основ, просим вас воспользоваться https://libvirt.org/storage.html.

Управление томами

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

Приготовление

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

Как это сделать...

Для создания, инспекции и назначения томов некому экземпляру выполните следующее:

Выведите перечень всех доступных пулов хранения:


root@kvm:~# virsh pool-list --all
 Name            State  Autostart
-------------------------------------------
 file_virtimages active yes

root@kvm:~#

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


root@kvm:~# virsh vol-list file_virtimages
 Name     Path
--------------------------------------------------------------------
 kvm1.img /var/lib/libvirt/images/kvm1.img

root@kvm:~#

Создайте некий новый том с заданным размером:


root@kvm:~# virsh vol-create-as file_virtimages new_volume.img 9G
Vol new_volume.img created

root@kvm:~#

Перечислите все тома в заданной файловой системе:


root@kvm:~# ls -lah /var/lib/libvirt/images/
total 11G
drwx--x--x 2 root root 4.0K Mar 23 20:38 .
drwxr-xr-x 8 root root 4.0K Mar 21 23:16 ..
-rwxr-xr-x 1 libvirt-qemu kvm 8.0G Mar 23 20:23 kvm1.img
-rw------- 1 root root 9.0G Mar 23 20:38 new_volume.img
root@kvm:~#

получите информацию о своём новом томе:


root@kvm:~# qemu-img info /var/lib/libvirt/images/new_volume.img
image: /var/lib/libvirt/images/new_volume.img
file format: raw
virtual size: 9.0G (9663676416 bytes)
disk size: 9.0G
root@kvm:~#

Для получения ещё дополнительных сведений воспользуйтесь командой virsh:


root@kvm:~# virsh vol-info new_volume.img --pool file_virtimages
Name: new_volume.img
Type: file
Capacity: 9.00 GiB
Allocation: 9.00 GiB

root@kvm:~#

Выведите дамп настроек этого тома:


root@kvm:~# virsh vol-dumpxml new_volume.img --pool file_virtimages
<volume type='file'>
 <name>new_volume.img</name>
 <key>/var/lib/libvirt/images/new_volume.img</key>
 <source>
 </source>
 <capacity unit='bytes'>9663676416</capacity>
 <allocation unit='bytes'>9663680512</allocation>
 <target>
   <path>/var/lib/libvirt/images/new_volume.img</path>
   <format type='raw'/>
   <permissions>
     <mode>0600</mode>
     <owner>0</owner>
     <group>0</group>
   </permissions>
   <timestamps>
     <atime>1490301514.446004048</atime>
     <mtime>1490301483.698003615</mtime>
     <ctime>1490301483.702003615</ctime>
   </timestamps>
 </target>
</volume>

root@kvm:~#

Измените размер тома и отобразите его новый размер:


root@kvm:~# virsh vol-resize new_volume.img 10G --pool file_virtimages
Size of volume 'new_volume.img' successfully changed to 10G

root@kvm:~# virsh vol-info new_volume.img --pool file_virtimages
Name: new_volume.img
Type: file
Capacity: 10.00 GiB
Allocation: 9.00 GiB

root@kvm:~#

Удалите созданный том и перечислите все доступные тома в имеющемся пуле хранения:


New-VM -Name VM01 -Generation 2root@kvm:~# virsh vol-delete new_volume.img --pool file_virtimages
Vol new_volume.img deleted

root@kvm:~# virsh vol-list file_virtimages
 Name     Path
------------------------------------------------------------------
 kvm1.img /var/lib/libvirt/images/kvm1.img

root@kvm:~#

Клонируйте свой существующий том:


root@kvm:~# virsh vol-clone kvm1.img kvm2.img --pool file_virtimages
Vol kvm2.img cloned from kvm1.img

root@kvm:~# virsh vol-list file_virtimages
 Name     Path
--------------------------------------------------------------------
 kvm1.img /var/lib/libvirt/images/kvm1.img
 kvm2.img /var/lib/libvirt/images/kvm2.img

root@kvm:~#

Как это работает...

Мы начали этот рецепт с пулом хранения file_virtimages, который мы создали в своём предыдущем рецепте. Для подтверждения этого на шаге 1 мы перечислили все пулы хранения. На шаге 2 мы увидели что наш пул хранения содержит один единственный том. В этом нет сюрприза, поскольку мы создали его в своём последнем рецепте данной главы.

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

В шагах 5 и 6 мы собрали дополнительную информацию о своём новом томе. Мы можем видеть что он является сырым, более того по умолчанию неким разбросанным образом. Разбросанным (sparse) образам не выделяется всё дисковое пространство и он растёт по мере записи в него данных.

На шаге 7 мы выводим дамп определения этого тома. Мы можем воспользоваться им для определения некого нового тома позднее с помощью команды virsh vol-create.

Libvirt предоставляет удобный способ изменения размера существующих образов. Именно это мы и сделали на шаге 8 - мы изменили размер своего образа до 10 ГБ. Теперь мы можем видеть, что выделенный размер меньше общей ёмкости; это происходит по причине того, что наш том сырой.

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

На самом последнем шаге мы воспользовались имеющимся образом Debian и создали из него некий том клона. Запуск некой виртуальной машины с применением такого клонированного тома в результате приведёт к некому идентичному экземпляру, поскольку он был клонирован из соответствующего тома. Это в сочетании с неким дампом определения данного экземпляра является великолепным способом резервного копирования ваших экземпляров KVM, пока вы храните эти образ тома и его файл определения XML в неком удалённом местоположении. Мы намерены изучить резервное копирование экземпляров KVM в своих последующих рецептах.

Управление секретными ключами

Libvirt предоставляет некий API для создания, хранения и применения секретных ключей (secrets). Секретные ключи являются объектами, которые содержат чувствительную информацию, такую как пароли, которая могут быть связаны с различными типами основ тома. Вспомните наш рецепт Работа с пулами хранения, в котором мы создали некий пул хранения iSCSI и том с удалённой цели iSCSI, а также применили его в качестве соответствующего образа для какого- то гостя KVM. В промышленных средах чаще всего цели iSCSI представлены с аутентификацией CHAP. В данном рецепте мы намерены создать некий секретный ключ для его применения с каким- то томом iSCSI.

Приготовление

Для это рецепта нам потребуется следующее:

Некий пул хранения с каким- то томом на основе iSCSI
Пакет libvirt

Как это сделать...

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

Перечислите все доступные ключи секретов:


root@kvm:~# virsh secret-list
 UUID Usage
-------------------------------------------------------------------
root@kvm:~#

Создайте следующее определение ключей секретов:


root@kvm:~# cat volume_secret.xml
<secret ephemeral='no'>
 <description>Passphrase for the iSCSI iscsi-target.linux-admins.net target server</description>
 <usage type='iscsi'>
   <target>iscsi_secret</target>
 </usage>
</secret>
root@kvm:~#

Создайте необходимый ключ секрета и убедитесь что он был успешно создан:


root@kvm:~# virsh secret-define volume_secret.xml
Secret 7ad1c208-c2c5-4723-8dc5-e2f4f576101a created

root@kvm:~# virsh secret-list
 UUID                                 Usage
-----------------------------------------------------------------
 7ad1c208-c2c5-4723-8dc5-e2f4f576101a iscsi iscsi_secret

root@kvm:~#

Установите некое значение для этого ключа секрета:


root@kvm:~# virsh secret-set-value 7ad1c208-c2c5-4723-8dc5-e2f4f576101a $(echo "some_password" | base64)
Secret value set

root@kvm:~#

Создайте некий новый файл определения пула iSCSI:


root@kvm:~# cat iscsi.xml
<pool type='iscsi'>
 <name>iscsi_virtimages</name>
 <source>
   <host name='iscsi-target.linux-admins.net'/>
   <device path='iqn.2004-04.ubuntu:ubuntu16:iscsi.libvirtkvm'/>
   <auth type='chap' username='iscsi_user'>
     <secret usage='iscsi_secret'/>
   </auth>
 </source>
 <target>
   <path>/dev/disk/by-path</path>
 </target>
</pool>
root@kvm:~#

Как это работает...

На шаге 1 мы перечислили все доступные ключи секретов о которых известно libvirt. Поскольку мы их ещё не создавали, данный список пустой.

На шаге 2 мы создали необходимое определение XML для своего ключа секрета. Вот те элементы XML, которые мы применяем при определении своего секретного ключа:

Наш корневой элемент <secret> с неким необязательным атрибутом ephemeral сообщает libvirt что этот пароль должен храниться исключительно в памяти, если он установлен в значение yes.
Следующий атрибут <description> содержит некое произвольное описание.
Элемент <usage> определяет для какого использования предназначены данные ключи секретов. В данном примере значение атрибута type установлено в iSCSI. Прочими допустимыми типами являются volume, ceph и tls. Данный атрибут type обязателен.
Значение элемента <target> определяет произвольное название, которое будет применяться при определении соответствующего пула iSCSI.

Поместив на место соответствующий файл настроек на шаге 3 мы создали необходимый ключ секрета. Если эта операция успешна, libvirt возвращает некий UUID, который указывает на данный ключ секрета.

На шаге 4 мы установили некое значение для этого секретного ключа, закодировав с помощью base64 свою строку some_password, которая является соответствующим паролем для нашей цели iSCSI, которую мы намерены применять в качестве некого тома пула хранения.

И наконец, на шаге 5 мы добавили атрибут <auth> в свой раздел <source> определения нашего пула iSCSI. Отметим, что тот секретный ключ, который мы бы желали использовать своим томом iSCSI определяется в необходимом атрибуте <secret usage='iscsi_secret'/>. Libvirt теперь может применять название iscsi_secret для определения местоположения реального сохранённого пароля.