1. Виртуализация VirtualBox

а) Установка

Ставить VirtualBox можно либо из стандартного репозитория rpmfusion-free-updates, либо с репозитория Oracle. Последний вариант предпочтительней, т.к. в rpmfusion-free-updates пакет бывает нерабочим.
Для подключения репозитория Oracle надо каталоге /etc/yum.repos.d создать файл virtualbox.repo со следующим содержимым:


[virtualbox] name=Fedora $releasever - $basearch - VirtualBox baseurl=http://download.virtualbox.org/virtualbox/rpm/fedora/$releasever/$basearch enabled=1 gpgcheck=1 gpgkey=http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc

Установка VirtulaBox:


# Из rpmfusion-free-updates $ yum install VirtualBox # Из репозитория Oracle (текущая версия 4.3) $ yum install VirtualBox-4.3

Для того, чтобы можно было работать в гостевых системах с USB необходимо установить стандартное (базовое) расширение (и пока единственное): скачиваем Oracle VM VirtualBox Extension Pack, соответствующий нашей версии и устанавливаем его через консоль управления. Например, для текущей версии 4.3.16:


$ VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.3.16-95972.vbox-extpack

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


$ gpasswd -a <имя_пользователя> vboxusers

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



б) Сжатие и конвертирование виртуальных дисков (VDI)

Перед сжатием желательно освободить побольше места на виртуальном диске гостевой системы и заполнить свободноме место нулями: если гостевая ОС - Linux, то для этого существует программа zerofree (у неё ограничение ext2/ext3 по манам: на ext4 не проверял); если гостевая ОС - FreeBSD, то можно воспользоваться программой zeroer.
В принципе лучшим, наверное, вариантом, будет


$ dd if=/dev/zero of=/tmp/ZEROZERO bs=512 # хотя и такой не исключён $ cat /dev/zero > /tmp/ZEROZERO

По окончании "зануления" (отвалится с ошибкой, т.е. всё свободное место "забито" нулями - удалить файл /tmp/ZEROZERO. Возможен "казус", если работает дедубликация блоков данных на файловой системе или уплотнение пустых блоков.
После "зануления" всего свободного пространства на диске гостевую систему выключают (желательно ещё создать "снимок") и сжимают VDI-файл возможностями VirtualBox:


$ VBoxManage modifyvdi FreeBSD-9_0-amd64-disk1.vdi compact

В моём случае из более ем 13 Гб осталось чуть более 8 Гб, что не может не радовать. А если ВМ экспортировать в OVA формате и потом восстановить - ещё очень сильно ужмётся. :)
Иногда (например, при импорте конфигурации из образа в OVA-формате) виртуальный "жёсткий диск" будет в формате VMDK и такой образ утилита VBoxManage откажется сжимать. Поэтому предварительно (ну или вообще, при любой необходимости) VMDK надо сконвертировать в VDI. Для этого так же надо воспользоваться утилитой VBoxManage:


$ VBoxManage clonehd файл_исходный.vmdk файл_назначения.vdi --format VDI

Общий вид команды (если понадобится конвертировать другие форматы):


VBoxManage clonehd <uuid>|<filename> <uuid>|<outputfile> [--format VDI|VMDK|VHD|RAW|<other>] [--variant Standard,Fixed,Split2G,Stream,ESX] [--existing]

Для целей конвертации можно воспользоваться и qemu:


$ qemu-img convert -f vdi -O vmdk VirtualBoxImage.vdi VmWareImage.wmdk

Общий вид команды (если понадобится конвертировать другие форматы):


qemu-img convert [-c] [-f fmt] [-O output_fmt] [-o options] filename [filename2 [...]] output_filename

Так же, при необходимости можно воспользоваться VMWare vCenter Converter. В добавок к возможности преобразования виртуальных машин из одного формата в другой, Converter от VmWare может клонировать систему реальной физической машины в виртуальный образ.
P.S. Для KVM: драйвера для гостевой Венды находятся здесь.



в) Управление VirtualBox с консоли

Команды для управления виртуальной машины Virtualbox с помощью утилиты vboxmanage (или VBoxManage - это два симлинка на VBox, но напрямую вызов VBox не работает).
Создание виртуальных машины и диска к ней:


# вирт.машина с именем winxp $ VBoxManage createvm --name winxp --register # переход в каталог вирт.машины (у меня в /Virtual_System) # и создание диска типа VDI с именем winxp_10G, объемом в 10 Гб $ cd /Virtual_System/winxp/ $ VBoxManage createhd --format VDI --size 10240 --filename winxp_10G # указание типа гостевой ОС, выделение 512 Мб основной и 12 МБ видеопамяти $ VBoxManage modifyvm winxp --ostype WindowsXP --memory 512 --vram 12 # включение поддержки USB в целом и 2.0 (EHCI), выбор чипсета $ VBoxManage modifyvm winxp --usb on --usbehci on --chipset piix3 # указание порядка и типа загрузочных устройств $ VBoxManage modifyvm winxp --boot1 dvd --boot2 disk --boot3 none --boot4 none # создание контроллера в/в: имя, тип, модель, кеширование $ VBoxManage storagectl winxp --name IDE --add ide --controller PIIX4 --hostiocache on # подключение ранее созданного вирт.диска $ VBoxManage storageattach winxp --storagectl IDE --port 0 --device 0 --type hdd --medium winxp_10G.vdi # подключение установочного образа ISO с Windows XP $ VBoxManage storageattach winxp --storagectl IDE --port 0 --device 1 --type dvddrive --medium /mnt/virtualbox/WinXP_Boot.iso # настройка типа сети: сетевой мост $ VBoxManage modifyvm winxp --nic1 hostif # или NAT $ VBoxManage modifyvm winxp --nic1 nat # включение режима VRDP, чтобы при отсутствии графического интерфейса # иметь возможность подключиться и установить систему $ VBoxManage modifyvm winxp --vrde on

Основные настройки сделаны. Все остальные (звук и пр.) можно так же произвести через VBoxManage.
Просмотр детальной информации об определенной виртуальной машине:


$ VBoxManage showvminfo "winxp"

Список из всех существующих виртуальных машин (имена и UUID):


$ VBoxManage list vms "RusFedora 19" {99ac9ab8-ccfa-4201-8d3b-c3e87ae87483} "winxp" {b05123bc-2e5b-44f3-b14c-a6dc2c7ae9e3}

Запуск виртуальных машин:


$ VBoxManage startvm winxp --type=headless $ VBoxManage startvm "RusFedora 22"

Ключ --type=headless необходим, если управляем ВМ в консоли удалённо: гостевая ОС будет запущена, без отображения графического интерфейса.
Останов (через ACPI и "жёстко") работы виртуальной машины:


$ VBoxManage controlvm "winxp" acpipowerbutton | poweroff

Останов с сохранение состояния:


$ VBoxManage controlvm "RusFedora 19" savestate

Весь список команд доступен через vboxmanage без опций.
Дополнительная информация: ссылка 1, ссылка 2.



1 - проброс устройств узла

В общем случае это проброс PCI-устройства по номеру на шине:


# подключение устройства 02:00.0 к ВМ $ VBoxManage modifyvm "VM name" --pciattach 02:00.0@01:05.0 # отключение устройств от ВМ $ VBoxManage modifyvm "VM name" --pcidetach 02:00.0

Так же бывает необходимо пробросить жёсткий диск узла или его раздел "как есть":


# старый вариант $ VBoxManage internalcommands createrawvmdk -filename sdf.vmdk -rawdisk /dev/sdf # новый вариант $ VBoxManage createmedium disk --filename sdf.vmdk --format VMDK --variant RawDisk --property RawDrive=/dev/sdf

Вместо указания диска можно указать только необходимый раздел /dev/sdf2.
Но для того, чтобы присоединять диски и разделы, пользователь, из под которого запущен VirtualBox, должен иметь на это права. Есть два варианта:
1) запускать VirtualBox из-под root-а;
2) добавить пользователя в группу disk:


$ usermod UserName -aG disk # или, соответственно $ usermod UserName --append --groups disk

В Fedora "фокус" с группой disk работает, но в других дистрибутивах такого может не быть.



г) Включение локальной консоли ВМ с консоли

Узнаем список виртуальных машин:


$ VBoxManage list vms "VM name" {e63c0a4f-32bb-45a6-827f-d089966255a4}

Выключаем необходимую нам ВМ любым способом и запускаем в headless режиме:


$ VBoxHeadless -s "VM name" -v on -p 3390

При этом, порт консоли будет 3390.


Проверяем, что машина запустилась: $ VBoxManage list runningvms "VM name" {e63c0a4f-32bb-45a6-827f-d089966255a4}

И теперь подключаемся к ней:


$ rdesktop -g 1024x768 -a 16 -5 XX.XX.XX.XX:3390

где XX.XX.XX.XX адрес сервера, где запущен VirtualBox.
После завершения работ, запустите виртуальную машину в нормальном режиме.



д) Возможные проблемы и решения

ПРОБЛЕМА 1 - 3D для Gnome 3 (shell)
Описание: после установки Fedora в виртуальную машину в VirtualBox при загрузке Gnome-shell отказывается работать как надо и работает в fallback-режиме. Даже после настройки виртуальной машины, включения 3D, установки видео-памяти в 128 Мб, установки гостевого софта от vbox, glxgears и glxinfo показывают наличие 3D, но Gnome-shell отказывается этот 3D признавать.
Решение: проблема из-за SELinux. Для решения запускаем от root’а в этой гостевой машине:


$ restorecon -R -v /opt

После перезагрузки всё будет работать. Оригинал взят у elemc.
ПРОБЛЕМА 2 - запуск после смены ядра Linux
После смены ядра (чаще всего при обновлении системы) необходимо под данное ядро собрать модуль VirtualBox-а.
В версии 5.1 и новее пересборка производится командой:


$ /sbin/vboxconfig

В версиях с 5.0 до 5.1 такие команды:


$ /usr/lib/virtualbox/vboxdrv.sh setup # или $ /sbin/rcvboxdrv setup

Но в версии 5.0.10 данная команда не работала.
До 5-й версии модуль ядра перекомпилировался скриптом vboxdrv:


$ /etc/rc.d/init.d/vboxdrv setup

Т.е. иногда варианты пересборки меняются и, возможно, в будущих версиях будет снова что-то изменено.



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

а) Установка

Что-то не захотел ставиться Parallel Desktop 4 на свеже установленную Russian Fedora Remix 13 x86_64.
Поэтому решил разобраться с имеющимися средствами виртуализации в Федоре (поддерживаемые ОС и уровни этой самой поддержки).
Для начала необходимо их установить:


$ yum groupinstall Виртуализация

Установили сразу всё, входящее в группу "Виртуализация". А "всё" - это KVM (QEMU) со всеми сопутствующими библиотеками и утилитами.
Но в Fedora 20 русского именования группы уже нет. Да и лучше ставить только то, что реально необходимо. Поэтому можно воспользоваться таким списком установочных пакетов:


$ yum install virt-manager virt-viewer libvirt libvirt-python python-virtinst qemu-system-x86 libvirt-daemon-kvm spice-gtk-tools

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


$ modprobe kvm kvm_intel $ modprobe kvm kvm_amd

для систем на процессоре Intel и AMD соответственно. Это связано с разными технологиями виртуализации на процессорах этих фирм (для проверки это существуют свои флаги: 'vmx' - Intel, 'svm' - AMD).
После этого можно проверить, подгрузились ли они:


$ lsmod | grep kvm

Должны отобразиться два модуля, запущенные чуть ранее.
Если у нас каталог с ВМ будет размещён не в /var/lib/libvirt/images (или он будет дополнительным к основному), то для него надо установить правильный контекст SELinux:


# создаём нужный контекст $ semanage fcontext -a -t virt_image_t /mnt/KVM $ restorecon -Rv /mnt/KVM # назначаем его каталогом образов "по умолчанию" (при необходимости) $ virsh pool-define-as guest_images_dir dir - - - - "/mnt/KVM"

Дополнительная информация по виртаулизации доступна на сайте Fedora Project. И немного полезного о настройке.



б) Отмена запроса пароля и работа от пользователя

Для того, чтобы KVM (например, при запуске virt-manager) при запуске не требовал пароль:


$ groupadd libvirt $ usermod -a -G libvirt <username>

Возможно понадобится создать файл /etc/polkit-1/localauthority/50-local.d/50-org.libvirt-group-access.pkla следующего содержания:


[libvirt group Management Access] Identity=unix-group:libvirt Action=org.libvirt.unix.manage ResultAny=yes ResultInactive=yes ResultActive=yes

После чего надо данному файлу выставить права, идентичные правам соседних файлов.
Чтобы ВМ работали у нас от непривилегированного пользователя, в файле /etc/libvirt/qemu.conf скорректируем следующие параметры:


user = "username" group = "libvirt"

Поскольку у нас будут использоваться tun-устройства, нужно выставить capability CAP_NET_ADMIN, сделать это можно как для отдельного исполняемого файла, так и для пользователя в целом, или настроить чтобы libvirt не сбрасывал нужные права для qemu/kvm.
Выставляем для отдельного файла:


$ setcap cap_net_admin=ei /usr/bin/kvm

Или выставляем для пользователя в целом в файле /etc/security/capability.conf:


cap_net_admin username

Или выставляем соответствующую настройку в /etc/libvirt/qemu.conf:


clear_emulator_capabilities = 0

Добавим пользователя в группу kvm (в libvirt мы его уже добавили):


$ usermod -a -G kvm <username>

MacVTap



в) Настройка сети: мост (bridge) и объединение (bond)

Базовое необходимое действие по настройке сети для доступа гостевых систем к сети - настройка моста (bridge). При установке пакетов KVM в системе создался мост virbr0, но он предназначен для "внутренней сети" для гостевых систем. Нам же нужен мост, который будет обеспечивать доступ к внешней (относительно хоста) сети. Учитывая, что для серверных применений важно обеспечить резервирование сетевого подключения, объединим (bind) имеющиеся в сервере (у меня так) два интерфейса в один: bind0.
Настройку можно производить и Network Manager-ом, устанавливаемым в Fedora "по умолчанию", но воспользуемся "старым и добрым" network.service.
Поэтому сначала остановим и отключим (удалим, если надо) Network Manager:


$ systemctl stop NetworkManager.service $ systemctl disable NetworkManager.service

Так же я для собственного удобства отключаю переименование сетевых интерфейсов udev-ом. Получаем "старые" имена сетевых интерфейсов: ethX.
Теперь скорректируем файл конфигурации физического интерфейса и создадим для "моста". Содержание файлов интерфейсов:
1) физического eth0 (файл /etc/sysconfig/network-scripts/ifcfg-eth0):


TYPE="Ethernet" DEVICE="eth0" NAME="eth0" BOOTPROTO="none" ONBOOT="yes" USERCTL="no" IPV6INIT="no" IPV4_FAILURE_FATAL="no" NM_CONTROLLED="no"

2) физического eth1 (файл /etc/sysconfig/network-scripts/ifcfg-eth1):


TYPE="Ethernet" DEVICE="eth1" NAME="eth1" BOOTPROTO="none" ONBOOT="yes" USERCTL="no" IPV6INIT="no" IPV4_FAILURE_FATAL="no" NM_CONTROLLED="no"

3) "объединения" bond0 (файл /etc/sysconfig/network-scripts/ifcfg-bond0):


DEVICE="bond0" # BONDING_OPTS="mode=1 miimon=1000" BONDING_OPTS="mode=active-backup primary=eth0 miimon=100 updelay=0 downdelay=0" ONBOOT="yes" BRIDGE="bridge0" IPV6INIT="no" IPV4_FAILURE_FATAL="no" NM_CONTROLLED="no"

Данная конфигурация "объединения" назнает интерфейс eth0 активным, а eth1 будет работать в режиме "горячей замены".
4) "моста" bridge0 (файл /etc/sysconfig/network-scripts/ifcfg-bridge0):


TYPE="Bridge" DEVICE="bridge0" NAME="bridge0" ONBOOT="yes" DELAY="0" BOOTPROTO="none" IPADDR="192.168.1.28" NETMASK="255.255.240.0" # PREFIX=24 GATEWAY="192.168.1.1" DNS1="192.168.1.1" DOMAIN="mydomain.local" IPV4_FAILURE_FATAL="no" IPV6INIT="no" NM_CONTROLLED="no"

И последнее: для нормальной работы сети надо ещё указать шлюз "по умолчанию". В ifcfg-bridge0 мы прописали GATEWAY, но в случае проблем (возможно этот параметр используется только Metwork Manager - не выяснял) можно указать вручную:


$ route add default gw 192.168.1.1 dev bridge0

Тоже самое с DNS: при необходимости можно (или даже сразу нужно это сделать) вписать адреса серверов в /etc/resolv.conf.
По неясным для меня причинам после данных действий не заработала сеть. Пришлось воспользоваться утилитой brctl, чтобы это понять:


$ brctl show bridge name bridge id STP enabled interfaces bridge0 8000.000000000000 no virbr0 8000.525400c22026 yes virbr0-nic

Т.е. оказалось, что физ.интерфейс bond0 не в составе моста, хотя в его файле конфигурации прописано BRIDGE="bridge0".
Добавим в мост наш интерфейс:


$ brctl addif bridge0 bond0

Запускаем сетевой сервис:


$ systemctl enable network.service $ systemctl start network.service

Если всё в порядке - сервис сразу запустится. Иногда возникают проблемы из-за того, что параметры интерфейсов в файлах /etc/sysconfig/network-scripts/ifcfg-* были NetworkManager-ом списаны некорректно (для network.service).


Failed to start LSB: Bring up/down networking

Проверяем "пингом" работу интерфейса.
Состояние "бондинга" проверяется через /proc:


$ cat /proc/net/bonding/bond0

Настройка bonding в Linux
Linux Bonding
libvirt: Network interfaces
libvirt: Network management architecture
Setting guest network
Networking
Bridge
Network Bridge
Виртуализация с KVM на Fedora 17 Server
Настройка KVM в CentOS 6
Работа с виртуальными машинами KVM. Клонирование виртуальных машин



г) Создание виртуальной машины

Виртуальные машины (ВМ) в терминах KVM называются доменами. Поэтому в дальнейшем этот термин будет использоваться именно в таком значении.



д) Проброс устройств в гостевую систему

№1 - "Классический" проброс
При необходимости пробросить физическое устройство в гостевую систему (мне понадобилось пробросить Fibre Channel карту в гостевую с FreeNAS) необходимо воспользоваться технологией IOMMU (Input/Output Memory Management Unit). Оно же AMD-Vi в случае AMD и VT-d в случае Intel.
К сожалению стоит признать: хотя IOMMU внедряется в 2009 года (а в Sun SPARC и DEC Alpha она была "со староглиняных времён"), но на многих десктопных системных платах эта технология либо не работает, либо работает некорректно. :(
Но мы отталкиваемся от того, что у нас всё таки всё нормально и материнка и процессор поддерживают IOMMU.
Для начала необходимо включить поддержку IOMMU в BIOS/UEFI платы.
Затем (или перед тем) дополним в загрузчике параметры ядра следующими новыми:
1) включение поддердки IOMMU:


# для систем на базе AMD iommu=pt iommu=1 amd_iommu=fullflush # для систем на базе Intel intel_iommu=on

Я воспользовался вторым вариантом.
2) переключение устройства с собственного драйвера на драйвер-заглушку pci-stub:


pci-stub.ids=1077:2312

Числа в данном параметре берутся из вывода команды


$ lspci -nn | grep QLogic 07:05.0 Fibre Channel [0c04]: QLogic Corp. ISP2312-based 2Gb Fibre Channel to PCI-X HBA [1077:2312] (rev 02)

В каталоге /etc/modprobe.d создаём файл kvm_iommu_map_guest.conf следующего содержания:


$ cat kvm_iommu_map_guest.conf options kvm allow_unsafe_assigned_interrupts=1

и перегружаем систему.
После загрузки проверяем, а доступен ли IOMMU для Linux (здесь и далее убираю метки времени в начале строк из dmesg):


# для систем на бвзе процессоров AMD $ dmesg | grep -iE "(IOMMU|AMD-Vi)" AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40 AMD-Vi: Interrupt remapping enabled AMD-Vi: Initialized for Passthrough Mode # для систем на бвзе процессоров Intel $ dmesg | grep -iE "(IOMMU|VT-d|DMAR)" | grep -v vmlinuz ACPI: DMAR 0x00000000DD22B8A0 000080 (v01 INTEL SNB 00000001 INTL 00000001) Intel-IOMMU: enabled dmar: Host address width 36 dmar: DRHD base: 0x000000fed90000 flags: 0x1 dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c9008020660262 ecap f0105a dmar: RMRR base: 0x000000dda21000 end: 0x000000dda3dfff IOAPIC id 2 under DRHD base 0xfed90000 IOMMU 0 DMAR: No ATSR found IOMMU 0 0xfed90000: using Queued invalidation IOMMU: Setting RMRR: IOMMU: Setting identity map for device 0000:00:14.0 [0xdda21000 - 0xdda3dfff] IOMMU: Setting identity map for device 0000:00:1a.0 [0xdda21000 - 0xdda3dfff] IOMMU: Setting identity map for device 0000:00:1d.0 [0xdda21000 - 0xdda3dfff] IOMMU: Prepare 0-16MiB unity mapping for LPC IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]

Для переблокировки пробрасываемого устройства вот такой скрипт (если проброс будет нужен постоянно, то этот скрип надо в автозапуск):


$ cat kvm_hw.sh #!/bin/bash fcid="1077 2312" hostfc="0000:07:05.0" echo $fcid > /sys/bus/pci/drivers/pci-stub/new_id echo $hostfc > /sys/bus/pci/devices/$hostfc/driver/unbind echo $hostfc > /sys/bus/pci/drivers/pci-stub/bind # echo "1077 2312" > /sys/bus/pci/drivers/pci-stub/new_id # echo "0000:07:05.0" > /sys/bus/pci/drivers/pci-stub/unbind # echo "0000:07:05.0" > /sys/bus/pci/drivers/pci-stub/bind # echo "1077 2312" > /sys/bus/pci/drivers/pci-stub/remove_id

Подробности
1) Chapter 15. PCI passthrough
2) How to assign devices with VT-d in KVM
3) Dual Boot two Linux versions, GRUB_CMDLINE_LINUX?
4) 890FXA-GD70 IOMMU Causes Freezing
5) KVM проброс PCI
6) Первый тестовый проброс устройств на ASUS M5A97PRO
7) Статьи на umVirt.Ru
8) Buggy AMD-Vi firmware and patches?

№2 - Проброс с помощью технологии VFIO
Загрузи модули ядра vfio:


$ modprobe vfio vfio_pci

Подробности:
1) Проброс видеокарты в гостевую ОС из гипервизора KVM с помощью технологии VFIO;
2) Проброс видеокарты;
3) Pci passthrough.

№3 - Проброс и управление видеокартой
При необходимости управлять видеокартой (включать/выключать питание и пр.) необходимо проверить, включён ли данный функционал в ядре (если нет - придётся пересобирать):


$ grep 'VGA_SWITCHEROO=' /usr/src/kernels/4.14.8-200.fc26.x86_64/.config CONFIG_VGA_SWITCHEROO=y

Дополнительно:
1) Проброс видеокарты в KVM из под ubuntu
2) Проброс видеокарты в виртуальную машину
3) Looking Glass (A KVMFR (KVM Frame Relay) Implementation)

№4 - Ошибки и решения
а) проблемы включения IOMMU на платформе AMD
Если при проверке включения IOMMU в выводе присутствуют сообщения вида:


$ dmesg | grep -iE "(IOMMU|AMD-Vi)" [Firmware Bug]: AMD-Vi: IOAPIC[9] not in IVRS table [Firmware Bug]: AMD-Vi: IOAPIC[10] not in IVRS table [Firmware Bug]: AMD-Vi: No southbridge IOAPIC found AMD-Vi: Disabling interrupt remapping AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40 AMD-Vi: Initialized for Passthrough Mode

необходимо в параметры ядра добавить


ivrs_ioapic[9]=00:14.0 ivrs_ioapic[10]=00:00.1

Т.е. для платформы AMD надо чуть больше параметров для конфигурирования IOMMU.

б) журнал запуска и работы домена (ВМ):


$ cat /var/log/libvirt/qemu/<guest_name>.log

Если гостевая была удалена, то журнал её работы - остаётся.



е) Конфигурирование

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


$ virsh --connect qemu:///system

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


# для локального подключения $ export VIRSH_DEFAULT_CONNECT_URI=qemu:///system

И после этого команда подключения упрощается (но, хотя и описан такой способ, у меня не сработал):


$ virsh --connect

Для редактирования конфигурации "вручную", исправив соответствующий XML-файл не надо применять прямое редактирование, т.к. система не примет исправленный файл.
Правильно использовать virsh:


$ virsh edit <имя_домена>

XML-файл откроется в vi и по окончании редактирования будет перечитан системой.
QXL: WDDM драйвер видео (для Win8)
VirtIO для Windows
Installing Virtio Drivers in Windows XP Setup



ё) Настройка гостевой, требующей EFI

OVMF
Загрузка виртуальных linux-машин с диска без разделов
Как загрузить Debian в KVM с OVMF?



ж) Управление

Просмотр списка зарегистрированных ВМ (доменов):


$ virsh --connect qemu:///system list --all ID Имя Статус ---------------------------------------------------- - Windows_7 выключен

Зпуск и останов ВМ (домена) "Windows_7":


$ virsh --connect qemu:///system start Windows_7 Домен Windows_7 запущен $ virsh --connect qemu:///system destroy Windows_7 Домен Windows_7_64bit разрушен

Управление виртуализацией на основе libvirt
Virsh — управление виртуальными машинами KVM
Глава 15. Управление виртуальными машинами с помощью virsh
Управление виртуальными машинами с помощью virsh
Domain XML format



з) Протокол SPICE (Simple Protocol for Independent Computing Environments)

SPICE (home)
VirtIO for Windows
SPICE guest tools
Windows Virtio Drivers
SPICE – протокол доставки виртуального рабочего стола
Специи для виртуалки
Тонкая настройка виртуальной машины с поддержкой SPICE



и) РАЗНОЕ

Конфигурирование и управление можно производить без использования libvirt, обращаясь напрямую к QEMU. Например, таким скриптом:


#!/bin/bash /usr/bin/qemu-system-x86_64 -machine accel=kvm \ -m 3584 \ -machine pc-i440fx-1.4,accel=kvm,usb=off \ -cpu Westmere,+invpcid,+erms,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+abm,+rdtscp,+pdpe1gb,+rdrand,+f16c,+avx,+osxsave,\ +xsave,+tsc-deadline,+movbe,+pcid,+pdcm,+xtpr,+fma,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,\ +ss,+acpi,+ds,+vme \ -smp 8,sockets=4,cores=1,threads=2 \ -drive file=/home/vmhosts/Windows_Seven_x86.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,aio=native \ -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0 \ -usb -device usb-ehci -usbdevice tablet \ -vga std

Подготовка хост-машины
Web Virtual Manager
Руководство по виртуализации (Справочное руководство по виртуализации в Fedora)
Установка виртуальных машин KVM под ubuntu server
Установка и настройка KVM под управлением CentOS 6
Example Sharing Host files with the Guest
Создание новой виртуальной машины за одну минуту или «vagrant up!»
oVirt
oVirt - Live Snapshots
Features/Virt Live Snapshots
Виртуализация с KVM на Fedora 17 Server
Виртуальная видеокарта QXL на реальном железе
libguestfs - tools for accessing and modifying virtual machine disk images
File exchange between host and VM
Documentation/9psetup
VM Snapshot UI with virt-manager
О снапшотах на форуме
О снапшотах на другом форуме
Запуск Windows под Linux KVM
Enabling QEMU Guest Agent anddddd FSTRIM (AGAIN), его можно указать в переменной окружения, например, для bash:


# для локального подключения $ export VIRSH_DEFAULT_CONNECT_URI=qemu:///system

И после этого команда подключения упрощается (но, хотя и описан такой способ, у меня не сработал):


$ virsh --connect

Для редактирования конфигурации



3. Контейнерная виртуализация

а) systemd-nspawn

В случае Scientific Linux / CentOS 7 в системе уже есть поддержка, а для Fedora необходимо доустановить пакет systemd-container:


# Fedora $ dnf install systemd-container debootstrap bridge-utils # Scientific Linux / CentOS 7 $ yum install debootstrap bridge-utils

Утилиты управления:


$ systemd-nspawn $ machinectl

Особенности: контейнеры должны быть размещены на файловой системе BTRFS, т.е. "по умолчанию" эта ФС должна быть смонтирована (если сама ОС установлена не на BTRFS) в каталог /var/lib/machines/.

Примеры использования
Товарищ lemenkov так устанавливал CouchDB:


$ dnf -y --releasever=21 --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora --enablerepo=updates --enablerepo updates-testing install systemd couchdb $ systemd-nspawn -D /srv/mycontainer -b $ systemctl -M mycontainer mask systemd-logind.service $ systemctl -M mycontainer mask console-getty.service $ systemctl -M mycontainer enable couchdb.service $ systemctl -M mycontainer enable systemd-networkd.service $ machinectl reboot mycontainer

Пример размещён здесь.

Дополнительная информация
Systemd и контейнеры: знакомство с systemd-nspawn
systemd-nspawn (ArchLinux)



б) Docker

1 - Установка на CentOS 7/8

Возможно понадобится доустановить Python 3 (например, для docker-compose). Тогда надо добавить репозиторий IUS (Inline with Upstream Stable) Community:


# CentOS 7 $ yum install https://centos7.iuscommunity.org/ius-release.rpm # И сам Python 3 $ yum install python36u python36u-devel python36u-pip # CentOS 8 $ dnf install https://centos7.iuscommunity.org/ius-release.rpm # И сам Python 3 $ dnf install python36u python36u-devel python36u-pip

Для практической работы лучше использовать последнюю версию из официального источника. Существуют два вариант: Community Edition (CE) - бесплатный, Enterprise Edition (EE) - платный. Ориентируемся на CE:


## Установка необходимых пакетов # CentOS 7 $ yum install yum-utils device-mapper-persistent-data lvm2 bridge-utils zlib # CentOS 8 $ dnf install yum-utils device-mapper-persistent-data lvm2 zlib ## Добавление официального репозитория $ yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo ## Непосредственно установка Docker CE # CentOS 7 $ yum install docker-ce # CentOS 8 $ dnf install docker-ce --nobest

ВАЖНО!!! Вероятно из-за того, что на момент написания этой инструкции для CentOS 8 не был создан отдельный репозиторий и используются пакеты для CetnOS 7 - последние версии docker-ce не устанавливаются на 8 версию ОС: требуется container.io более новый, чем доступен для CentOS 8 (вероятно сделаны ограничения в самой ОС разработчиками). Поэтому для установка используется параметр --nobest.
При установке будет создана группа docker, члены которой без sudo смогут работать к Docker-ом. Поэтому добавим в эту группу пользователя, под которым будем работать с контейнерами:


$ usermod -aG docker UserName

Запускаем:


$ systemctl enable docker $ systemctl start docker

Наслаждаемся результатом.
При необходимости работать сервису docker через контейнер создадим файл /etc/systemd/system/docker.service.d/http-proxy.conf с такими строками:


[Service] Environment="HTTP_PROXY=proxy_URL:port" Environment="HTTPS_PROXY=proxy_URL:port"

Естественно, указав вместо proxy_URL:port адрес и порт действующего proxy-сервера.



2 - Управление контейнерами

2.1 - Утилитой docker

Скачивание образа контейнера:


$ docker pull tomcat:latest

Здесь tomcat - название контейнера; latest - тег (своего рода - вариант образа). Если не указывать тег, то по умолчанию ищется контейнер с тегом latest.
Запуск контейнера из образа tomcat в фоне (-d) с пробросом из контейнера на узловой адрес порта 8080 (-p, проброс всех портов: -P), c именем контейнера (--name):


$ docker run --name tomcattest -p 8880:8080 -d tomcat 73d255f74b5ea02df1b2277e9f3797ebe7cc58b9c74386f21ae0d542dbe44a8c

При запуске Докер выдал длинное 16-ричное 32-байтное число, которое является уникальным именем контейнера. Но при запуске мы указали ещё более удобное человекочитаемое имя: tomcattest. Так же используется сокращённое имя из 6 первых байт выданного 32-байтного числа - 73d255f74b5e.
Подключение к запущенному контейнеру (все три варианты имени равнозначны):


$ docker exec -it 73d255f74b5ea02df1b2277e9f3797ebe7cc58b9c74386f21ae0d542dbe44a8c /bin/bash $ docker exec -it 73d255f74b5e /bin/bash $ docker exec -it tomcattest /bin/bash

Просмотр образов, установленных в системе:


$ docker images # , в том числе и скрытых и иных $ docker images -a

Просмотр контейнеров в системе:


# активных (up) $ docker ps # во всех состояниях $ docker ps -a

Останов и запуск контейнера:


$ docker stop 73d255f74b5e $ docker start 73d255f74b5e

Удаление контейнера:


$ docker stop 73d255f74b5e $ docker rm -v 73d255f74b5e # или сразу (жёстко) $ docker rm -v -f 73d255f74b5e

2.2 - Утилитой docker-compose

Утилита docker-compose позволяет более гибко управлять контейнерами (используя DockerAPI).
Установка docker-compose:


# ставим необходимые пакеты $ yum install zlib-devel # скачиваем последнюю актуальную версию $ sudo curl -L https://github.com/docker/compose/releases/download/v2.2.3/docker-compose-`uname -s`-`uname -m` -o /usr/bin/docker-compose # присваиваем параметры запуска $ chmod +x /usr/bin/docker-compose # проверяем, что утилита работает $ docker-compose --version docker-compose version 1.19.0, build 9e633ef

Параметры, которые для docker надо было указывать в командной строке, для docker-compose указываются в конфигурационном файле docker-compose.yaml (или yml).
Пример файла docker-compose.yaml:


version: '3' services: # название сервиса tomcatback: # автоматический запуск restart: always # параметры сборки build: context: /_docker/project/backend/ dockerfile: Dockerfile.dev # базовый образ image: tomcat # переменные environment: - CATALINA_OPTS="-Dspring.profiles.active=d03" # проброс портов ports: - "8080:8080" # подключение томов узел:контейнер (файлы и каталоги) volumes: - /_docker/project/backend/tomcat-conf:/usr/local/tomcat/conf - /_docker/project/backend/transcont:/opt/backend - /_docker/project/backend/webapps:/usr/local/tomcat/webapps nginxfront: restart: always image: nginx ports: - "80:80" # зависит от... обеспечение порядка запуска depends_on: - tomcatback volumes: - /_docker/project/frontend/nginx:/etc/nginx - /_docker/project/frontend/frontend:/opt/frontend

Запуск созданной конфигурации производится в там же каталоге, где расположен файл docker-compose.yaml (т.е. по умолчанию утилита ищет данный файл в каталоге запуска). Либо прямым указанием соответствующего файла docker-compose.yaml:


# запуск конфигурации в фоновом режиме $ docker-compose up -d # ... с указанием конфигурационного файла $ docker-compose --file docker-compose.local-tests.yml up -d

В docker-compose.yaml указаны параметры сборки образов контейнеров, но по умолчанию сборка не производится. Для сборки необходимо для запуска контейнера добавить сборки:


$ docker-compose up -d --build

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


$ docker-compose ps

Остановка контейнеров конфигурации:


$ docker-compose down

3 - Сборка и публикация контейнеров

Сборка образа производится командой


$ docker build -t project/common:tomcat

Система автоматически ищет файл Dockerfile - описание процесса сборки. Например:


FROM project/common:tomcat LABEL name="backend" vendor="MySystem" license="GPLv2" build-date="20180216" ENV CATALINA_OPTS="-Dspring.profiles.active=test -Drun.properties=test" #ARG DEBIAN_FRONTEND=noninteractive RUN apt-get update -y && apt-get upgrade -y # RUN apt-get update && apt-get install -y --no-install-recommends apt-utils RUN mkdir -p /opt/backend/cert && mkdir -p /opt/backend/departments ADD account-back.war /usr/local/tomcat/webapps/backend.war ADD notification-email.war /usr/local/tomcat/webapps/notification-email.war ADD client.jks /opt/backend/cert/client.jks ADD trcont-zones.geojson /opt/backend/trcont-zones.geojson RUN sed -i '$d' /usr/local/tomcat/conf/tomcat-users.xml ; \ echo ' <role rolename="manager-gui"/>' >> tomcat-users.xml ; \ echo ' <role rolename="manager-script"/>' >> tomcat-users.xml ; \ echo ' <user username="tomcat" password="tomcat" roles="manager-gui,admin-gui"/>' >> tomcat-users.xml ; \ echo ' <user username="user_name" password="********" roles="manager-script"/>' >> tomcat-users.xml ; \ echo '</tomcat-users>' >> tomcat-users.xml EXPOSE 8080 CMD ["catalina.sh", "run"]

Следует учесть, что при сборке на каждую операцию система создают промежуточный контейнер, которые удаляются, но при сбоях могут остаться в системе. Поэтому надо просматривать периодически списки контейнеров в системе и удалять ненужные.
После сборки в системе появится образ с именем project/common и тегом tomcat. Теперь его можно отправить в репозиторий:


# авторизуемся $ docker login Username (MyUser): MyUser Password: Login Succeeded $ docker push project/common:tomcat

Всё, теперь образ собран и опубликован в репозитории.



4 - Установка локального репозитория

Исходя из документации:


# сам репозиторий $ docker run -d -p 5000:5000 --restart always --name registry -v /var/lib/docker/registry:/var/lib/registry registry:2 # web-управление docker-registry-frontend $ docker run -d -e ENV_DOCKER_REGISTRY_HOST=hq-tmc-d01.trcont.ru -e ENV_DOCKER_REGISTRY_PORT=5000 -p 8081:80 -p 8082:443 --restart always --name docker_ui konradkleine/docker-registry-frontend:v2

Есть множество иных образов систем web-управления, размещённых в Docker Hub. Например, konradkleine/docker-registry-frontend, а так же Portus, panamax.io, portainer.io и множество других.



5 - Мониторинг системой Zabbix

Мониторинг системы Docker в общем случае настраивается достаточно легко.
Устанавливаем NetCat:


$ yum install nmap-ncat

Добавляем пользователя zabbix в группу docker:


$ usermod -aG docker zabbix

Создаём файл конфигурации /etc/zabbix/zabbix_agentd.d/docker.conf для агента Zabbix:


UserParameter=docker.container.status[*],echo -e "GET /containers/$1/stats HTTP/1.0\r\n" | /bin/nc -U /var/run/docker.sock | grep HTTP | cut -d' ' -f3- UserParameter=docker.service.status,systemctl is-active docker.service UserParameter=docker.service.version,docker --version | cut -d' ' -f3-

Создадим файл скрипта /etc/zabbix/scripts/docker_container_status.sh:


#!/bin/bash function countContainers() { docker ps -q $1 | wc -l } function countCrashedContainers() { docker ps -a | grep -v -F 'Exited (0)' | grep -c -F 'Exited (' } TYPE=${1-all} case $TYPE in running) COUNT_FUNCTION="countContainers"; shift;; crashed) COUNT_FUNCTION="countCrashedContainers"; shift;; all) COUNT_FUNCTION="countContainers -a"; shift;; esac $COUNT_FUNCTION

И установим на него права права:


$ chmod 655 /etc/zabbix/scripts/docker_container_status.sh

Настраиваем SELinux:


$ setsebool -P zabbix_can_network 1

Создаём файл zabbix-agent_docker.te:


module zabbix-agent_docker 1.0; require { type container_runtime_exec_t; type kernel_t; type container_unit_file_t; type init_t; type systemd_systemctl_exec_t; type sudo_exec_t; type zabbix_agent_t; type container_runtime_t; type system_dbusd_t; class unix_stream_socket connectto; class dbus send_msg; class service status; class system module_request; class file { execute execute_no_trans }; } #============= init_t ============== allow init_t zabbix_agent_t:dbus send_msg; #============= zabbix_agent_t ============== allow zabbix_agent_t container_runtime_exec_t:file { execute execute_no_trans }; #!!!! The file '/run/docker.sock' is mislabeled on your system. #!!!! Fix with $ restorecon -R -v /run/docker.sock #!!!! This avc can be allowed using the boolean 'daemons_enable_cluster_mode' allow zabbix_agent_t container_runtime_t:unix_stream_socket connectto; allow zabbix_agent_t container_unit_file_t:service status; allow zabbix_agent_t init_t:dbus send_msg; #!!!! This avc can be allowed using the boolean 'domain_kernel_load_modules' allow zabbix_agent_t kernel_t:system module_request; allow zabbix_agent_t sudo_exec_t:file execute; allow zabbix_agent_t system_dbusd_t:dbus send_msg; #!!!! The file '/run/dbus/system_bus_socket' is mislabeled on your system. #!!!! Fix with $ restorecon -R -v /run/dbus/system_bus_socket allow zabbix_agent_t system_dbusd_t:unix_stream_socket connectto; allow zabbix_agent_t systemd_systemctl_exec_t:file { execute execute_no_trans };

Возможно что-то можно упростить (по указаниям в файле) - проверю при настройке на следующем сервере.
Обрабатываем созданный файл:


$ checkmodule -M -m -o zabbix-agent_docker.mod zabbix-agent_docker.te # создаём пакет $ semodule_package -o zabbix-agent_docker.pp -m zabbix-agent_docker.mod # загружаем модуль в ядро $ semodule -i zabbix-agent_docker.pp

Другой вариант: если у нас уже были неудачные попытки - обрабатываем аудит:


$ cat /var/log/audit/audit.log | grep zabbix_agent | grep denied | audit2allow -M zabbix-agent_docker $ semodule -i zabbix-agent_docker.pp

В Zabbix создаём шаблон, куда добавляем такие элементы данных:
1) версия docker:
  Имя: Docker service version
  Тип: Zabbix agent
  Ключ: docker.service.version
  Тип информации: Текст
2) статус сервиса docker:
  Имя: Docker service status
  Тип: Zabbix agent
  Ключ: docker.service.status
  Тип информации: Текст
3) проверка контейнера с именем <НАИМЕНОВАНИЕ>:
  Имя: Check container <НАИМЕНОВАНИЕ>
  Тип: Zabbix agent
  Ключ: docker.container.status[<НАИМЕНОВАНИЕ_КОНТЕЙНЕРА>]
  Тип информации: Текст
<НАИМЕНОВАНИЕ_КОНТЕЙНЕРА> - имя контейнера, назначенное при запуске. Можно по номеру, но номера для контейнера меняются.
Соответственно, описываем все необходимые контейнеры. Можно сделать "обнаружение", но тогда будут проблемы с временными, тестовыми и иными контейнерами, не являющиеся необходимыми для мониторинга.
Перегружаем агента для принятия изменений:


$ systemctl restart zabbix-agent

Предлагаю разделить шаблон на два: в первом будут базовые параметры, а во втором - мониторинг всех необходимых контейнеров. Ко второму же будет подключён первый. Добавлять к контролируемому серверу следует только второй шаблон: первый подключится, как зависимость.
Если всё сделано верно, то добавив наш шаблон в узел контролируемого сервера мы получил полноценный мониторинг.



6 - Проблемы и решения

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


# скачанных или собранных образов $ docker images # всех образов (скрытых, промежуточных и пр.) $ docker images -a # всех контейнеров (скрытых, промежуточных и пр.) $ docker ps -a

Удаление:


# образа по его коду $ docker rmi 3f8a4339aadd # всех образов по их коду (кроме связанных с активными контейнерами) $ docker rmi $(docker images -q) # в особых случаях (с множественными наименованиями и пр.) $ docker rmi -f 3f8a4339aadd # контейнера по его коду $ docker rm fa33b5gf33a0 # всех контейнеров по их коду (запущенные не будут удалены) $ docker rm $(docker ps -a -q) # "висящие" образы: без репозитория и тэга, не являющиеся промежуточными для других образов $ docker rmi $(docker images -q -f dangling=true) # удаление ненужных контейнеров $ docker container prune # удаление всех контейнеров, образов, сетей, контейнеров; не удаляет тома $ docker system prune # удаление всех томов $ docker volume prune

Для подкоманды prune можно использовать опции -a -f, чтобы вся зачистка происходила сразу, без интерактивных запросов. И вписать команды очистки в /etc/crontab:


0 2 * * 1 root docker system prune -a -f > /dev/null 2>&1 5 2 * * 1 root docker volume prune -f > /dev/null 2>&1

Теперь в 2 часа каждый понедельник система будет зачищена от неиспользуемых объектов Docker-а.

№2 Проблема с отображением названий в Zabbix
При переносе Zabbix с VDS на выделенный сервер столкнулся с проблемой что после свежей установки Zabbix на графиках перестали отображаться названия графиков и описание значений.
Долго ломал голову что это может быть пока не получил ответ от одного из постояльцев форума zabbix.com, который указал на раздел документации при установке zabbix-server:
Пакет zabbix-frontend-php в процессе установки настроит шрифт, который используется на генерируемых изображениях. Если вы обновили пакет из любого другого репозитория и на графиках или картах сети отсутствует текст, пожалуйста проверьте, установлен ли пакет ttf-dejavu-core и попытайтесь выполнить команду dpkg-reconfigure zabbix-frontend-php.
Сложно сказать наверняка что это было, но починилось все после того как выполнил:


$ yum reinstall ttf-dejavu-core $ yum reinstall zabbix-web $ dpkg-reconfigure zabbix-web

После этого обратился к своему zabbix-server по IP и выполнил повторную установку, подключил к базе – все заработало и графики стали рисоваться как положено.

№3 '???' вместо кириллицы при работе через SSH
При подключении консолью к серверам вместо в mc вместо кириллицы могут отображаться знаки ????.
Проблема решается достаточно просто (Debian/Ubuntu):


$ dpkg-reconfigure locales

После этого выбираю в настройках RU_ru.UTF-8.
Далее иду в настройки ssh клиента и комментирую строку:


SendEnv LANG LC_*

После этого необходимо переподключиться к серверу.



7 - Дополнительная информация

Docker, Inc is Dead
Docker (base command)
Шпаргалка с командами Docker
Пять Docker-утилит, о которых вам стоит узнать
Zabbix + мониторинг нагрузки на диски
Инструменты управления контейнерами
Rocket (rkt)
Как я год работал на CoreOS
Полная автоматизация «development» среды с помощью docker-compose

Настройка сети
[url=http://onreader.mdl.ru/LearningDockerNetworking/content/Ch02.htmlПостроение сети Docker взгляд вовнутрь[/url]
[url=https://habr.com/post/333874/Сети Docker изнутри: как Docker использует iptables и интерфейсы Linux[/url]
[url=https://github.com/moby/moby/issues/9889DOCKER_OPTS do not work in config file /etc/default/docker[/url]
[url=https://stackoverflow.com/questions/26166550/set-docker-opts-in-centosSet Docker_Opts in centos[/url]
[url=https://docs.docker.com/engine/reference/commandline/network_create/#examplesdocker network create[/url]
[url=[/url]

Смена сетевых параметров "моста" docker0 (172.16.73.128 / 255.255.255.128)



docker network create \ --driver=bridge \ --subnet=172.28.0.0/16 \ --ip-range=172.28.5.0/24 \ --gateway=172.28.5.254 \ br0

Можно изменить настройки существующего docker bridge через /etc/docker/daemon.json. Например так:



{ "bip": "172.16.73.129/25", "ip-forward": true, "ip": "0.0.0.0", "fixed-cidr": "172.16.73.128/25", "dns": ["172.23.139.213"] }

{ "bip": "172.16.73.129/25", "fixed-cidr": "172.16.73.128/25", "mtu": 1500, "default-gateway": "172.16.73.129", "dns": ["172.23.139.213","172.23.139.214"] }

{ "bip": "172.16.73.129/25", }

Можно так же добавлением параметра строки запуска, например, в файл юнита /etc/systemd/system/multi-user.target.wants/docker.service для systemd (скопировав его из /usr/lib/systemd/system/docker.service, чтобы при обновлении systemd он не перезаписался):
dockerd --bip=172.16.73.129/25

При смене сети может потребоваться удаление файла (или временное переименование, чтобы можно было 'откатиться') /var/lib/docker/network/files/local-kv.db



"Driver": "bridge", "Subnet": "172.17.0.0/16", "Gateway": "172.17.0.1"