В предыдущем руководстве вы обеспечили безопасность этого единственного узла Proxmox, а именно: настроили учетную запись, отличную от root, с двухфакторной аутентификацией, брандмауэр и токен API с ограниченным доступом для автоматизации. В данном руководстве все три компонента используются для создания первой виртуальной машины, которую платформа будет фактически размещать - от загрузки образа установщика до запуска гостевой системы с операционной системой.
Загрузить установочный образ
При новой установке Proxmox установочные носители изначально отсутствуют, поэтому прежде чем виртуальная машина сможет указать операционную систему, программа установки этой ОС должна находиться в месте, доступном для Proxmox. Эти носители хранятся на панели «ISO-образы» на странице хранилища, которая по умолчанию совершенно пуста.
Proxmox может загрузить этот мультимедийный файл самостоятельно, прямо на узле, вместо того чтобы загружать файл с локального компьютера через медленное соединение. Кнопка «Загрузить с URL» на той же панели открывает небольшое диалоговое окно, в котором требуется указать лишь URL-адрес.
В этом руководстве описывается установка Debian внутри виртуальной машины - того же дистрибутива, на котором работает сама Proxmox, - с использованием небольшого образа netinst вместо полного DVD: он занимает всего несколько сотен мегабайт, а остальные пакеты, необходимые для установки, загружаются по сети по мере её выполнения.
Почему бы вместо этого просто не клонировать операционную систему самого хоста Proxmox в виртуальную машину?
Дело в том, что собственная ОС гипервизора и всё, что работает внутри его виртуальных машин, - это совершенно разные вещи. Собственная Debian-основа Proxmox существует исключительно для запуска стека гипервизора, в то время как гостевая виртуальная машина может свободно запускать всё, что действительно требуется для конкретной рабочей нагрузки, и на реальной платформе это редко бывает один и тот же дистрибутив дважды.
Если ввести настоящий URL-адрес сетевой установки Debian и нажать кнопку «Проверить URL», файл будет проверен ещё до начала загрузки, что позволит подтвердить как его реальный размер, так и реальный тип содержимого.
При нажатии кнопки «Скачать» загрузка запускается на самом узле в фоновом режиме с собственным журналом задач в режиме реального времени, а не с помощью индикатора выполнения в браузере, привязанного к этой вкладке.
На это перенаправление стоит обратить внимание, а не пропускать его мимо: cdimage.debian.org Сам сервер никогда не предоставляет файл - он лишь для каждого запроса определяет, какой из реальных зеркальных серверов находится ближе всего или менее загружен, и перенаправляет загрузку на него. При повторной попытке подключения из другой сети пользователь может попасть на совершенно другой зеркальный сервер, при этом со стороны Proxmox ничего не изменится.
После завершения задачи в том же списке ISO-образов, что и раньше, теперь отображается ровно один файл с реальным размером и реальной меткой времени вместо заполнителя.
Кнопка «Скачать по URL» сама по себе представляет собой простую оболочку для одного вызова API, о чем стоит знать, если этот шаг необходимо выполнять в автоматическом режиме в рамках развертывания всей платформы, а не с помощью ручного нажатия кнопки в диалоговом окне каждый раз:
curl -k -X POST "https://pve.example.com:8006/api2/json/nodes/pve/storage/local/download-url" \
-H "Authorization: PVEAPIToken=opsadmin@pve!automation=<token-secret>" \
--data-urlencode "content=iso" \
--data-urlencode "filename=debian-13.7.0-amd64-netinst.iso" \
--data-urlencode "url=https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-13.7.0-amd64-netinst.iso"
Токен здесь тот же самый opsadmin@pve!automation токен, созданный в предыдущем руководстве, при этом его область действия по-прежнему ограничена только теми разрешениями, которые ему действительно необходимы.
Пройдите мастер создания виртуальной машины
Кнопка «Создать виртуальную машину», расположенная в правом верхнем углу любой страницы Proxmox, открывает мастер из восьми вкладок. В этом нет никакой «тайной магии»: все поля на всех восьми вкладках объединяются в единый набор параметров, который отправляется один раз - в самом конце - в виде одного API-вызова. Наблюдая за тем, как каждая вкладка по частям формирует этот один и тот же вызов, API становится гораздо менее загадочным, когда он появляется на последней вкладке.
Укажите название виртуальной машины и выберите её идентификатор
На вкладке «Общие» сначала запрашиваются наименее интересные данные: идентификатор виртуальной машины (VM ID), который Proxmox уже заполняет следующим свободным номером на данном узле, и имя (Name), которое носит чисто косметический характер и никак не влияет на фактическую гостевую ОС, если только его позже не скопировать вручную.
Наведите курсор на установочный образ
На вкладке «ОС» и происходит фактическое использование ранее загруженного ISO-образа. Если оставить поле «ISO-образ» пустым и попытаться перейти дальше, на экране появится реальная ошибка проверки, а не позволит мастеру продолжить работу без уведомления.
При выборе этого файла также устанавливается тип гостевой ОС «Linux», а в поле «Версия» открывается выпадающий список, который на самом деле меньше, чем кажется: Proxmox здесь фактически различает только два поколения Linux.
Так имеет ли на самом деле значение конкретное число в «7.x» для гостевой системы Debian 13?
Это никоим образом не влияет на поведение системы. «7.x - ядро 2.6» - это собственное сокращение Proxmox для обозначения любого современного ядра Linux, начиная с версий серии 2.6, которое на данный момент охватывает практически все дистрибутивы, по-прежнему получающие обновления; «Ядро 2.4» существует исключительно для действительно древних гостевых систем, появившихся до него. Debian 13 полностью попадает в первую категорию, несмотря на буквальное упоминание «7» в названии.
Оставьте настройки по умолчанию, установите один флажок
Настройки по умолчанию на вкладке «Система» уже подходят для первой виртуальной машины: «VirtIO SCSI single» в качестве дискового контроллера, «Default (i440fx)» в качестве типа машины, SeaBIOS вместо UEFI. Единственный флажок, который стоит специально установить, - это «Qemu Agent», который по умолчанию не установлен.
Установка флажка сама по себе ничего не устанавливает - она лишь указывает Proxmox, что следует ожидать, что гостевой агент будет отвечать через виртуальный последовательный канал. Работает ли этот агент на самом деле внутри гостевой системы - это отдельный вопрос, к которому мы вернёмся в данном руководстве после установки самой ОС.
Изменение размера виртуального диска
На вкладке «Диски» по умолчанию указан диск объёмом 32 GiB в локальном LVM - это больше, чем требуется для этой первой виртуальной машины, и больше, чем должен нести в одиночку «тонкий» пул, размер которого был задан в предыдущем руководстве. Уменьшение объёма до 16 ГБ оставляет достаточно места для базовой установки Debian и её журналов, не задействуя при этом больше ресурсов пула, чем это оправдано для первой тестовой виртуальной машины.
Назначить ядра процессора
На вкладке «Процессор» по умолчанию указаны один сокет, одно ядро и тип процессора «x86-64-v2-AES» вместо точной модели хоста. Увеличение количества ядер до 2 обеспечивает этой виртуальной машине достаточную мощность для выполнения параллельных задач.
Этот вариант по умолчанию представляет собой намеренный контраст с выбором, сделанным в предыдущем руководстве: -cpu host для запуска самой Proxmox в лабораторных условиях: гостевая виртуальная машина на реальной платформе может когда-нибудь потребовать переноса на другое физическое оборудование, и тип процессора, привязанный к конкретному набору характеристик данного хоста, приведет к полному сбою такого переноса. Переносимый базовый тип жертвует небольшой долей исходной производительности ради возможности перемещения, что, как правило, является правильным компромиссом для всего, что фактически обслуживает клиентов.
Установить верхний предел объёма памяти
На вкладке «Память» по умолчанию установлено значение 2048 MiB. При включении раздела «Дополнительно» появляются те же параметры «Ballooning Device» и «Allow KSM», о которых говорилось в предыдущем руководстве; оба они по умолчанию установлены для любой новой виртуальной машины.
Начальное значение минимального объема памяти равно самому объему памяти, что означает, что фактический диапазон динамического расширения пока отсутствует; он становится полезным только после того, как это минимальное значение будет уменьшено, что позволит Proxmox извлечь разницу из простоящей виртуальной машины в условиях реальной нехватки памяти.
Прикрепите его к мосту
На вкладке «Сеть» виртуальная машина подключается к vmbr0 - тому же мосту, который рассматривался в предыдущем руководстве, - с использованием модели VirtIO для обеспечения максимальной производительности, которую может обеспечить паравиртуализированный драйвер. По умолчанию на самом сетевом интерфейсе установлен флажок «Брандмауэр».
Этот флажок представляет собой другой переключатель, отличный от рассмотренного ранее параметра включения брандмауэра на уровне центра обработки данных, который на данном узле по-прежнему находится в выключенном состоянии. Установка флажка здесь пока не дает видимого эффекта, но это означает, что в тот момент, когда главный переключатель будет включен позже, трафик этой виртуальной машины уже будет подпадать под действие всех применимых к ней правил, а не потребует повторной настройки для каждого интерфейса по отдельности.
Просмотр и создание
На вкладке «Подтвердить» все значения из предыдущих вкладок представлены в виде простой таблицы «ключ-значение», и эта таблица не является сводкой, предназначенной для человека, а представляет собой буквальное тело запроса, которое мастер собирается отправить.
Если установить флажок «Начать проверку» после создания и нажать «Готово», эта таблица отправляется в виде одного реального API-запроса, который приведён здесь в полном виде, а не в виде предположения:
curl -k -X POST "https://pve.example.com:8006/api2/json/nodes/pve/qemu" \
-H "Authorization: PVEAPIToken=opsadmin@pve!automation=<token-secret>" \
--data-urlencode "vmid=100" \
--data-urlencode "name=web01" \
--data-urlencode "ostype=l26" \
--data-urlencode "ide2=local:iso/debian-13.7.0-amd64-netinst.iso,media=cdrom" \
--data-urlencode "scsihw=virtio-scsi-single" \
--data-urlencode "scsi0=local-lvm:16,iothread=on" \
--data-urlencode "agent=1" \
--data-urlencode "sockets=1" \
--data-urlencode "cores=2" \
--data-urlencode "cpu=x86-64-v2-AES" \
--data-urlencode "memory=2048" \
--data-urlencode "net0=virtio,bridge=vmbr0,firewall=1" \
--data-urlencode "start=1"
Этот единственный вызов одновременно создаёт и запускает виртуальную машину, что подтверждается наличием в журнале двух отдельных реальных задач вместо одной: «VM 100 - Create», за которой сразу следует «VM 100 - Start».
Загрузитесь в программу установки
При открытии вкладки «Консоль» этой виртуальной машины сразу появляется то же меню загрузки программы установки Debian, которое уже подробно рассматривалось в предыдущем руководстве для физического хоста, только на этот раз оно запущено в консоли виртуальной машины, а не на «голом железе». Следующие экраны в обоих случаях идентичны, поэтому во втором прохождении данное руководство проходит их быстрее, уделяя внимание только тому, что действительно ново или отличается при установке в гостевой системе.
Этот обратный отсчет внизу стоит прочитать, а не игнорировать: если оставить меню без изменений, система не просто выберет выделенный вариант по умолчанию, а в конечном итоге запустит доступный путь установки синтезатора речи - это заметно иной процесс, построенный на звуковых подсказках, а не на привычных диалоговых окнах. Нажатие любой клавиши со стрелкой отменяет обратный отсчёт и позволяет намеренно выбрать обычный пункт «Установить».
Установите гостевую операционную систему
Язык, местоположение и раскладка клавиатуры повторяют настройки, выбранные во время самой установки Proxmox. Первый действительно новый запрос касается имени хоста; его следует установить так, чтобы оно совпадало с именем виртуальной машины в Proxmox, а не оставлять стандартный заполнитель Debian.
При настройке учетной записи пользователя без прав root возникает реальная ошибка проверки, о которой стоит знать заранее: некоторые имена пользователей зарезервированы самой системой и сразу отклоняются, как бы разумно они ни звучали.
Имя «operator» вступает в конфликт с реальной учетной записью Unix, которая исторически использовалась для системных операций, хотя на первый взгляд оно кажется вполне подходящим выбором для администратора платформы. «opsadmin» - то же имя, которое уже использовалось для учётной записи администратора Proxmox в предыдущем руководстве, - работает без конфликтов и обеспечивает единообразие именования между гипервизором и виртуальными машинами, работающими на нём.
Автоматическое разбиение на разделы с использованием всего виртуального диска позволяет получить реальную, работоспособную таблицу разделов без каких-либо ручных вычислений: корневая файловая система ext4, занимающая большую часть диска, и раздел подкачки, размер которого определяется объемом оперативной памяти самой виртуальной машины.
Прежде чем подтвердить действия на этом экране, убедитесь, что на виртуальной машине пока нет данных, которые стоит сохранить, поскольку при автоматическом разбиении на разделы весь виртуальный диск будет стёрт. Чтобы проверить, что именно будет отформатировано, на экране обзора перед началом записи отображается список всех разделов с указанием устройств и размеров.
Восстановление данных из поврежденного зеркала архива
Сразу после завершения установки базовой системы программа установки пытается подключиться через сеть к зеркалу пакетов Debian, чтобы настроить apt для дальнейшей установки. Эта проверка действительно может завершиться неудачей, и стоит узнать, как именно выглядит ошибка, а не предполагать, что система вышла из строя без возможности восстановления.
На реальном оборудовании это, как правило, указывает на какую-то проблему, связанную с путем выхода этой виртуальной машины в Интернет: DNS-сервер, доступ к которому из гостевой системы пока невозможен, правило брандмауэра, блокирующее исходящий HTTPS-трафик, или просто зеркало, которое временно перегружено и к которому стоит повторить попытку чуть позже. Поэтому, если вернуться и выбрать тот же зеркальный сервер, иногда со второго раза удается установить соединение именно по этой причине.
Когда установка постоянно завершается сбоем, сама программа установки предлагает реальный выход из ситуации, а не тупик: завершить установку вообще без использования сетевого зеркала.
Если здесь выбрать «Да», полнофункциональная установка будет заменена на рабочую: при последующем выборе программного обеспечения будут доступны только те компоненты, которые уже содержатся в образе netinst, при этом в списке не будет ни SSH-сервера, ни гостевого агента. Как только установленная система загрузится с реальным, работающим доступом к сети, обычная apt update перед хорошим зеркалом в /etc/apt/sources.list улавливает всё, что установщику пришлось пропустить.
Завершите установку и перезагрузите компьютер
При отсутствии зеркального образа при выборе задачи устанавливаются только стандартные системные утилиты, уже присутствующие в образе ISO, и программа установки переходит к записи GRUB на тот диск, на который она фактически была установлена, а не пытается угадать его.
Если программа установки, похоже, перестала отвечать буквально в самом конце - на этапе initramfs или окончательной очистки - обычно можно без опасений воспользоваться собственной кнопкой «Сброс» Proxmox, если диск уже разбит на разделы, а загрузчик записан. В ходе установки пакета ядра ранее уже был записан рабочий initramfs, поэтому сброс на этом позднем этапе всё равно приведёт к загрузке рабочей системы, а не к ситуации, из которой невозможно восстановить систему.
После этого перезагрузка происходит в реальной, установленной системе, а не в программе установки, и появление запроса на вход в систему служит подтверждением того, что весь процесс действительно привёл к созданию рабочей гостевой системы.
Убедитесь, что агент Guest Agent запущен
Простое отметка агента Qemu Agent на вкладке «Система» лишь сообщила Proxmox о необходимости наличия агента; без сетевого зеркала во время установки этот агент так и не был установлен в гостевой системе, как и сервер SSH. Обе задачи можно выполнить одной командой, как только гостевая система получит реальный доступ к Интернету, будь то исправленная /etc/apt/sources.list после сбоя зеркального сервера или при обычной установке, при которой доступ к сети был обеспечен с самого начала:
apt update
apt install -y qemu-guest-agent openssh-server
Как только этот агент запускается и отправляет отчет, на вкладке «Сводка» в Proxmox поле «IP-адреса» перестает отображаться пустым и начинает показывать реальный адрес, полученный изнутри гостевой системы, а не предполагаемый на основе данных сетевого уровня снаружи.
Эта же информация доступна через API, и именно её скрипт настройки будет запрашивать, вместо того чтобы ждать, пока кто-нибудь заглянет на вкладку «Сводка»:
curl -k "https://pve.example.com:8006/api2/json/nodes/pve/qemu/100/agent/network-get-interfaces" \
-H "Authorization: PVEAPIToken=opsadmin@pve!automation=<token-secret>"
В заключение
- Proxmox может самостоятельно загружать образы установщика через сеть, локальная загрузка не требуется.
- Восемь вкладок мастера создания виртуальной машины объединены в один вызов API, который полностью отображается на вкладке «Подтверждение».
- Неудачная проверка зеркал не обязательно должна привести к остановке установки - она лишь откладывает настройку apt до момента перезагрузки.
- После того как виртуальная машина получит доступ к реальной сети, необходимо отдельно установить агент-гость и сервер SSH.
В следующем руководстве вы привяжете к этой виртуальной машине маршрутизируемый IPv4-адрес и убедитесь, что она доступна из Интернета.