Создать виртуальную машину по шаблону

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

Преобразовать виртуальную машину в шаблон

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

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

qm template 100

Именно это переименование и является механизмом, лежащим в основе шаблона: сам дисковый том становится base-100-disk-0, подложка, доступная только для чтения, из которой по умолчанию считывает каждый будущий клон, вместо того чтобы копировать данные напрямую.

Нет. Proxmox полностью удаляет пункт «Пуск» из собственного меню шаблона, и панель отображает именно то, что остаётся на его месте после создания шаблона web01:

Сама опция «Преобразовать в шаблон» остается видимой, но неактивной - таким образом Proxmox подтверждает, что виртуальная машина уже является шаблоном, вместо того чтобы полностью скрывать эту опцию. Левое дерево визуально отражает тот же факт: у web01 сохраняется значок в виде простого прямоугольника, тогда как у web02 и web03, которые являются обычными виртуальными машинами, вместо него отображается маленький экран монитора. Файл конфигурации подтверждает то, что уже показано в меню: новая строка, template: 1, приводится в /etc/pve/qemu-server/100.conf наряду со всем остальным, что там уже есть.

Скопировать шаблон

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

Выберите «Полный клон» или «Связанный клон»

При нажатии кнопки «Клонировать» в том же меню «Дополнительно» открывается небольшое диалоговое окно, а не очередной мастер с восемью вкладками: целевой узел, автоматически заполненный ИД следующей свободной виртуальной машины, поле «Имя» и раскрывающийся список «Режим», в котором предлагаемый выбор имеет большее значение, чем может показаться на первый взгляд.

Параметры «Целевое хранилище» и «Формат», которые на этом снимке экрана выделены серым цветом, становятся доступными только после переключения режима в «Полное клонирование»: для связанного клона не требуется принимать самостоятельного решения о хранении - он всегда размещается там же, где уже находится диск шаблона.

• Полное клонирование: полностью независимая копия каждого блока с диска шаблона, выделенная заново на любом хранилище, на которое направлено клонирование. После завершения копирования никакие изменения в шаблоне больше не могут повлиять на клон, однако это сопряжено со значительными затратами времени на само копирование: клонирование диска объемом 16 GiB таким способом заняло более минуты.
• Связанный клон: «тонкий» снимок, в котором хранятся только те данные, которые изменяются в клоне, а все неизменённые данные читаются напрямую из блоков самого шаблона. Клонирование того же диска объёмом 16 ГиБ этим способом заняло менее двух секунд, поскольку на самом деле пока ничего не копировалось.

Запустить клонирование

Уход --full по умолчанию используется связанный клон, если это поддерживается бэкэндом хранилища, что local-lvm делается здесь. Присвоение новой виртуальной машине имени web02 в соответствии с шаблоном, уже заданным для web01, позволяет сохранить единообразие между ними:

qm clone 100 101 --name web02

Эти две строки с ПРЕДУПРЕЖДЕНИЕМ стоит прочитать, а не игнорировать: пул этой лабораторной системы действительно настолько мал, что Proxmox справедливо сигнализирует об этом - такое же предупреждение появляется на производственном узле, когда количество связанных клонов становится достаточным, чтобы теоретически превысить его собственную физическую емкость, если бы каждый из них одновременно записывал данные в каждый блок. Это примечание по планированию емкости, касающееся того, что могло бы произойти в худшем случае, но в данном случае его безобидность подтверждается реальным временем выполнения, указанным прямо под ним.

Подтвердите связь в LVM

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

lvs -o lv_name,origin,lv_size pve

Эта колонка «Origin» и является фактическим подтверждением на уровне хранилища того, что представляет собой связанный клон: vm-101-disk-0 пока не содержит ничего собственного, кроме тех изменений, которые были внесены в гостевую ОС после создания клона, и каждый неизменённый блок по-прежнему сопоставляется с base-100-disk-0.

Исправить то, что клон по-прежнему имеет общего с шаблоном

Сама Proxmox рандомизирует только те адреса, которыми она управляет напрямую: новый MAC-адрес на net0, новый UUID в smbios1, новый vmgenid. Если сравнить эти два файла конфигурации рядом, становится видно именно это и ничего больше:

web01 (100): net0 virtio=BC:24:11:40:09:E7   smbios1 uuid=8874d2ab-e9ec-4094-9b59-611829e70ccb
web02 (101): net0 virtio=BC:24:11:33:95:ED   smbios1 uuid=fd463a04-aa85-4015-9b6d-884d34db4b1c

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

Да, двумя конкретными способами. Собственная система systemd machine-id, которые должны быть уникальными для каждой установки, а также любой ключ хоста SSH, сгенерированный в процессе настройки, сохраняются при клонировании в полном объёме, что подтверждается именно монтированием обоих дисков в режиме «только для чтения» и их сравнением:

Общий идентификатор машины (machine-id) вводит в заблуждение все, что использует его в качестве ключа - от собственного реестра машин D-Bus до клиента DHCP, использующего его в качестве стабильного идентификатора, а общее имя хоста делает две виртуальные машины неотличимыми с точки зрения панели мониторинга. Обе проблемы можно устранить с помощью нескольких простых команд, которые нужно выполнить один раз внутри свежего клона до того, как он попадет к клиенту:

rm -f /etc/machine-id
systemd-machine-id-setup
rm -f /etc/ssh/ssh_host_*
ssh-keygen -A
hostnamectl set-hostname web02

Эта последняя строка также должна иметь соответствующий элемент в /etc/hosts, сопоставив новое имя хоста с адресом петлевого интерфейса так же, как программа установки уже настроила это для web01 в предыдущем руководстве.

Автоматизация клонирования в рамках рабочего процесса продаж

Ни один из перечисленных выше шагов не требует от пользователя нажатия кнопок в диалоговом окне, если их действительно стоит выполнить для каждой виртуальной машины, которую платформа фактически продает. То же самое qm clone команда напрямую обращается к API Proxmox - тому самому API, которое уже использовалось в данном руководстве для создания виртуальной машины и загрузки образа ISO:

curl -k -X POST "https://pve.example.com:8006/api2/json/nodes/pve/qemu/100/clone" \
  -H "Authorization: PVEAPIToken=opsadmin@pve!automation=<token-secret>" \
  --data-urlencode "newid=102" \
  --data-urlencode "name=web03" \
  --data-urlencode "full=1"

Этот вызов возвращает идентификатор задачи сразу же, не дожидаясь завершения клонирования - это тот же асинхронный подход, который лежит в основе всех других длительных операций в Proxmox. Идентификатор задачи имеет фиксированный, легко распознаваемый формат:

UPID:pve:00002FD6:000590CA:6ABB8D48:qmclone:100:root@pam:

Опрос /nodes/pve/tasks/<that UPID>/status Именно таким же образом скрипт подготовки среды фактически определяет, что процесс полного клонирования (занимающий более минуты для диска объемом 16 ГиБ) завершился, а не делает предположения на основе фиксированной задержки.

Полный скрипт настройки объединяет четыре из этих компонента в следующей последовательности: qm clone чтобы создать виртуальную машину, необходимо machine-id и после того, как команды, связанные с ключом хоста SSH из предыдущего раздела, будут выполнены один раз внутри него, добавится маршрут для любого адреса из пула туннеля, присвоенного данному клиенту в соответствии с его заказом, и, наконец, qm start. Весь процесс от первого звонка до получения клиентом рабочих учетных данных проходит в автоматическом режиме - та же последовательность действий, которую оператор-человек выполнял вручную лишь в первый раз.