libvirtd.conf#

libvirtd.conf - это конфигурационный файл демона libvirtd (подробнее см. в «Утилита libvirtd») по умолчанию, если он не переопределен. Содержит настройки и значения по умолчанию для виртуальных машин и методы переопределения их стандартных параметров. Строки, начинающиеся с #, являются комментариями и игнорируются.

Примеры записей#

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

Настройка прослушивания защищенных TLS-соединений на общедоступном TCP/IP-порте:
- для включения прослушивания сокетов с помощью демона libvirtd примените опцию --listen в командной строке демона;
- это не требуется при использовании virtproxyd (компонент серверного демона системы управления виртуализацией libvirt);
- этот параметр не требуется и не соблюдается при использовании активации сокета systemd;
- перед использованием этой возможности настройте центр сертификации и выдайте сертификаты сервера;
- включено по умолчанию, запись для отключения:
```
listen_tls = 0
```
Прослушивание незашифрованных TCP-соединений на общедоступном TCP/IP-порте:
- для включения прослушивания сокетов с помощью демона libvirtd примените опцию --listen в командной строке демона;
- это не требуется при использовании virtproxyd;
- этот параметр не требуется и не соблюдается при использовании активации сокета systemd;
- для использования сокета TCP по умолчанию требуется аутентификация SASL; разрешены только механизмы SASL, поддерживающие шифрование данных; это DIGEST_MD5 и GSSAPI (Kerberos5);
- по умолчанию эта функция отключена, запись для включения:
```
listen_tcp = 1
```
Переопределение порта для приема защищенных соединений по протоколу TLS:
- это может быть номер порта или название службы;
- этот параметр не требуется и не соблюдается при использовании активации сокета systemd;
- пример записи:
```
tls_port = "16514"
```
Переопределение порта для приема небезопасных TCP-соединений:
- это может быть номер порта или название службы;
- этот параметр не требуется и не соблюдается при использовании активации сокета systemd;
- пример записи:
```
tcp_port = "16509"
```
Переопределение конфигурации по умолчанию, привязанной ко всем сетевым интерфейсам:
- это может быть числовой адрес IPv4/6 или имя хоста;
- этот параметр не требуется и не соблюдается при использовании активации сокета systemd;
- если libvirtd запускается параллельно с запуском сети, то привязка к адресам, отличным от подстановочных знаков (0.0.0.0/::), может быть еще недоступна;
- пример записи:
```
listen_addr = "hh.hh.hh.hh"
```
  Где hh.hh.hh.hh – IP-адрес.

Средства управления доступом к сокетам UNIX#

Настройка групп-владельцев доменных сокетов UNIX - может быть использовано для предоставления доверенному набору пользователей доступа к возможностям управления без получения статуса root:
- этот параметр не требуется и не соблюдается при использовании активации сокета systemd;
- по умолчанию параметр ограничен значением root;
- пример записи:
```
unix_sock_group = "libvirt"
```
Установка разрешений сокета UNIX для сокета «read-only» - используется для мониторинга состояния виртуальной машины:
- этот параметр не требуется и не соблюдается при использовании активации сокета systemd;
- по умолчанию разрешен для любого пользователя; если настраиваются группы-владельцы, то может быть ограничен;
- пример записи:
```
unix_sock_ro_perms = "0777"
```
Установка разрешений сокета UNIX для сокета «read-write» - используется для полного управления виртуальными машинами:
- этот параметр не требуется и не соблюдается при использовании активации сокета systemd;
- по умолчанию разрешен только root; если в сокете включен PolicyKit (средство, позволяющее непривилегированным пользователям выполнять операции, доступные администратору), то значение по умолчанию изменится на «разрешить всем» (например, 0777);
- если PolicyKit не используется и группы-владельцы не установлены для контроля доступа, возможно ослабление этого ограничения;
- пример записи:
```
unix_sock_rw_perms = "0770"
```
Установка разрешений сокета UNIX для сокета интерфейса администратора:
- этот параметр не требуется и не соблюдается при использовании активации сокета systemd;
- по умолчанию он разрешен только владельцу (root), не меняйте его, если не уверены в том, кому предоставляете доступ;
- пример записи:
```
unix_sock_admin_perms = "0700"
```
Указание директории для поиска/создания сокетов:
- этот параметр не требуется и не соблюдается при использовании активации сокета systemd;
- пример записи:
```
unix_sock_dir = "/run/libvirt"
```

Аутентификация#

Доступны следующие варианты:

none - не выполнять проверку подлинности - может использоваться, если существуют ограничения на подключение к сокету (например, разрешения на использование сокета UNIX) или если в сети есть более низкий уровень аутентификации (например, сертификаты TLS/x509);
sasl - использовать инфраструктуру SASL; в этом случае актуальная схема аутентификации регулируется в файле /etc/sasl2/libvirt.conf; для сокета TCP будут использоваться только механизмы GSSAPI и DIGEST-MD5; для сокетов, отличных от TCP или TLS, разрешена любая схема;
polkit - использовать PolicyKit для аутентификации; подходит только для использования в сокетах UNIX; по умолчанию доступ разрешен только для чтения («read-only»), для получения полного доступа на чтение и запись («read-write») необходимо введение пароля.
Установка схемы аутентификации для сокетов UNIX «read-only»:
- по умолчанию разрешения сокетов позволяют подключаться любому пользователю;
- если libvirt был скомпилирован без поддержки polkit, то проверки контроля доступа не выполняются, но libvirt по-прежнему разрешает выполнение только API, не изменяющих состояние;
- если libvirt был скомпилирован с поддержкой polkit, то сокет libvirt выполнит проверку с помощью polkit после подключения; по умолчанию по-прежнему разрешен доступ любому локальному пользователю;
- для ограничения мониторинга доменов можете либо включить sasl, либо изменить определение политики polkit;
- пример записи:
```
auth_unix_ro = "polkit"
```
Установка схемы аутентификации для сокетов UNIX «read-write»:
- если libvirt был скомпилирован без поддержки polkit, то файлы сокета systemd по умолчанию будут использовать SocketMode=0600, что позволит подключаться только пользователю root, а auth_unix_rw по умолчанию будет иметь значение none;
- если libvirt был скомпилирован с поддержкой polkit, то файлы сокета systemd будут использовать SocketMode=0666, что позволяет любому пользователю подключаться, а auth_unix_rw по умолчанию будет иметь значение polkit; если использование polkit здесь отключено, то необходимо изменить параметр systemd Socket Mode обратно на 0600, чтобы избежать небезопасной конфигурации;
- пример записи:
```
auth_unix_rw = "polkit"
```
Изменение схемы аутентификации для сокетов TCP:
- если SASL не включен, то весь трафик TCP будет отображаться в виде открытого текста;
- не используйте данный параметр вне сценария разработки/тестирования; для использования в реальных условиях всегда включайте SASL и используйте механизм GSSAPI или DIGEST-MD5 в /etc/sasl2/libvirt.conf;
- пример записи:
```
auth_tcp = "sasl"
```
Изменение схемы аутентификации для сокетов TLS:
- сокеты TLS уже имеют шифрование, обеспечиваемое уровнем TLS, а ограниченная аутентификация выполняется с помощью сертификатов;
- также можно использовать любой механизм аутентификации SASL, используя для этого параметр sasl;
- пример записи:
```
auth_tls = "none"
```
Установка минимального значения SSF для TCP-сокетов:
- на данный момент минимальное значение по умолчанию равно 56 (single-DES), в будущем будет увеличено до 112;
- данный параметр можно использовать для установки значений выше 112;
- пример записи:
```
tcp_min_ssf = 112
```
Изменение схемы управления доступом к API:
- по умолчанию аутентифицированному пользователю разрешен доступ ко всем API; при помощи драйверов доступа можно устанавливать ограничения; по умолчанию драйвер nop включен, что означает, что после аутентификации клиента с помощью libvirtd проверки контроля доступа не выполняются;
- пример записи:
```
access_drivers = [ "polkit" ]
```

Конфигурация сертификата TLS x509#

Для использования TLS требуется выдача сертификатов x509. Расположение файлов сертификатов по умолчанию:

/etc/pki/CA/cacert.pem - мастер сертификат CA (центра сертификации);
/etc/pki/libvirt/servercert.pem - сертификат сервера, подписанный cacert.pem;
/etc/pki/libvirt/private/serverkey.pem - закрытый ключ сервера.

Для переопределения местоположения по умолчанию задайте соответствующие значения key_file, cert_file и ca_file.

Пример переопределения пути к файлу ключа сервера по умолчанию:
```
key_file = "/etc/pki/libvirt/private/serverkey.pem"
```
Пример переопределения пути к файлу сертификата сервера по умолчанию:
```
cert_file = "/etc/pki/libvirt/servercert.pem"
```
Пример переопределения пути к сертификату CA по умолчанию:
```
ca_file = "/etc/pki/CA/cacert.pem"
```
Пример указания списка отзываемых сертификатов - по умолчанию CURL не используется:
```
crl_file = "/etc/pki/CA/crl.pem"
```

Управление авторизацией#

Настройка отключения проверки сертификатов собственного сервера:
- при запуске libvirtd выполняет проверки работоспособности собственных сертификатов;
- по умолчанию всегда выполняется проверка работоспособности;
- пример записи, отключающей проверку работоспособности (не рекомендуется к использованию):
```
tls_no_sanity_certificate = 1
```
Настройка отключения проверки клиентских сертификатов:
- проверка клиентских сертификатов является основным механизмом аутентификации;
- клиент, не предоставивший сертификат, подписанный CA, будет отклонен;
- по умолчанию проверка выполняется всегда;
- пример записи, отключающей проверку:
```
tls_no_verify_certificate = 1
```
Список разрешенных для управления доступом отличительных имен (DN) x509:
- может содержать подстановочные знаки;
- формат DN для конкретного сертификата можно запросить с помощью:
```
virt-pki-query-dn clientcert.pem
```
- если список пуст, то ни один клиент не сможет подключиться - не используйте пустой список для отключения проверок;
- по умолчанию DN не проверяются;
- пример записи:
```
tls_allowed_dn_list = ["DN1", "DN2"]
```
Переопределение строки приоритета TLS по умолчанию во время компиляции:
- значение по умолчанию NORMAL, если не переопределено во время сборки;
- данный параметр устанавливается только в случае, если требуется, чтобы libvirt отклонялся от глобальных настроек по умолчанию;
- пример записи:
```
tls_priority="NORMAL"
```
Список разрешенных пользователей SASL для контроля доступа:
- формат имени пользователя зависит от механизма аутентификации SASL; имя пользователя в Kerberos выглядит как username@REALM;
- список может содержать подстановочные знаки, такие как *@EXAMPLE.COM;
- если список пуст, то ни один клиент не сможет подключиться - не используйте пустой список для отключения проверок;
- по умолчанию имена пользователей не проверяются;
- пример записи:
```
sasl_allowed_username_list = ["name1@EXAMPLE.COM", "name2@EXAMPLE.COM" ]
```

Управление обработкой данных#

Максимальное количество одновременных клиентских подключений, разрешенное для всех сокетов вместе взятых; пример записи:
```
max_clients = 5000
```
Максимальная длина очереди подключений, ожидающих приема демоном; некоторые протоколы, поддерживающие повторную передачу, могут выполнять это требование, чтобы последующая попытка подключения была успешной; пример записи:
```
max_queued_clients = 1000
```
Максимальная длина очереди из принятых, но не прошедших проверку подлинности клиентов; значение по умолчанию - 20; для отключения данной функции установите значение 0; пример записи:
```
max_anonymous_clients = 20
```
Минимальный лимит устанавливает количество воркеров (рабочих модулей), которые должны быть запущены изначально:
- если количество активных клиентов превышает данное значение, то запускается больше потоков, вплоть до лимита max_workers;
- обычно значение max_workers равно максимально допустимому количеству клиентов;
- пример записей:
```
min_workers = 5
max_workers = 20
```
Количество приоритетных воркеров; если все воркеры из вышеприведенного пула «stuck», некоторые вызовы, помеченные как высокоприоритетные (в частности, domainDestroy), могут быть выполнены в этом пуле; пример записи:
```
prio_workers = 5
```
Лимит одновременных запросов от одного клиентского соединения:
- чтобы избежать монополизации сервера одним клиентом, данный параметр должен составлять небольшую часть параметра max_workers;
- слишком низкое значение может привести к тайм-аутам в режиме ожидания;
- пример записи:
```
max_client_requests = 5
```
Параметры, аналогичные вышеуказанным, для интерфейса администратора; пример записей:
```
admin_min_workers = 1
admin_max_workers = 5
admin_max_clients = 5
admin_max_queued_clients = 5
admin_max_client_requests = 5
```

Управление ведением журнала#

Уровни ведения журнала:
- 4 - ошибки;
- 3 - предупреждения;
- 2 - информация;
- 1 - отладка (регистрируется все допустимые события).
Пример записи:
```
log_level = 3
```
Внимание

Использование данного параметра не рекомендуется, поскольку он выводит слишком много информации, которую практически невозможно прочитать. Используйте параметр log_filters.
Фильтры ведения журнала:
- фильтр позволяет выбрать другой уровень ведения для выбранной категории журналов; формат фильтра:
```
level:match
```
  Где:
  - match - строка, соответствующая категории, указанной в VIR_LOG_INIT() в верхней части каждого исходного файла libvirt, например, remote, qemu или util.json;
  - level - минимальный уровень, на котором должны регистрироваться совпадающие сообщения
- один фильтр может включать несколько фильтров, разделенных пробелами;
- libvirt выполняет «первое» сопоставление, т.е. при наличии параллельных фильтров будет применен первый из них по порядку;
- обычно требуется получить информацию из драйвера гипервизора, точек входа в общедоступный API и некоторого служебного кода; Некоторые служебные коды являются нежелательными; пример записи для гипервизора QEMU - в строке фильтра для отладки может быть отключение объектов, json и ведения журнала событий, но включение остального кода util:
```
log_filters="1:qemu 1:libvirt 4:object 4:json 4:event 1:util"
```
Выходные данные ведения журнала это одно из мест для сохранения информации журнала:
- формат:
  - level:stderr - выходные данные преобразуются в stderr;
  - level:syslog:name - системный журнал используется для вывода, в качестве идентификатора - заданное имя;
  - level:file:file_path - вывод в файл с заданным путем;
  - level:journald - вывод в систему ведения журнала.
- во всех случаях level имеет минимальный приоритет и действует как фильтр;
- могут быть заданы несколько выходных данных, разделенных пробелами;
- пример записи всех предупреждений и ошибок в системный журнал под идентификатором libvirtd:
```
log_outputs="3:syslog:libvirtd"
```

Аудит#

Данный параметр позволяет изменить использование подсистемы аудита, значения:
- 0 - отключить весь аудит;
- 1 - включить аудит, если он включен на хосте (по умолчанию);
- 2 - включить аудит и выйти, если он отключен на хосте.
Пример записи:
```
audit_level = 2
```
Если данный параметр равен 1, то сообщения аудита также будут отправляться через инфраструктуру ведения журнала libvirt; по умолчанию 0; пример записи:
```
audit_logging = 1
```

UUID хоста#

UUID хоста считывается из одного из источников, указанных в параметре host_uuid_source.
Источники:
- smbios - извлечение UUID из dmidecode -s system-uuid;
- machine-id - извлечение UUID из /etc/machine-id.
Значение host_uuid_source по умолчанию - smbios; если dmidecode не предоставляет допустимый UUID, то будет сгенерирован временный UUID.
Другой вариант - указать UUID хоста в host_uuid.
Пример записей с UUID, в котором 0 - условное обозначение - замените его на вывод команды uuidgen:
```
host_uuid = "00000000-0000-0000-0000-000000000000"
host_uuid_source = "smbios"
```

Протокол поддержания работоспособности#

Позволяет libvirtd обнаружить нарушенные клиентские соединения или даже «мертвые» клиенты. Сообщение keepalive отправляется клиенту после нескольких секунд бездействия keepalive_interval, чтобы проверить, продолжает ли клиент отвечать; keepalive_count - это максимальное количество сообщений keepalive, которые разрешено отправлять клиенту без получения ответа, прежде чем соединение будет считаться разорванным.

Таким образом, соединение автоматически закрывается примерно через keepalive_interval * (keepalive_count + 1) секунд с момента получения последнего сообщения от клиента. Если значение keepalive_interval равно -1, то libvirtd не будет отправлять запросы keepalive; однако клиенты все равно могут их отправлять, и демон будет отправлять ответы.

Если значение keepalive_count равно 0, то соединения будут автоматически закрываться после нескольких секунд бездействия keepalive_interval без отправки каких-либо сообщений keepalive.

Пример записей:

keepalive_interval = 5
keepalive_count = 5

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

admin_keepalive_interval = 5
admin_keepalive_count = 5

Открытие vSwitch#

Позволяет указать время ожидания для вызовов openvswitch, выполняемых libvirt. Для настройки используется ovs-vsctl, ее параметр времени ожидания по умолчанию установлен на 5 секунд, чтобы избежать возможного бесконечного ожидания, блокирующего libvirt. Пример записи:

admin_keepalive_interval = 5
admin_keepalive_count = 5