Product SiteDocumentation Site

12.2. Виртуализация

Виртуализация — это одно из крупнейших достижений вычислительной техники последних лет. Этот термин включает в себя различные абстракции и технологии имитации виртуальных компьютеров с разной степенью независимости от реального оборудования. На одном физическом сервере могут размещаться несколько систем, работающих одновременно и изолированных друг от друга. Приложений много, и зачастую они были бы невозможны без такой изоляции: к примеру, тестовые окружения с различными конфигурациями или разделение сервисов по разным виртуальным машинам для безопасности.
Существует множество решений для виртуализации, каждое со своими достоинствами и недостатками. Эта книга сфокусируется на Xen, LXC и KVM, но есть и другие реализации, достойные упоминания:

12.2.1. Xen

Xen — это решение для «паравиртуализации». Оно вводит тонкий слой абстракции, называемый «гипервизором», между оборудованием и вышележащими системами; он играет роль арбитра, контролирующего доступ к оборудованию из виртуальных машин. Однако он обрабатывает лишь немногие инструкции, остальные напрямую выполняются оборудованием от имени систем. Главное преимущество заключается в том, что производительность не страдает, и системы работают со скоростью, близкой к нативной; минусом является то, что ядра операционных систем, которые нужно запускать на гипервизоре Xen, должны быть адаптированы для этого.
Уделим немного времени терминологии. Гипервизор является нижним слоем, выполняющимся непосредственно на оборудовании, даже ниже ядра. Гипервизор может разделять остальное программное обеспечение по нескольким доменам, которые могут выглядеть как множество виртуальных машин. Один из этих доменов (первый, который запускается) известен как dom0 и имеет особую роль, поскольку только этот домен может управлять гипервизором и исполнением других доменов. Эти другие домены известны как domU. Другими словами, с точки зрения пользователя dom0 соответствует «хосту» в других системах виртуализации, а domU — «гостю».
Чтобы использовать Xen в Debian, нужны три компонента:
  • The hypervisor itself. According to the available hardware, the appropriate package providing xen-hypervisor will be either xen-hypervisor-4.17-amd64, xen-hypervisor-4.17-armhf, or xen-hypervisor-4.17-arm64.
  • A kernel that runs on that hypervisor. Any kernel more recent than 3.0 will do, including the 6.1 version present in Bookworm.
The hypervisor also brings xen-utils-4.17, which contains tools to control the hypervisor from the dom0. This in turn brings the appropriate standard library. During the installation of all that, configuration scripts also create a new entry in the GRUB bootloader menu, so as to start the chosen kernel in a Xen dom0. Note, however, that this entry is not usually set to be the first one in the list, but it will be selected by default.
Когда всё необходимое установлено, следующим шагом будет тестирование поведения самого dom0; оно включает перезагрузку в гипервизор и ядро Xen. Система должна загрузиться обычным образом, с несколькими дополнительными сообщениями в консоли на ранних стадиях инициализации.
Теперь время собственно установить подходящие системы в domU с помощью инструментов из xen-tools. Этот пакет предоставляет команду xen-create-image, которая в значительной мере автоматизирует задачу. Единственный обязательный параметр — --hostname, передающий имя domU; другие опции важны, но они могут быть сохранены в конфигурационном файле /etc/xen-tools/xen-tools.conf, и их отсутствие в командной строке не вызовет ошибки. Поэтому следует проверить содержимое этого файла перед созданием образов, или же использовать дополнительные параметры в вызове xen-create-image. Отметим следующие важные параметры:
  • --memory для указания количества ОЗУ, выделенного вновь создаваемой системе;
  • --size и --swap, чтобы задать размер «виртуальных дисков», доступных для domU;
  • --debootstrap-cmd, to specify the which debootstrap command is used. The default is debootstrap if debootstrap and cdebootstrap are installed. In that case, the --dist option will also most often be used (with a distribution name such as bookworm).
  • --dhcp объявляет, что конфигурация сети domU должна быть получена по DHCP, в то время как --ip позволяет задать статический IP-адрес.
  • Наконец, следует выбрать метод хранения для создаваемых образов (тех, которые будут видны как жёсткие диски из domU). Самый простой метод, соответствующий опции --dir, заключается в создании одного файла на dom0 для каждого устройства, которое будет передано domU. Для систем, использующих LVM, альтернативой является использование опции --lvm, за которой указывается имя группы томов; в таком случае xen-create-image создаст новый логический том в этой группе, и этот логический том станет доступным для domU как жёсткий диск.
Когда выборы сделаны, мы можем создать образ для нашего будущего Xen domU:
# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=4G --dist=bookworm --role=udev


General Information
--------------------
Hostname       :  testxen
Distribution   :  bookworm
Mirror         :  http://deb.debian.org/debian
Partitions     :  swap            512M  (swap)
                  /               4G    (ext4)
Image type     :  sparse
Memory size    :  256M
Bootloader     :  pygrub

Networking Information
----------------------
IP Address     : DHCP [MAC: 00:16:3E:9F:55:BB]


Creating partition image: /srv/testxen/domains/testxen/swap.img
Done

Creating swap on /srv/testxen/domains/testxen/swap.img
Done

Creating partition image: /srv/testxen/domains/testxen/disk.img
Done

Creating ext4 filesystem on /srv/testxen/domains/testxen/disk.img
Done
Installation method: debootstrap
Done

Running hooks
Done

Role: udev
	File: /etc/xen-tools/role.d/udev
Role script completed.

Creating Xen configuration file
Done

No role scripts were specified.  Skipping
Setting up root password
Generating a password for the new guest.
All done


Logfile produced at:
	 /var/log/xen-tools/testxen.log

Installation Summary
---------------------
Hostname        :  testxen
Distribution    :  bookworm
MAC Address     :  00:16:3E:9F:55:BB
IP Address(es)  :  dynamic
SSH Fingerprint :  SHA256:JsTNzWbiRoqTwZ60GAFFpl+s+/rmWf5GhQexQz1gCm8 (DSA)
SSH Fingerprint :  SHA256:iEuV3oFhRdDRoytTpxF4YMMgewTsQKYTU709kxCH+tk (ECDSA)
SSH Fingerprint :  SHA256:LSrc0bAIaeKI0neSEeT+Oun6uBbu47sKAo2agmq+jCI (ED25519)
SSH Fingerprint :  SHA256:/4OS5h74tkzSlk5/EU/tchvrar32vpoJoCudyDnw9W0 (RSA)
Root Password   :  3Bbnf5qFcEMDucK4sMYFJY7
Теперь у нас есть виртуальная машина, но она ещё не запущена (и поэтому только занимает место на жёстком диске dom0). Разумеется, мы можем создать больше образов, возможно с разными параметрами.
До включения этих виртуальных машин нам нужно определить, как будет получаться доступ к ним. Разумеется, они могут быть назначены изолированными машинами, доступными только через системную консоль, но это редко соответствует сценарию работы. Большую часть времени domU будет считаться удалённым сервером, и доступ к нему будет осуществляться только через сеть. Однако было бы весьма неудобным добавлять сетевую карту для каждого domU; по этой причине Xen позволяет создавать виртуальные интерфейсы, которые каждый домен может видеть и использовать обычным образом. Заметьте, что эти карты, хоть они и виртуальные, будут полезными только когда они подключены к сети, хотя бы виртуальной. У Xen есть несколько сетевых моделей для этого:
  • Простейшей является модель моста; все сетевые карты eth0 (как в dom0, так и в domU-системах) ведут себя, как если бы они были напрямую подключены к Ethernet-коммутатору.
  • Следующая модель — маршрутизируемая, когда dom0 ведёт себя как маршрутизатор, находящийся между domU-системами и (физической) внешней сетью.
  • Наконец, в модели NAT dom0 опять находится между domU-системами и остальной сетью, но domU-системы не доступны извне напрямую, и трафик проходит через преобразование адресов на dom0.
Эти три сетевых режима включают различные интерфейсы с необычными именами, такими как vif*, veth*, peth* и xenbr0. Гипервизор Xen комбинирует их в соответствии с заданной схемой под контролем инструментов пространства пользователя. Поскольку NAT и маршрутизируемая модель приспособлены лишь для отдельных случаев, мы рассмотрим только модель моста.
The standard configuration of the Xen packages does not change the system-wide network configuration. However, the xend daemon is configured to integrate virtual network interfaces into any pre-existing network bridge (with xenbr0 taking precedence if several such bridges exist). We must therefore set up a bridge in /etc/network/interfaces (which requires installing the bridge-utils package, which is why the xen-utils package recommends it) to replace the existing eth0 entry. Be careful to use the correct network device name:
auto xenbr0
iface xenbr0 inet dhcp
    bridge_ports eth0
    bridge_maxwait 0
Перезагрузившись для проверки, что мост создаётся автоматически, мы можем запустить domU с помощью инструментов управления Xen, а именно команды xl. Эта команда позволяет производить различные манипуляции с доменами, в частности выводить их список, запускать их и останавливать. Может понадобиться увеличить объём памяти по умолчанию, отредактировав значение переменной memory в конфигурационном файле (в данном случае — /etc/xen/testxen.cfg). Здесь мы установили его в 1024 (мегабайт).
# xl list
Name                                ID   Mem VCPUs      State   Time(s)
Domain-0                             0  7973     4     r-----      13.6
# xl create /etc/xen/testxen.cfg
Parsing config from /etc/xen/testxen.cfg
# xl list
Name                                ID   Mem VCPUs      State   Time(s)
Domain-0                             0  7841     4     r-----      87.1
testxen                              4     0     0     --p---       0.0
Заметьте, что domU testxen использует реальную память, взятую из ОЗУ, которая иначе была бы доступна dom0, а не виртуальную. Поэтому при сборке сервера для размещения машин Xen следует побеспокоиться об обеспечении достаточного объёма физического ОЗУ.
Voilà! Наша виртуальная машина запускается. Мы можем получить доступ к ней в одном из двух режимов. Обычный путь — подключаться к ней «удалённо» через сеть, как мы подключались бы к реальной машине; для этого обычно требуется настройка либо DHCP-сервера, либо DNS. Другой путь, который может стать единственно возможным в случае неправильной настройки сети, — использование консоли hvc0 с помощью команды xl console:
# xl console testxen
[...]

Debian GNU/Linux 12 testxen hvc0

testxen login: 
После этого можно начать сессию, как если бы вы сидели за клавиатурой виртуальной машины. Для отключения от этой консоли служит сочетание клавиш Control+].
Когда domU запущен, он может использоваться как любой другой сервер (ведь это, помимо прочего, система GNU/Linux). Однако благодаря тому, что это виртуальная машина, доступны и некоторые дополнительные возможности. К примеру, domU может быть временно приостановлен, а затем вновь запущен с помощью команд xl pause и xl unpause. Заметьте, что хотя приостановленный domU не использует ресурсы процессора, выделенная ему память по-прежнему занята. Может иметь смысл использовать команды xl save и xl restore: сохранение domU освобождает ресурсы, которые ранее использовались этим domU, в том числе и ОЗУ. После восстановления (или снятия с паузы) domU не замечает ничего кроме того, что прошло некоторое время. Если domU был запущен, когда dom0 выключается, сценарии из пакетов автоматически сохраняют domU и восстанавливают его при следующей загрузке. Отсюда, конечно, проистекает обычное неудобство, проявляющееся, например, при переводе ноутбука в спящий режим; в частности, если domU приостановлен слишком надолго, сетевые подключения могут завершиться. Заметьте также, что Xen на данный момент несовместим с большей частью системы управления питанием ACPI, что мешает приостановке dom0-системы.
Выключение или перезагрузка domU могут быть выполнены как изнутри domU (с помощью команды shutdown), так и из dom0, с помощью xl shutdown или xl reboot.
Большая часть подкоманд xl требуют одного или более аргументов, часто — имени domU. Эти аргументы подробно описаны в странице руководства xl(1).

12.2.2. LXC

Хотя она и используется для создания «виртуальных машин», LXC является, строго говоря, не системой виртуализации, а системой для изоляции групп процессов друг от друга, даже если они все выполняются на одном узле. Она использует набор недавних изменений в ядре Linux, известных под общим названием control groups, благодаря которому разные наборы процессов, называемые «группами», имеют разные представления о некоторых аспектах системы. Наиболее примечательные из этих аспектов — идентификаторы процессов, конфигурация сети и точки монтирования. Такая группа изолированных процессов не будет иметь доступа к другим процессам в системе, и её доступ к файловой системе может быть ограничен определённым подмножеством. У неё также могут быть свои собственные сетевой интерфейс и таблица маршрутизации, и она может быть настроена так, чтобы видеть только подмножество устройств, присутствующих в системе.
С помощью комбинации этих возможностей можно изолировать целое семейство процессов начиная с процесса init, и получившийся набор будет выглядеть чрезвычайно похоже на виртуальную машину. Официальное название для такой схемы «контейнер» (отсюда и неофициальное название LXC: LinuX Containers), но весьма значительным отличием от «настоящих» виртуальных машин, таких как предоставляемые Xen или KVM, заключается в отсутствии второго ядра; контейнер использует то же самое ядро, что и хост-система. У этого есть как преимущества, так и недостатки: к преимуществам относится великолепная производительность благодаря полному отсутствию накладных расходов, а также тот факт, что ядро видит все процессы в системе, поэтому планировщик может работать более эффективно, чем если бы два независимых ядра занимались планированием выполнения разных наборов задач. Основное из неудобств — невозможность запустить другое ядро в контейнере (как другую версию Linux, так и другую операционную систему).
Поскольку мы имеем дело с изоляцией, а не обычной виртуализацией, настройка контейнеров LXC более сложна, чем простой запуск debian-installer на виртуальной машине. Мы опишем некоторые предварительные требования, затем перейдём к конфигурации сети; после этого мы сможем собственно создать систему для запуска в контейнере.

12.2.2.1. Предварительные шаги

Пакет lxc содержит инструменты, необходимые для запуска LXC, поэтому его необходимо установить.
LXC также требует систему конфигурации control groups, представляющую собой виртуальную файловую систему, которая должна быть смонтирована в /sys/fs/cgroup. Так как Debian 8 перешел на systemd, который также зависит от control groups, это делается автоматически во время загрузки без дополнительной настройки.

12.2.2.2. Сетевые настройки

Цель установки LXC — в запуске виртуальных машин; хотя мы, разумеется, можем держать их изолированными от сети и взаимодействовать с ними только через файловую систему, для большинства задач требуется хотя бы минимальный сетевой доступ к контейнерам. В типичном случае каждый контейнер получит виртуальный сетевой интерфейс присоединённый к реальной сети через мост. Этот виртуальный интерфейс может быть подключён либо напрямую к физическому сетевому интерфейсу хост-системы (в таком случае контейнер непосредственно в сети), либо к другому виртуальному интерфейсу, определённому в хост-системе (тогда хост сможет фильтровать или маршрутизировать трафик). В обоих случаях потребуется пакет bridge-utils.
The simple case is just a matter of editing /etc/network/interfaces, moving the configuration for the physical interface (for instance, eth0 or enp1s0) to a bridge interface (usually br0), and configuring the link between them. For instance, if the network interface configuration file initially contains entries such as the following:
auto eth0
iface eth0 inet dhcp
Их следует отключить и заменить на следующие:
auto eth0
iface eth0 inet static

auto br0
iface br0 inet dhcp
    bridge-ports eth0
Результат такой настройки будет похож на тот, какой мы получили бы, если бы контейнеры были машинами, подключёнными к той же физической сети, что и хост-машина. Конфигурация «мост» управляет прохождением кадров Ethernet между всеми связанными интерфейсами, включая и физический eth0, и интерфейсы, заданные для контейнеров.
В случаях, когда такую конфигурацию использовать невозможно (например, если контейнерам нельзя выделить публичные IP-адреса), будет создан и подключён к мосту виртуальный tap-интерфейс. Это будет эквивалентно сетевой топологии, при которой вторая сетевая карта подключена к отдельному коммутатору, и к нему же подключены контейнеры. Хост тогда должен выступать как шлюз для контейнеров, если им требуется соединяться с остальным миром.
В дополнение к bridge-utils для «продвинутой» конфигурации потребуется пакет vde2; файл /etc/network/interfaces тогда примет следующий вид:
# Interface eth0 is unchanged
auto eth0
iface eth0 inet dhcp

# Virtual interface 
auto tap0
iface tap0 inet manual
    vde2-switch -t tap0

# Bridge for containers
auto br0
iface br0 inet static
    bridge-ports tap0
    address 10.0.0.1
    netmask 255.255.255.0
Сеть может быть настроена как статически в контейнерах, так и динамически и помощью DHCP-сервера, запущенного на хост-системе. Такой DHCP-сервер должен быть сконфигурирован для ответа на запросы на интерфейсе br0.

12.2.2.3. Установка системы

Let us now set up the filesystem to be used by the container. Since this “virtual machine” will not run directly on the hardware, some tweaks are required when compared to a standard filesystem, especially as far as the kernel, devices and consoles are concerned. Fortunately, the lxc package includes scripts that mostly automate this configuration. For instance, the following commands (which require the debootstrap and rsync packages) will install a Debian container:
# lxc-create -n testlxc -t debian
debootstrap is /usr/sbin/debootstrap
Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ... 
Downloading debian minimal ...
I: Retrieving Release 
I: Retrieving Release.gpg 
[...]
Download complete.
Copying rootfs to /var/lib/lxc/testlxc/rootfs...
[...]
# 
Заметьте, что файловая система изначально создана в /var/cache/lxc, а затем перемещена в каталог назначения. Это позволяет создавать идентичные контейнеры намного быстрее, поскольку требуется лишь скопировать их.
Заметьте, что сценарий создания шаблона debian принимает опцию --arch с указанием архитектуры системы для установки и опцию --release, если вы хотите установить что-то отличное от текущего стабильного релиза Debian. Вы можете также установить переменную окружения MIRROR, чтобы указать на локальное зеркало Debian.
The lxc package further creates a bridge interface lxcbr0, which by default is used by all newly created containers via /etc/lxc/default.conf and the lxc-net service:
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
These entries mean, respectively, that a virtual interface will be created in every new container; that it will automatically be brought up when said container is started; and that it will be automatically connected to the lxcbr0 bridge on the host. You will find these settings in the created container's configuration (/var/lib/lxc/testlxc/config), where also the device' MAC address will be specified in lxc.net.0.hwaddr. Should this last entry be missing or disabled, a random MAC address will be generated.
Другая полезная запись в этом файле — имя узла:
lxc.uts.name = testlxc
The newly-created filesystem now contains a minimal Debian system and a network interface.

12.2.2.4. Запуск контейнера

Now that our virtual machine image is ready, let's start the container with lxc-start --name=testlxc.
In LXC releases following 2.0.8, root passwords are not set by default. We can set one running lxc-attach -n testlxc passwd if we want. We can login with:
# lxc-console -n testlxc
Connected to tty 1
Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself

Debian GNU/Linux 12 testlxc tty1

testlxc login: root
Password: 
Linux testlxc 6.1.0-23-amd64 #1 SMP Debian 6.1.99-1 (2024-07-15) 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.
Last login: Wed Jun  7 18:39:37 UTC 2024 on console
root@testlxc:~# ps auxwf
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.2  18964 11464 ?        Ss   01:36   0:00 /sbin/init
root          45  0.0  0.2  31940 10396 ?        Ss   01:37   0:00 /lib/systemd/systemd-journald
root          71  0.0  0.1  99800  5724 ?        Ssl  01:37   0:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid [..]
root          97  0.0  0.1  13276  6980 ?        Ss   01:37   0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root         160  0.0  0.0   6276  3928 pts/0    Ss   01:46   0:00 /bin/login -p --
root         169  0.0  0.0   7100  3824 pts/0    S    01:51   0:00  \_ -bash
root         172  0.0  0.0   9672  3348 pts/0    R+   01:51   0:00      \_ ps auxwf
root         164  0.0  0.0   5416  2128 pts/1    Ss+  01:49   0:00 /sbin/agetty -o -p -- \u --noclear [...]
root@testlxc:~# 
Теперь мы в контейнере; наш доступ к процессам ограничен только теми, которые запущены изнутри самого контейнера, и наш доступ к файловой системе также ограничен до выделенного подмножества полной файловой системы (/var/lib/lxc/testlxc/rootfs). Мы можем выйти из консоли с помощью Control+a q.
Note that we ran the container as a background process, thanks to lxc-start starting using the --daemon option by default. We can interrupt the container with a command such as lxc-stop --name=testlxc.
Пакет lxcсодержит сценарий инициализации, который может автоматически запускать один или несколько контейнеров при загрузке хост-системы (он использует lxc-autostart, запускающую контейнеры, параметр lxc.start.auto которых установлен в значение 1). Более тонкий контроль порядка запуска возможен с помощью lxc.start.order и lxc.group: по умолчанию сценарий инициализации сначала запускает контейнеры, входящие в группу onboot, а затем — контейнеры, не входящие ни в какие группы. В обоих случаях порядок внутри группы определяется параметром lxc.start.order.

12.2.3. Виртуализация с помощью KVM

KVM, что расшифровывается как Kernel-based Virtual Machine, является первым и главным модулем ядра, предоставляющим большую часть инфраструктуры, которая может использоваться виртуализатором, но не является самим виртуализатором. Собственно контроль за виртуализацией осуществляется приложением, основанным на QEMU. Не переживайте, если в этом разделе будут упоминаться команды qemu-*: речь всё равно о KVM.
В отличие от других систем виртуализации, KVM был влит в ядро Linux с самого начала. Его разработчики выбрали использование наборов инструкций процессора, выделенных для виртуализации (Intel-VT и AMD-V), благодаря чему KVM получился легковесным, элегантным и не прожорливым до ресурсов. Обратной стороной медали является, естественно, то, что KVM работает не на любом компьютере, а только на таком, в котором установлен подобающий процессор. Для x86-машин можно убедиться, такой ли у вас процессор, проверив наличие флага «vmx» или «svm» в файле /proc/cpuinfo.
Поскольку его разработка активно поддерживается Red Hat, KVM стал в той или иной степени эталоном виртуализации в Linux.

12.2.3.1. Предварительные шаги

Unlike such tools as VirtualBox, KVM itself doesn't include any user-interface for creating and managing virtual machines. The virtual qemu-kvm package only provides an executable able to start a virtual machine, as well as an initialization script that loads the appropriate kernel modules.
Fortunately, Red Hat also provides another set of tools to address that problem, by developing the libvirt library and the associated virtual machine manager tools. libvirt allows managing virtual machines in a uniform way, independently of the virtualization system involved behind the scenes (it currently supports QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare, and UML). virt-manager is a graphical interface that uses libvirt to create and manage virtual machines.
Первым делом мы установим необходимые пакеты с помощью команды apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-bin предоставляет демон libvirtd, позволяющий (возможно удалённо) управлять виртуальными машинами, запущенными на хосте, и запускает необходимые виртуальные машины при загрузке хоста. libvirt-clients предоставляет утилиту virsh с интерфейсом командной строки, которая позволяет контролировать виртуальные машины, управляемые libvirt.
Пакет virtinst предоставляет virt-install, которая позволяет создавать виртуальные машины из командной строки. Наконец, virt-viewer позволяет получать доступ к графической консоли виртуальной машины.

12.2.3.2. Сетевые настройки

Как и в случаях Xen и LXC, наиболее распространённая сетевая конфигурация включает мост, группирующий сетевые интерфейсы виртуальных машин (см. Раздел 12.2.2.2, «Сетевые настройки»).
В качестве альтернативы, в конфигурации KVM по умолчанию, виртуальной машине выдаётся адрес из частного диапазона (192.168.122.0/24), и NAT настраивается таким образом, чтобы виртуальная машина могла получить доступ во внешнюю сеть.
Ниже в этом разделе считается, что на хост-системе имеются физический интерфейс eth0 и мост br0, и что первый присоединён к последнему.

12.2.3.3. Установка с помощью virt-install

Создание виртуальной машины очень похоже на установку обычной системы с той разницей, что характеристики виртуальной машины описываются в командной строке, кажущейся бесконечной.
С практической точки зрения это значит, что мы будем использовать установщик Debian, загружая виртуальную машину с виртуального привода DVD-ROM, соответствующего образу DVD Debian, хранящемуся на хост-системе. Виртуальная машина экспортирует свой графический интерфейс по протоколу VNC (см. подробности в Раздел 9.2.2, «Использование удалённых графических рабочих столов»), что позволит нам контролировать процесс установки.
We first need to tell libvirtd where to store the disk images, unless the default location (/var/lib/libvirt/images/) is fine.
# mkdir /srv/kvm
# virsh pool-create-as srv-kvm dir --target /srv/kvm
Pool srv-kvm created

# 
Давайте запустим процесс установки на виртуальной машине и поближе взглянем на наиболее важные опции virt-install. Эта команда регистрирует виртуальную машину и её параметры в libvirtd, а затем запускает её, чтобы приступить к установке.
# virt-install --connect qemu:///system  1
               --virt-type kvm           2
               --name testkvm            3
               --memory 2048             4
               --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10  5
               --cdrom /srv/isos/debian-12.6.0-amd64-netinst.iso  6
               --network bridge=virbr0   7
               --graphics vnc            8
               --os-type linux           9
               --os-variant debiantesting


Starting install...
Allocating 'testkvm.qcow'

1

Опция --connect указывает, какой «гипервизор» использовать. Он указывается в виде URL, содержащего систему виртуализации(xen://, qemu://, lxc://, openvz://, vbox:// и т. п.) и машину, на которой должны размещаться виртуальные машины (это поле можно оставить пустым в случае локального узла). В дополнение к этому, в случае QEMU/KVM каждый пользователь может управлять виртуальными машинами, работающими с ограниченными правами, и путь URL позволяет дифференцировать «системные» машины (/system) от остальных (/session).

2

Так как KVM управляется тем же образом, что и QEMU, в --virt-type kvm можно указать использование KVM, хотя URL и выглядит так же, как для QEMU.

3

Опция --name задаёт (уникальное) имя виртуальной машины.

4

Опция --memory позволяет указать объём ОЗУ (в МБ), который будет выделен виртуальной машине.

5

--disk служит для указания местоположения файла образа, который будет представляться жёстким диском виртуальной машины; этот файл создаётся, если только ещё не существует, а его размер (в ГБ) указывается параметром size. Параметр format позволяет выбрать из нескольких способов хранения образа файла. Формат по умолчанию (qcow2) позволяет начать с небольшого файла, увеличивающегося только по мере того, как виртуальная машина использует пространство.

6

Опция --cdrom используется, чтобы указать, где искать оптический диск для установки. Путь может быть либо локальным путём к ISO-файлу, либо URL, по которому можно получить файл, либо файлом устройства физического привода CD-ROM (то есть /dev/cdrom).

7

С помощью опции --network указывается, каким образом виртуальная сетевая карта интегрируется в сетевую конфигурацию хоста. Поведением по умолчанию (которое мы задали явно в этом примере) является интеграция в любой существующий сетевой мост. Если ни одного моста нет, виртуальная машина сможет получить доступ к физической сети только через NAT, поэтому она получает адрес в подсети из частного диапазона (192.168.122.0/24).
The default network configuration, which contains the definition for a virbr0 bridge interface, can be edited using virsh net-edit default and started via virsh net-start default if not already done automatically during system start.

8

--graphics vnc означает, что подключение к графической консоли нужно сделать доступным через VNC. По умолчанию соответствующий VNC-сервер слушает только на локальном интерфейсе; если VNC-клиент должен запускаться на другой системе, для подключения потребуется использовать SSH-туннель (см. Раздел 9.2.1.5, «Создание шифрованных туннелей»). Как вариант, можно использовать опцию --graphics vnc,listen=0.0.0.0, чтобы VNC-сервер стал доступен на всех интерфейсах; заметьте, что если вы сделаете так, вам серьёзно стоит заняться настройкой межсетевого экрана.

9

Опции --os-type и --os-variant позволяют оптимизировать некоторые параметры виртуальной машины, исходя из известных особенностей указанной операционной системы.
The full list of OS types can be shown using the osinfo-query os command from the libosinfo-bin package.
Сейчас виртуальная машина запущена, и нам надо подключиться к графической консоли, чтобы произвести установку. Если предыдущий шаг выполнялся в графическом окружении, это подключение установится автоматически. В противном случае, или же при удалённой работе, чтобы открыть графическую консоль, можно запустить virt-viewer в любом графическом окружении (пароль root на удалённой машине запрашивается дважды, поскольку для работы требуется два SSH-соединения):
$ virt-viewer --connect qemu+ssh://root@server/system testkvm
root@server's password: 
root@server's password: 
Connecting to installer session using virt-viewer

Рисунок 12.1. Connecting to installer session using virt-viewer

Когда процесс установки завершится, виртуальная машина перезагрузится и будет готова к работе.

12.2.3.4. Управление машинами с помощью virsh

Теперь, когда установка выполнена, давайте посмотрим, как обращаться с имеющимися виртуальными машинами. Первым делом попробуем попросить у libvirtd список управляемых им виртуальных машин:
# virsh -c qemu:///system list --all
 Id Name                 State
----------------------------------
  8 testkvm              shut off
Давайте запустим нашу тестовую виртуальную машину:
# virsh -c qemu:///system start testkvm
Domain testkvm стартует 
Теперь можно получить инструкции для подключения к графической консоли (возвращённый VNC-дисплей можно передать в качестве параметра команде vncviewer):
# virsh -c qemu:///system vncdisplay testkvm
127.0.0.1:0
В число прочих подкоманд virsh входят:
  • reboot для перезапуска виртуальной машины;
  • shutdown для корректного завершения работы;
  • destroy для грубого прерывания работы;
  • suspend для временной приостановки;
  • resume для продолжения работы после приостановки;
  • autostart для включения (или для выключения, с опцией --disable) автоматического запуска виртуальной машины при запуске хост-системы;
  • undefine для удаления всех следов виртуальной машины из libvirtd.
All these sub-commands take a virtual machine identifier as a parameter.