Глава 2. Архитектура

Содержание

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

Объектная модель

Основная цель как API libvirt, так и модуля libvirt Python состоит в предоставлении всех требующихся для развёртывания виртуальных машин и управления ими функций. К ним относятся управление как функциями ядра гипервизора, так и имеющимися у хоста ресурсами, которые необходимы виртуальным машинам, такими как сетевые возможности, хранилища, а также устройства PCI/ USB. Большинство из этих выставляемых libvirt классов и методов имеют внутреннюю основу подключаемого модуля, предоставляя поддержку различным лежащим в основе технологиям виртуализации и операционных систем. Тем самым та степень функциональности, которая доступна из конкретного API или метода определяются конкретным применимы драйвером гипервизора и возможностями лежащей в основе технологии виртуализации.

Соединения гипервизора

Некое соединение (connection) является самым первичным объектом, или объектом верхнего уровня в API libvirt и модуле libvirt Python. Для применения практически любого из имеющихся классов или объектов необходим некий экземпляр этого объекта. Некое соединение ассоциируется с каким- то конкретным гипервизором, который может быть запущенным локально на той же самой машине что и наше приложение клиента libvirt, либо в некой удалённой машине в имеющейся сетевой среде. В любом случае данное соединение представляется каким- то экземпляром класса virConnect и идентифицируется через некий URI. Значения схемы URI и пути определяют тот гипервизор, к которому необходимо подключаться, в то время как значение части хоста в этом URI определяет где он расположен. Для полного описания допустимых URI обратитесь к разделу Форматы URI Главы 3.

Некому приложению допустимо открывать множество подключений в одно и то же самое время, даже при применении более одного гипервизора в какой- то отдельной машине. Например, некий хост может предоставлять как полную виртуальную машину KVM, так и контейнеры Linux. Некий объект соединения может применяться одновременно (concurrently) во множестве потоков. После того как соединение установлено, имеется возможность обрабатывать прочие объекты или создавать новые управляемые объекты для получения обработчиков для прочих управляемых объектов или создавать новые управляемые объекты, как это обсуждается в нашем следующем разделе "Гостевые домены".

Гостевые домены

Некий гостевой домен может именовать либо к какую- то виртуальную машину, или некую конфигурацию, которая может применяться для запуска какой- то виртуальной машины. Сам объект соединения предоставляет методы для нумерации (enumerate) всех гостевых доменов, создания новых гостевых доменов и управления уже имеющимися доменами. Какой- то гостевой домен представляется с неким экземпляром определённого класса virDomain и имеет какое- то число уникальных идентификаторов.

ID: Это положительное целое, причём уникальное среди всех запущенных гостевых доменов в неком обособленном хосте. Неактивный домен не имеет никакого идентификатора.
Name: Представляет короткую строку, уникальную для всех гостевых доменов в неком обособленном хосте, как запущенных, так и неактивных. Для обеспечения максимальной совместимости между гипервизорами такие названия могут содержать лишь алфавитноцифровые (a–Z, 0–9) символы, символ тире (-) и символ подчёркивания (_).
UUID: Данное значение содержит 16 байт без знака, гарантирующих уникальность по всем гостевым доменам в любом из хостов. RFC 4122 определяет сам формат для UUID и предоставляет рекомендуемый алгоритм для выработки UUID с обеспечением уникальности.

Некий гостевой домен может быть недолговечным (transient) или постоянным (persistent). Недолговечный гостевой домен может управляться только когда он запущен в определённом хосте. После того как он выключен все его отслеживания пропадут. Постоянный гостевой домен имеет свои конфигурации сопровождаемыми в неком хранилище данных в том хосте, в котором расположен гипервизор в неком определяемом реализацией формате. Таким образом, когда какой- то постоянно существующий гость выключен, всё ещё имеется возможность управлять его неактивной конфигурацией. Некий недолговечный гость может быть превращён в постоянного гостя во время его исполнения путём задания его конфигурации.

Виртуальные сети

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

Остаётся изолированной для данного хоста.
Делает возможной маршрутизацию обмена с узла через имеющиеся в ОС этого хоста активные сетевые интерфейсы. К ним относятся вариант применения NAT к обмену IPv4.

Некая виртуальная сетевая среда представляется как какой- то экземпляр имеющегося класса virNetwork и имеет такие два уникальных идентификатора:

Name: Представляет короткую строку, уникальную для всех виртуальных сетей в неком обособленном хосте, как запущенных, так и неактивных. Для обеспечения максимальной совместимости между гипервизорами такие названия могут содержать лишь алфавитноцифровые (a–Z, 0–9) символы, символ тире (-) и символ подчёркивания (_).
UUID: Данное значение содержит 16 байт без знака, гарантирующих уникальность по всем виртуальных сетям в любом из хостов. RFC 4122 определяет сам формат для UUID и предоставляет рекомендуемый алгоритм для выработки UUID с обеспечением уникальности.

Некая виртуальная сеть может быть недолговечной (transient) или постоянной (persistent). Недолговечная виртуальная сеть может управляться только когда она запущена в определённом хосте. После того как он выключен все его отслеживания пропадут. Постоянная виртуальная сеть имеет свои конфигурации сопровождаемыми в неком хранилище данных в том хосте, в котором расположен гипервизор в неком определяемом реализацией формате. Таким образом, когда какая- то постоянно существующая сеть выключена, всё ещё имеется возможность управлять её неактивной конфигурацией. Некая недолговечная сеть может быть превращена в постоянную сеть во время её исполнения путём задания её конфигурации.

После установки libvirt, каждый хост получит некий обособленный экземпляр виртуальной сети с названием default, который предоставляет гостям службы DHCP и делает возможной IP связь NAT с имеющимися у хоста интерфейсами. Такая служба лучше всего подходит для хостов с периодически действующими сетевыми подключениями, такими как применяющие беспроводную связь ноутбуки.

Для получения дополнительных сведений относительно применения виртуальных сетевых объектов обратитесь к Главе 6.

Пулы хранения

Объект пула хранения предоставляет некий механизм для управления всеми типами хранения в хосте, такими как локальные диски, группы логических томов, цели iSCSI, HBA Fibre Channel, а также локальные/ сетевые файловые системы. Неким пулом именуется какой- то объём хранения, который может выделяться в виде индивилуальных томов. Какой- то пул хранения представляется неким экземпляром имеющегося класса virNetwork и имеет пару уникальных идентификаторов.

Name: Представляет короткую строку, уникальную для всех пулов хранения в неком обособленном хосте, как запущенных, так и неактивных. Для обеспечения максимальной совместимости между гипервизорами такие названия могут содержать лишь алфавитноцифровые (a–Z, 0–9) символы, символ тире (-) и символ подчёркивания (_).
UUID: Данное значение содержит 16 байт без знака, гарантирующих уникальность по всем пулам хранения в любом из хостов. RFC 4122 определяет сам формат для UUID и предоставляет рекомендуемый алгоритм для выработки UUID с обеспечением уникальности.

Некий пул хранения может быть недолговечным (transient) или постоянным (persistent). Недолговечный пул хранения может управляться только когда он запущен в определённом хосте. После того как тот выключен, все его отслеживания пропадут. Постоянный пул хранения имеет свои конфигурации сопровождаемыми в неком хранилище данных в том хосте, в котором расположен гипервизор в неком определяемом реализацией формате. Таким образом, когда какой- то постоянно существующий пул хранения не активен, всё ещё имеется возможность управлять его неактивной конфигурацией. Некий недолговечный пул может быть превращена в постоянный пул во время его работы путём задания его конфигурации.

Для получения дополнительных сведений относительно применения объектов пулов хранения обратитесь к Главе 5.

Тома хранения

Объект тома хранения позволяет вам выделять какой- то блок хранения в рамках некого пула, выступая каким- то разделом диска, логическим томом, LUN SCSI/ iSCSI или файлом внутри локальной/ сетевой файловой системы. Будучи выделенным, том может применяться для предоставления дисков одному (или более) виртуальным доменам. Какой- то том представляется неким экземпляром имеющегося класса virNetwork и имеет три уникальных идентификаторов.

Name: Представляет короткую строку, уникальную для всех томов хранения внутри какого- то пула хранения. Для обеспечения максимальной совместимости между гипервизорами такие названия могут содержать лишь алфавитноцифровые (a–Z, 0–9) символы, символ тире (-) и символ подчёркивания (_). Данное название не гарантирует своей стабильности между перезагрузками или между хостами, даже если его пул хранения разделяется между хостами.
Key: Это уникальная строка произвольных выводимых на печать символов, служащая для уникальной идентичности данного тома внутри его пула. Данный ключ предназначен для того чтобы быть уникальным между перезагрузками и хостами.
Path: Задаёт путь некой файловой системы к данному тому. Этот путь уникален по всем томам хранения внутри обособленного хоста. Когда имеющийся пул хранения настроен с подходящим целевым путём, такой путь тома может быть стабильным между перезагрузками и хостами.

Для получения дополнительных сведений относительно применения объектов томов хранения обратитесь к Главе 5.

Устройства хоста

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

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

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

Модель драйвера

Библиотека libvirt предоставляет гарантированные стабильные API и ABI, которые отвязаны от какой бы то ни было конкретной технологии виртуализации. Кроме того, многие из этих API имеют связанные схемы XML, которые рассматриваются как часть гарантии стабильности ABI. Во внутреннем представлении присутствует несколько реализаций публичного ABI, причём каждая из них предназначена некой отличной технологии виртуализации. Каждая реализация называется драйвером. При получении экземпляра имеющегося класса virConnect разработчик приложения может предоставить некий URI для определения того какой именно драйвер гипервизора активирован.

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

Когда некий драйвер libvirt не реализует некий определённый API, тогда он будет возвращать код ошибки VIR_ERR_NO_SUPPORT, который позволяет выявлять это. Также существует некий API позволяющий запрашивать определённые возможности некого гипервизора, например значение поддерживаемого типа ABI гостя. Рисунок 2-1 отображает все возможные модели драйвера, к которым можно ссылаться через имеющийся API.

Рисунок 2-1

Архитектура драйвера libvirt

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

Вот перечень драйверов гипервизора:

Xen: Гипервизор Xen с открытым исходным кодом предоставляет паравиртуализацию и полные виртуальные машины. Отделный системный драйвер запускается в основном хосте Dom0, общаясь напрямую с неким счетанием гипервизора, xenstored и xend. Вот какой- то образец локальной схемы URI: xen:///.
QEMU: Поддерживает все технологии виртуализации на основе QEMU с открытым исходным кодом, включая KVM. Отдельный привилегированный драйвер хапускается в самом хосте, управляя процессами QEMU. Все непривилегированные учётные записи пользователя также имеют некий частный экземпляр такого драйвера. Неким примером привилегированной схемы URI является qemu:///system. А примером непривилегированной схемы URI выступает qemu:///session.
UML: Это представитель ядра User Mode Linux (Linux режима пользователя), некой чистой технологии паравиртуализации. Обособленный привилегированный драйвер системы запускается в том хосте, который управляет процессами UML. Всякая непривилегированная учётная запись ползователя также имеет какой- то частный экземпляр такого драйвера. Неким примером привилегированной схемы URI является uml:///system. А примером непривилегированной схемы URI выступает uml:///session.
OpenVZ: Это технология виртуализации на основе контейнеров OpenVZ с применением изменённого ядра хоста Linux. Обособленный привилегированный драйвер системы запускается в своём хосте для общения с инструментами OpenVZ. Неким примером привилегированной схемы URI является openvz:///system.
LXC: Это естественная технология виртуализации контейнеров Linux, доступная в ядрах Linux начиная с 2.6.25. Обособленный привилегированный драйвер системы запускается в своём хосте для общения с самим ядром. Неким примером привилегированной схемы URI является lxc:///.
Remote: Данная обобщённая безопасная служба RPC общается с неким демоном libvirtd. Она предоставляет шифрование и аутентификацию с применением выбираемого из туннелирования TLS, сертификатов x509, SASL (GSSAPI/Kerberos), а также SSH. Значение URI следует за названием схемы самого желательного драйвера, но с заполненным именем хоста и некими данными названия транспорта, добавляемого к значению схемы URI. Вот некий образец для общения с Xen поверх канала TLS: xen+tls://somehostname/. А это пример для общения с QEMU поверх канала SASL: qemu+tcp:///somehost/system.
Test: Это некий ложный драйвер, предоставляющий виртуальный гипервизор в оперативной памяти, который покрывает все имеющиеся API libvirt. Он снабжает необходимые тесты и приложения, которые применяют libvirt, делая возможным автоматизированные проверки запуска API libvirt упражнений без необходимости иметь дело с реальным гипервизором. Неким образцом схемы URI по умолчанию выступает test:///default. А вто пример индивидуальной схемы URI: test:///path/to/driver/config.xml.

Удалённое управление

Хотя многие технологии виртуализации предоставляют возможность удалённого управления, libvirt не полагается на это и представляет выделенный драйвер, который делает возможным такое удаленное управление для любого драйвера гипервизора libvirt. Этот драйвер имеет разнообразные возможности передачи данных предоставляя существенную безопасность для необходимого обмена данными. Этот драйвер спроектирован таким образом чтобы обеспечить 100- процентную функциональную эквивалентность как при локальном общении с необходимым драйвером libvirt, так и через соответствующую службу RPC.

Помимо такой содержащейся в libvirt естественной службы RPC, имеется целый ряд альтернатив для удалённого управления, которые мы не будем обсуждать в этой книге. Имеющийся проект libvirt-qpid предоставляет агента для службы обмена сообщениями QPid, выставляя все упарвляемые libvirt объекты и операции поверх его шины обмена сообщениями. Это удерживает достаточно близким, практически один- в- один соответствие libvirt в API C. Проект libvirt-CIM предоставляет некого агента CIM, который устанавливает соответствие имеющейся модели объектов libvirt в схему виртуализации DMTF.

Основы применения

Сторона сервера нашей службы RPC предоставляется имеющимся демоном libvirtd, который должен быть запущен на самом подлежащем управлению хосте. В неком развёртывании по умолчанию этот демон будет ожидать подключения только от локальных сокетов домена Unix. Это позволяет клиенту libvirt применять лишь туннель SSH для обмена данными. С подходящими настройками сертификатов x509 или с полномочиями SASL, имеющийся демон libvirtd способен общаться с неким ожидающим сокетом TCP напрямую, без установления туннельного соединения с клиентом.

Как вы можете видеть из наших предыдущих примеров URI драйверов libvirt, значение поля имени хоста в самом URI для локальных подключений libvirt вегда остаётся пустым. Чтобы воспользоваться определённым драйвером RPC libvirt, для такого локального URI требуются лишь два изменения. Должно быть определено по крайней мере одно название хоста, и с этой точкой libvirt попытается применять непосредственный обмен данными TLS. Через добавление в конец к заданной схеме URI запроса некого альтернативного транспорта им моожно будет воспользоваться. Более подробно форматы URI будут рассмотрены в Главе 6.

Транспортировка данных

Для охвата широкого разнообразия сред развёртывания служба RPC libvirt поддерживает ряд видов обмена данными, причём все они могут быть настроены с возможностями шифрования и аутентификации стандартов отрасли.

Вот основные транспорты libvirt:

tls

Это TCP сокет, исполняющий протокол TLS в своей шине. Этот вид обмена данными установлен по умолчанию если ничто иное не запрошено в явном виде и он применяет соединение TCP по порту 16514. Как минимум, требуется настроить свой сервер с авторизацией по сертификату x509 и выпускаемым им сертификатом сервера. В качестве необязательного требования, сервер libvirtd может быть настроенным на требование наличия у клиентов сертификатов x509 в качестве средства аутентификации.
tcp

Это сокет TCP без протокола TLS в шине. Этот вид обмена данными не следует применять в сетевых средах без надлежащего уровня доверия, только если не была включёна служба аутентификации SASL и она не настроена с подключаемым модулем, обеспечивающим шифрование. Соединение TCP выполняется по порту 16509.
unix

Данный обмен данными служит лишь для локального обмена данными, что делает возможным для пользователей напрямую подключаться к демону libvirtd, запущенному в различных учётных записях пользователя. Поскольку он доступен исключительно для самой локальной машины, он не шифруется. Стандартными именами сокетов являются /var/run/libvirt/libvirt-sock для полных возможностей управления и /var/run/libvirt/libvirt-sock-ro для ограниченных только операциями чтения сокетов.
ssh

Все данные RPC туннелируются поверх некого подключения SSH к необходимой удалённой машине. Это требует установки на соответствующей удалённой машине Netcat (nc) и чтобы libvirtd был запущен с включённым сокетом домена Unix. Рекомендуется настраивать SSH на работу без запроса пароля для соответствующего приложения клиента. Например, если вы применяете аутентификацию с общедоступным ключом SSH, рекомендуется чтобы вы запускали некого агента ssh для кэширования ключа параметров доступа. GSSAPI является ещё одним полезным режимом аутентификации для обмена SSH, который делает возможным применение предварительно инициализируемого кэширования параметров доступа Kerberos.
ebxt

Поддерживает исключительно все внешние программы, которые имеют возможность выполнять подключение к необходимой удалённой машине посредством того что выходит за рамки libvirt. Если не один из встроенных механизмов обмена не удовлетворён, это делает возможным предоставлять некую вспомогательную программу, которая выступает посредником (proxy) данных RPC поверх некого индивидуального канала.

Схемы аутентификации

Для охвата широкого разнообразия сред развёртывания служба RPC libvirt поддерживает ряд схем аутентификации для своего обмена данными, причём все они могут быть настроены с возможностями шифрования и аутентификации стандартов отрасли. Выбранная схема аутентификации настраивается администратором в соответствующем файле /etc/libvirt/libvirtd.conf.

Вот основные схемы libvirt:

sasl

SASL выступает отраслевым стандартом для подключаемых механизмов аутентификации. Всякий подключаемый модуль имеет широкое разнообразие возможностей, а обсуждение их эксплуатационных возможностей выходит за рамки данного документа. Для обмена данными tls существует широкий выбор подключаемых модулей, так как TLS предоставляет шифрование данных для самого канала сетевой среды. Для транспорта данных tcp libvirt будет отклонять применение любого подключаемого модуля, который не поддерживает шифрование данных. Это на самом деле ограничивает данный выбор на GSSAPI/Kerberos. Если требуется строгая аутентификация локальных пользователей, при обмене данными в имеющихся сокетах UNIX может быть опционально включён SASL.
polkit

PolicyKit является некой схемой аутентификации, подходящей для развёртываний локальной виртуализации рабочих мест, причём с применением исключительно в обмене данных через сокеты домена Unix. Она позволяет демонам libvirtd удостовериваться в том, что данное приложение клиента запущено внутри имеющегося сеанса X рабочего места. Она может быть настроена с тем, чтобы допускать автоматическую регистрацию уже вошедшего пользователя или же может выдавать ему запрос на ввод его собственного пароля или значения пароля суперпользователя (root).
x509

Хотя строго говоря это не схема аутентификации, имеющийся обмен данными TLS может быть настроен на обязательное применение сертификатов x509 клиента. Сам сервер может иметь далее некий белый список выделенных имён клиентов для управляющего доступа.

Выработка сертификатов TLS

libvirt поддерживает сертификаты TLS для проверки идентичности применяемых сервера и клиентов. В этот процесс вовлечены две разные проверки.

Проверки того клиента, который подключён к правильному серверу на соответствие самого сертификата, который этот сервер отправляет совместно с именем хоста данного сервера. Данную проверку можно запретить путём добавления ?no_verify=1.
Проверки самого сервера для обеспечения того, что подключены лишь lопустимые клиенты. Она выполняется с применением одного из следующих:
1. Значения IP адреса клиента
2. Значения IP адреса клиента и наличия сертификата клиента

Проверка сервера может включаться или отключаться с применением изменения файла libvirtd.conf.

Для полной проверки сертификата вам потребуется иметь сертификаты, выпускаемые признанным Центром автоизации (CA, certificate authority) для вашего сервера (или серверов) и для всех клиентов. Чтобы избежать затрат на получение сертификатов от коммерческих CA, существует подход установки вашего собственного CA и уведомления всех своих серверов и клиентов о доверии сертификатам, выпускаемым вашим собственным CA. Для того чтобы осуществить это, проследуйте инструкциям из следующего раздела.

Следует обратить внимание на то, что использование сертификата с применением значения FQDN/ имени хоста когда такой хост не представлен в вашем DNS вызовет проблемы пока этот хост не будет добавлен в содержимое файла hosts. В качестве альтернативы, когды вы заменяете значение имени хоста значением его IP адреса, это также может вызывать проблемы.

Имейте в виду, что имеющаяся по умолчанию конфигурация libvirtd.conf допускает подключения любых клиентов, которые предоставляют информацию что у них в наличии допустимый сертификат, выпущенный CA для их собственного IP адреса. В зависимости от ваших требований вам может потребоваться сделать эти настройки более или менее допускающими.

Настройка инфраструктуры общедоступного ключа

Инфраструктура общедоступного ключа (PKI, public key infrastructure) предоставляет управление доступом для некого домена через обсуждаемый API (Таблица 2-1). За полным обсуждением этих возможностей обратитесь, пожалуйста, к https://libvirt.org/auth.html. По умолчанию, все пользователи, которым требуется доступ к клиентам домена обязаны иметь некий сертификат PKI, созданный для них их администратором. В противном случае такой пользователь не получит никакого доступа к запрашиваемому домену через обсуждаемый API.

Таблица 2-1. Настройка общедоступных ключей
Местоположение	Машина	Описание	Требующиеся поля
`/etc/pki/CA/cacert.pem`	Устанавливается на всех клиентах и серверах	Сертификат CA	не требуются
`/etc/pki/libvirt/private/serverkey.pem`	Устанавливается на все серверы	Частный ключ сервера	не требуются
`/etc/pki/libvirt/servercert.pem`	Устанавливается на все серверы	Сертификат сервера, подписанный доверенным CA	CommonName (CN) обязан быть значением имени хоста самого сервера, как он виден клиентом
`/etc/pki/libvirt/private/clientkey.pem`	Устанавливается в соответствующем клиенте	Частный ключ клиента	не требуются
`/etc/pki/CA/cacert.pem`	Устанавливается в соответствующем клиенте	>Сертификат клиента, подписанный доверенным CA	Distinguished Name (DN, имя получателя) может быть проверено через некий список управления доступом (`tls_allowed_dn_list`)

Выводы

Данная глава представила основные компоненты, которые составляют основу архитектуры libvirt. Большая часть информации данной главы будет в дальнейшем расширяться последующими главами. Идущие далее главы сделают введение в сам API Python и покажут подробности функций, которые способны взаимодействовать с этими компонентами.