Ips гостевой агент не запущен

Обновлено: 15.01.2025

Я решил перевести заметку из proxmox wiki на тему рекомендаций по установке в качестве гостевой системы Windows 10. Там нет каких-то особых и критичных замечаний. Просто последовательно изложен порядок рекомендуемых действий и настроек для максимального быстродействия и стабильной работы системы.

Хочешь научиться автоматически разворачивать и поддерживать высоконагруженные проекты? Тогда рекомендую познакомиться с онлайн курсом " Infrastructure as a code." в OTUS. Актуально для системных администраторов и devops инженеров. Подробности по .

Введение

В данной статье будут даны общие рекомендации, так называемые best practices на тему установки Windows 10 или 11 на гипервизор Proxmox. Данное руководство можно использовать как how to для проверки себя во время настройки виртуальных машин.

Подготовка к установке

Для того, чтобы получить хорошее быстродействие операционной системы Windows на хосте Proxmox, мы установим Windows VirtIO Drivers во время установки VM.

Создайте новую виртуальную машину, выберите тип "Microsoft Windows 10/2016/2019" и активируйте функцию "Qemu Agent" на вкладке System. Далее укажите свой iso образ в качестве источника установки.
В качестве Bus/Device для виртуального диска укажите SCSI, контроллер должен быть VirtIO SCSI. Можете указать опцию кэширования Write back. Это увеличит быстродействие, но есть некоторые риски потери данных. Подробно про варианты кэширования я писал отдельно. Укажите параметр Discard для более эффективного использования места на диске. Этот параметр работает примерно так же, как технология TRIM в SSD дисках. Подчищает реально удаленные данные с диска, уменьшая занимаемое место.
Настройки памяти и процессора укажите в зависимости от потребностей виртуальной машины. Модель сетевой карты укажите VirtIO (paravirtualized).
Для того, чтобы во время установки системы использовать драйверы virtio, загрузите iso образ с ними. Добавьте новый CD-ROM к VM и подключите этот образ.
Теперь у вас всё готово для установки системы Windows.

Запуск установки Windows в Proxmox

После запуска установки системы, подключитесь к консоли виртуальной машины.
Дойдите до этапа установки, где нужно выбрать жёсткий диск. Скорее всего список доступных дисков будет пуст.
Нажмите "Загрузить драйвер" для того, чтобы установить драйвер жесткого диска и сетевой карты.
Для установки драйвер диска перейдите в директорию vioscsi\w10\amd64 и подтвердите выбор. Выберите "Red Hat VirtIO SCSI pass-through controller". Ваш виртуальный жёсткий диск должен появиться в списке для установки на него системы.
Повторите то же самое для выбора драйвера сетевой карты. Он находится в директории NetKVM\w10\amd64. Выберите "Redhat VirtIO Ethernet Adapter".
Драйвер выделения динамической оперативной памяти находится в Balloon\w10\amd64. Перейдите в эту директорию и выберите драйвер "VirtIO Balloon Driver".
Загрузка этих трёх драйверов позволит установщику Windows определить всё оборудование, так что можно продолжить установку системы в обычном режиме.

Подробно описанную процедуру можно лицезреть на видео на примере установки Windows Server 2016 на ProxMox. Установка Windows 10 или 11 будет проходить точно так же.

Загрузка драйвера Virtio во время установки Windows

Драйвер для Red Hat VirtIO SCSI pass-through controller

Установка Qemu Guest Agent на Windows

Для того, чтобы корректно работал Guest Agent на Windows, необходимо его установить отдельно. Он находит в iso образе virtio в корне диска, в папке guest-agent. Для x64 архитектуры установочный файл будет называться qemu-ga-x86_64.msi. Просто запустите установку и дождитесь окончания. Больше ничего делать не надо, агент автоматически установится и запустится.

Если всё прошло успешно, то вы сразу же в веб интерфейсе Proxmox увидите ip адреса на сетевых интерфейсах Windows.

Драйвера и Службы

Чтобы установить все недостающие драйвера для корректной работы Windows на Proxmox, запустите virtio-win-gt-x64.msi в корне диска virtio. Можете убрать установку тех драйверов и служб, что вы точно не будете использовать. Например, Qxl и Spice. После этого не только ip адреса, но и использования оперативной памяти должны корректно отображаться в веб интерфейсе.

Рекомендуется посмотреть менеджер устройств, чтобы убедиться в том, что там нет неопределённого оборудования. Если все драйверы установились корректно, то всё оборудование будет с драйверами и определено. Если это не так, то попробуйте установить драйвер устройства вручную. Для этого укажите в качестве источника драйвера виртуальный диск с virtio.iso и обязательно укажите использовать для поиска драйвера подпапки. Если драйвер будет найдет, то выберите его и установите, подтвердив, что доверяете установке драйверов от указанного поставщика.

Формат диска raw vs qcow2

Историю с выбором типа диска в proxmox я разбирал подробно в отдельной заметке. В общем случае формат raw обеспечивает лучшее быстродействие, но у qcow2 есть дополнительный полезный функционал. Речь идёт о технологии copy on write и возможности делать Live Snapshots. В настоящий момент формат qcow2 выбирается по умолчанию.

VirtIO drivers

Make it really easy: Build your ISO with drivers already included:

Можно достаточно просто подготовить свой образ операционной системы Windows с интегрированными VirtIO драйверами. Для этого можно можно воспользоваться отдельной статьёй - Windows guests - build ISOs including VirtIO drivers.

Windows Агент гостей Azure — это агент виртуальной машины (VM). Он позволяет VM взаимодействовать с контроллером ткани (физическим сервером, на котором находится VM) по IP-адресу 168.63.129.16. Это виртуальный общедоступный IP-адрес, который облегчает связь. Дополнительные сведения см. в том, что такое IP-адрес 168.63.129.16.

VM, переносимый в Azure из локального или созданного с помощью настраиваемого изображения, не имеет Windows агента azure guest. В этих сценариях необходимо вручную установить агент VM. Дополнительные сведения об установке агента виртуальной машины см. в обзоре агентов виртуальных машин Azure.

После Windows успешного установки гостевого агента Azure можно увидеть следующие службы, перечисленные в services.msc в VM:

Windows Служба гостевых агентов Azure
Служба телеметрии
Служба агентов RD

Windows Службы гостевых агентов Azure. Эта служба является службой, ответственной за все ведение журнала в WAppAgent.log. Эта служба отвечает за настройку различных расширений и связи от Гостевой до Хост.

Служба телеметрии. Эта служба отвечает за отправку телеметрии данных VM на сервер backend.

Служба агентов RD. Эта служба отвечает за установку агента-гостя. Прозрачный установщик также является компонентом агента Rd, который помогает обновить другие компоненты и службы гостевого агента. RDAgent также отвечает за отправку пульса из гостевого VM в host Agent на физическом сервере.

Начиная с версии 2.7.41491.971 гостевого агента VM, компонент телеметрии включен в службу RDAgent, поэтому эта служба телеметрии может не быть указана в вновь созданных VMs.

Проверка состояния агента и версии

Перейдите на страницу свойств VM на портале Azure и проверьте состояние агента. Если агент Windows Azure работает правильно, состояние показывает Ready. Если агент VM находится в состоянии Не готово, расширения и команда Run на портале Azure не будут работать.

Устранение неполадок с агентом VM, который находится в состоянии Not Ready

Шаг 1 Проверьте, установлена ли Windows служба гостевых агентов Azure

Найдите папку C:\WindowsAzure. Если вы видите папку GuestAgent, отображаемую номер версии, это означает, что Windows azure Guest Agent был установлен на VM. Вы также можете искать установленный пакет. Если Windows в VM установлен гостевой агент Azure, пакет будет сохранен в следующем расположении: C:\windows\OEM\GuestAgent\VMAgentPackage.zip .

Вы можете запустить следующую команду PowerShell, чтобы проверить, был ли VM Agent развернут в VM:

Get-AzVM -ResourceGroupName "RGNAME" -Name "VMNAME" -DisplayHint expand

В выходе найдите свойство ProvisionVMAgent и проверьте, установлено ли значение True. Если это так, это означает, что агент установлен на VM.

Проверка служб и процессов

Перейдите на консоль Services (services.msc) и проверьте состояние следующих служб: Windows Службы агентов для гостей Azure, службы RDAgent, Windows службы телеметрии Azure и службы сетевых агентов Windows Azure.

Вы также можете проверить, работают ли эти службы, изучив диспетчер задач для следующих процессов:

WindowsAzureGuestAgent.exe: Windows служба гостевых агентов Azure
WaAppAgent.exe: служба RDAgent
WindowsAzureNetAgent.exe: Windows службы сетевого агента Azure
WindowsAzureTelemetryService.exe: Windows служба телеметрии Azure

Если вы не можете найти эти процессы и службы, это указывает на то, что у вас нет Windows агента azure guest.

Проверка программы и функции

В панели управления перейдите к программам и функциям, чтобы определить, установлена ли Windows служба гостевых агентов Azure.

Если вы не находите запущенных пакетов, служб и процессов и даже не видите агента Windows Azure, установленного в рамках программ и функций, попробуйтеустановить службу Windows Azure Guest Agent . Если гостевой агент не установит должным образом, вы можете установить агент VM в автономном режиме.

Если вы видите службы и они запущены, перезапустите службу, которая увидит, устранена ли проблема. Если службы остановлены, запустите их и подождите несколько минут. Затем проверьте, сообщается ли состояние агента как Готово. Если эти службы сбои, некоторые сторонние процессы могут привести к сбою этих служб. Чтобы устранить эти проблемы, обратитесь в службу поддержки Майкрософт.

Шаг 2 Проверить, работает ли автоматическое обновление

Агент Windows Azure имеет функцию автоматического обновления. Он автоматически проверит новые обновления и установит их. Если функция автоматического обновления не работает правильно, попробуйте отстраить и установить агент Windows Azure с помощью следующих действий:

Если Windows в программах и функциях появится агент azure, удалить Windows azure Guest Agent.

Откройте окно Командная подсказка с привилегиями администратора.

Остановите службы гостевого агента. Если службы не останавливаются, необходимо настроить службы для ручного запуска и перезапустить VM.

Удаление служб гостевого агента:

В C:\WindowsAzure соответствии с созданием папки с именем OLD.

Перемещение любых папок с именем Пакеты или GuestAgent в старую папку.

Скачайте и установите последнюю версию пакета установки агента отсюда. Для завершения установки необходимо иметь права администратора.

Установите гостевой агент с помощью следующей команды:

Затем проверьте, правильно ли запускают службы гостевых агентов.

В редких случаях, когда гостевой агент не устанавливает правильно, можно установить агент VM в автономном режиме.

Шаг 3 Проверьте, можно ли VM подключиться к контроллеру fabric

Расширенные устранения неполадок

События для устранения неполадок Windows azure Guest Agent записывают в следующих файлах журнала:

C:\WindowsAzure\Logs\WaAppAgent.log
C:\WindowsAzure\Logs\TransparentInstaller.log

Ниже приводится ряд распространенных сценариев, в которых Windows azure Guest Agent может ввести состояние Не готово или перестать работать, как ожидалось.

Windows У VMs с агентом Azure VM версии 2.7.41491.1004 могут возникнуть проблемы с Sysprep

Запуск Sysprep.exe этих VMs может привести к указанным ниже ошибкам.

При первом запуске Sysprep вы увидите следующую ошибку:

АДМИНИСТРАТОР: Обработник ошибок

При запуске Sysprep несколько раз вы увидите следующую ошибку:

При попытке sysprep VM возникла роковая ошибка

Проблема только с версией 1004, поэтому вы можете попробовать обновление агента до последней версии агента, или вы можете попытаться модернизировать его до версии 1005 с помощью ниже MSI, у которого исправлена ошибка.

Кроме того, сначала сбросить состояние Sysprep для VM. Это состоит из изменения нескольких ключей реестра.

Агент Застрял на "Запуск"

В журнале WaAppAgent можно увидеть, что агент застрял в начальном процессе и не может запуститься.

Сведения журнала

[00000007] [05/28/2019 12:58:50.90] [INFO] Запуск WindowsAzureGuestAgent. Версия 2.7.41491.901

Анализ

VM по-прежнему работает в старой версии агента Windows Azure. В папке C:\WindowsAzure можно заметить, что Windows экземпляров гостевого агента Azure, включая несколько одинаковых версий. Так как установлено несколько экземпляров агентов, VM не запустит последнюю версию Windows Azure Guest Agent.

Решение

Вручную удалить агент Windows Azure, а затем переустановить его, следуя следующим шагам:

Откройте панель управления > программ и функций и разблокировать Windows Azure Guest Agent.

Откройте диспетчер задач и остановите следующие службы: Windows Службы агентов для гостей Azure, службы RDAgent, Windows службы телеметрии Azure и службы сетевых агентов Windows Azure.

В C:\WindowsAzure создайте папку с именем OLD.

Перемещение любых папок с именем Пакеты или GuestAgent в старую папку. Кроме того, переместите все папки GuestAgent в C:\WindowsAzure\logs, которые начинаются как GuestAgent_x.x.xxxxx в старую папку.

Скачайте и установите последнюю версию агента MSI. Для завершения установки необходимо иметь права администратора.

Установите гостевой агент с помощью следующей команды MSI:

Убедитесь, что службы RDAgent, Windows Azure и Windows службы телеметрии Azure запущены.

Проверьте систему WaAppAgent.log, чтобы убедиться, что работает последняя версия Windows Azure Guest Agent.

Удаление старой папки в C:\WindowsAzure.

Невозможно подключиться к IP-адресу WireServer (IP-адрес host)

Вы заметили следующие записи об ошибках в WaAppAgent.log и Telemetry.log:

Сведения журнала

Анализ

VM не может достичь хост-сервера wireserver.

Решение

Агент гостей застрял "Остановка"

Вы заметили следующие записи об ошибках в WaAppAgent.log:

Сведения журнала

Анализ

Windows Агент гостей Azure застрял в процессе остановки.

Решение

Убедитесь, что WaAppAgent.exe работает на VM. Если она не запущена, перезапустите службу rdgagent и подождите пять минут. Когда WaAppAgent.exe запущен, завершите WindowsAzureGuest.exe процесс.
Если шаг 1 не решает проблему, удалите установленную в настоящее время версию и установите последнюю версию агента вручную.

Адаптер Npcap Loopback

Вы заметили следующие записи об ошибках в WaAppAgent.log:

Анализ

Адаптер циклов Npcap устанавливается на VM wireshark. Wireshark — это средство с открытым исходным кодом для профилинга сетевого трафика и анализа пакетов. Такой инструмент часто называют сетевым анализатором, анализатором сетевых протоколов или снюхачом.

Решение

Адаптер Npcap Loopback, скорее всего, установлен WireShark. Попробуйте отключить его, а затем проверьте, устранена ли проблема.

Дальнейшие действия

Другие известные проблемы с агентом Windows Azure перечислены в репозитории Github.

Чтобы устранить проблему "Windows агент azure guest не работает", обратитесь в службу поддержки Майкрософт.

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

Proxmox кластер может состоять из двух и более серверов. Максимальное количество нод в кластере равняется 32 штукам. Наш собственный кластер будет состоять из трех нод на мультикасте (в статье я также опишу, как поднять кластер на уникасте — это важно, если вы базируете свою кластерную инфраструктуру на Hetzner или OVH, например). Коротко говоря, мультикаст позволяет осуществлять передачу данных одновременно на несколько нод. При мультикасте мы можем не задумываться о количестве нод в кластере (ориентируясь на ограничения выше).

Сам кластер строится на внутренней сети (важно, чтобы IP адреса были в одной подсети), у тех же Hetzner и OVH есть возможность объединять в кластер ноды в разных датацентрах с помощью технологии Virtual Switch (Hetzner) и vRack (OVH) — о Virtual Switch мы также поговорим в статье. Если ваш хостинг-провайдер не имеет похожие технологии в работе, то вы можете использовать OVS (Open Virtual Switch), которая нативно поддерживается Proxmox, или использовать VPN. Однако, я рекомендую в данном случае использовать именно юникаст с небольшим количеством нод — часто возникают ситуации, где кластер просто “разваливается” на основе такой сетевой инфраструктуры и его приходится восстанавливать. Поэтому я стараюсь использовать именно OVH и Hetzner в работе — подобных инцидентов наблюдал в меньшем количестве, но в первую очередь изучайте хостинг-провайдера, у которого будете размещаться: есть ли у него альтернативная технология, какие решения он предлагает, поддерживает ли мультикаст и так далее.

Установка Proxmox

Proxmox может быть установлен двумя способами: ISO-инсталлятор и установка через shell. Мы выбираем второй способ, поэтому установите Debian на сервер.

Перейдем непосредственно к установке Proxmox на каждый сервер. Установка предельно простая и описана в официальной документации здесь.

Добавим репозиторий Proxmox и ключ этого репозитория:

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

После успешного обновления установим необходимые пакеты Proxmox:

Заметка: во время установки будет настраиваться Postfix и grub — одна из них может завершиться с ошибкой. Возможно, это будет вызвано тем, что хостнейм не резолвится по имени. Отредактируйте hosts записи и выполните apt-get update

Изображение 1. Веб-интерфейс ноды Proxmox

Установка Nginx и Let’s Encrypt сертификата

Мне не очень нравится ситуация с сертификатом и IP адресом, поэтому я предлагаю установить Nginx и настроить Let’s Encrypt сертификат. Установку Nginx описывать не буду, оставлю лишь важные файлы для работы Let’s encrypt сертификата:

Команда для выпуска SSL сертификата:

Не забываем после установки SSL сертификата поставить его на автообновление через cron:

Заметка: чтобы отключить информационное окно о подписке, выполните данную команду:

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

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

Создадим сетевой мост для внутренней сети, чтобы наши виртуальные машины (в моем варианте будет LXC контейнер для удобства) во-первых, были подключены к внутренней сети гипервизора и могли взаимодействовать друг с другом. Во-вторых, чуть позже мы добавим мост для внешней сети, чтобы виртуальные машины имели свой внешний IP адрес. Соответственно, контейнеры будут на данный момент за NAT’ом у нас.

Работать с сетевой конфигурацией Proxmox можно двумя способами: через веб-интерфейс или через конфигурационный файл /etc/network/interfaces. В первом варианте вам потребуется перезагрузка сервера (или можно просто переименовать файл interfaces.new в interfaces и сделать перезапуск networking сервиса через systemd). Если вы только начинаете настройку и еще нет виртуальных машин или LXC контейнеров, то желательно перезапускать гипервизор после изменений.

Теперь создадим сетевой мост под названием vmbr1 во вкладке network в веб-панели Proxmox.

Изображение 2. Сетевые интерфейсы ноды proxmox1

Изображение 3. Создание сетевого моста

Изображение 4. Настройка сетевой конфигурации vmbr1

Настройка предельно простая — vmbr1 нам нужен для того, чтобы инстансы получали доступ в Интернет.

Теперь перезапускаем наш гипервизор и проверяем, создался ли интерфейс:

Изображение 5. Сетевой интерфейс vmbr1 в выводе команды ip a

Заметьте: у меня уже есть интерфейс ens19 — это интерфейс с внутренней сетью, на основе ее будет создан кластер.

Повторите данные этапы на остальных двух гипервизорах, после чего приступите к следующему шагу — подготовке кластера.

Также важный этап сейчас заключается во включении форвардинга пакетов — без нее инстансы не будут получать доступ к внешней сети. Открываем файл sysctl.conf и изменяем значение параметра net.ipv4.ip_forward на 1, после чего вводим следующую команду:

В выводе вы должны увидеть директиву net.ipv4.ip_forward (если не меняли ее до этого)

Настройка Proxmox кластера

Теперь перейдем непосредственно к кластеру. Каждая нода должна резолвить себя и другие ноды по внутренней сети, для этого требуется изменить значения в hosts записях следующих образом (на каждой ноде должна быть запись о других):

Также требуется добавить публичные ключи каждой ноды к остальным — это требуется для создания кластера.

Создадим кластер через веб-панель:

Изображение 6. Создание кластера через веб-интерфейс

После создания кластера нам необходимо получить информацию о нем. Переходим в ту же вкладку кластера и нажимаем кнопку “Join Information”:

Изображение 7. Информация о созданном кластере

Данная информация пригодится нам во время присоединения второй и третьей ноды в кластер. Подключаемся к второй ноде и во вкладке Cluster нажимаем кнопку “Join Cluster”:

Изображение 8. Подключение к кластеру ноды

Разберем подробнее параметры для подключения:

Peer Address: IP адрес первого сервера (к тому, к которому мы подключаемся)
Password: пароль первого сервера
Fingerprint: данное значение мы получаем из информации о кластере

Вторая нода успешно подключена! Однако, такое бывает не всегда. Если вы неправильно выполните шаги или возникнут сетевые проблемы, то присоединение в кластер будет провалено, а сам кластер будет “развален”. Лучшее решение — это отсоединить ноду от кластера, удалить на ней всю информацию о самом кластере, после чего сделать перезапуск сервера и проверить предыдущие шаги. Как же безопасно отключить ноду из кластера? Для начала удалим ее из кластера на первом сервере:

После чего нода будет отсоединена от кластера. Теперь переходим на сломанную ноду и отключаем на ней следующие сервисы:

Proxmox кластер хранит информацию о себе в sqlite базе, ее также необходимо очистить:

Данные о коросинке успешно удалены. Удалим оставшиеся файлы, для этого необходимо запустить кластерную файловую систему в standalone режиме:

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

Установка и настройка ZFS

ZFS — это файловая система, которая может использоваться совместно с Proxmox. С помощью нее можно позволить себе репликацию данных на другой гипервизор, миграцию виртуальной машины/LXC контейнера, доступ к LXC контейнеру с хост-системы и так далее. Установка ее достаточно простая, приступим к разбору. На моих серверах доступно три SSD диска, которые мы объединим в RAID массив.

Обновляем список пакетов:

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

Устанавливаем сам ZFS:

Если вы в будущем получите ошибку fusermount: fuse device not found, try ‘modprobe fuse’ first, то выполните следующую команду:

Теперь приступим непосредственно к настройке. Для начала нам требуется отформатировать SSD и настроить их через parted:

Аналогичные действия необходимо произвести и для других дисков. После того, как все диски подготовлены, приступаем к следующему шагу:

zpool create -f -o ashift=12 rpool /dev/sda4 /dev/sdb4 /dev/sdc4

Применим некоторые настройки для ZFS:

Теперь нам надо рассчитать некоторые переменные для вычисления zfs_arc_max, я это делаю следующим образом:

В данный момент пул успешно создан, также мы создали сабпул data. Проверить состояние вашего пула можно командой zpool status. Данное действие необходимо провести на всех гипервизорах, после чего приступить к следующему шагу.

Теперь добавим ZFS в Proxmox. Переходим в настройки датацентра (именно его, а не отдельной ноды) в раздел «Storage», кликаем на кнопку «Add» и выбираем опцию «ZFS», после чего мы увидим следующие параметры:

ID: Название стораджа. Я дал ему название local-zfs
ZFS Pool: Мы создали rpool/data, его и добавляем сюда.
Nodes: указываем все доступные ноды

Данная команда создает новый пул с выбранными нами дисками. На каждом гипервизоре должен появится новый storage под названием local-zfs, после чего вы сможете смигрировать свои виртуальные машины с локального storage на ZFS.

Репликация инстансов на соседний гипервизор

В кластере Proxmox есть возможность репликации данных с одного гипервизора на другой: данный вариант позволяет осуществлять переключение инстанса с одного сервера на другой. Данные будут актуальны на момент последней синхронизации — ее время можно выставить при создании репликации (стандартно ставится 15 минут). Существует два способа миграции инстанса на другую ноду Proxmox: ручной и автоматический. Давайте рассмотрим в первую очередь ручной вариант, а в конце я предоставлю вам Python скрипт, который позволит создавать виртуальную машину на доступном гипервизоре при недоступности одного из гипервизоров.

Для создания репликации необходимо перейти в веб-панель Proxmox и создать виртуальную машину или LXC контейнер. В предыдущих пунктах мы с вами настроили vmbr1 мост с NAT, что позволит нам выходить во внешнюю сеть. Я создам LXC контейнер с MySQL, Nginx и PHP-FPM с тестовым сайтом, чтобы проверить работу репликации. Ниже будет пошаговая инструкция.

Загружаем подходящий темплейт (переходим в storage —> Content —> Templates), пример на скриншоте:

Изображение 10. Local storage с шаблонами и образами ВМ

Нажимаем кнопку “Templates” и загружаем необходимый нам шаблон LXC контейнера:

Изображение 11. Выбор и загрузка шаблона

Теперь мы можем использовать его при создании новых LXC контейнеров. Выбираем первый гипервизор и нажимаем кнопку “Create CT” в правом верхнем углу: мы увидим панель создания нового инстанса. Этапы установки достаточно просты и я приведу лишь конфигурационный файл данного LXC контейнера:

Контейнер успешно создан. К LXC контейнерам можно подключаться через команду pct enter , я также перед установкой добавил SSH ключ гипервизора, чтобы подключаться напрямую через SSH (в PCT есть небольшие проблемы с отображением терминала). Я подготовил сервер и установил туда все необходимые серверные приложения, теперь можно перейти к созданию репликации.

Кликаем на LXC контейнер и переходим во вкладку “Replication”, где создаем параметр репликации с помощью кнопки “Add”:

Изображение 12. Создание репликации в интерфейсе Proxmox

Изображение 13. Окно создания Replication job

Я создал задачу реплицировать контейнер на вторую ноду, как видно на следующем скриншоте репликация прошла успешно — обращайте внимание на поле “Status”, она оповещает о статусе репликации, также стоит обращать внимание на поле “Duration”, чтобы знать, сколько длится репликация данных.

Изображение 14. Список синхронизаций ВМ

Теперь попробуем смигрировать машину на вторую ноду с помощью кнопки “Migrate”

Начнется миграция контейнера, лог можно просмотреть в списке задач — там будет наша миграция. После этого контейнер будет перемещен на вторую ноду.

Ошибка “Host Key Verification Failed”

Иногда при настройке кластера может возникать подобная проблема — она мешает мигрировать машины и создавать репликацию, что нивелирует преимущества кластерных решений. Для исправления этой ошибки удалите файл known_hosts и подключитесь по SSH к конфликтной ноде:

Примите Hostkey и попробуйте ввести эту команду, она должна подключить вас к серверу:

Особенности сетевых настроек на Hetzner

Переходим в панель Robot и нажимаем на кнопку “Virtual Switches”. На следующей странице вы увидите панель создания и управления интерфейсов Virtual Switch: для начала его необходимо создать, а после “подключить” выделенные сервера к нему. В поиске добавляем необходимые сервера для подключения — их не не нужно перезагружать, только придется подождать до 10-15 минут, когда подключение к Virtual Switch будет активно.

После добавления серверов в Virtual Switch через веб-панель подключаемся к серверам и открываем конфигурационные файлы сетевых интерфейсов, где создаем новый сетевой интерфейс:

Давайте разберем подробнее, что это такое. По своей сути — это VLAN, который подключается к единственному физическому интерфейсу под названием enp4s0 (он у вас может отличаться), с указанием номера VLAN — это номер Virtual Switch’a, который вы создавали в веб-панели Hetzner Robot. Адрес можете указать любой, главное, чтобы он был локальный.

Отмечу, что конфигурировать enp4s0 следует как обычно, по сути он должен содержать внешний IP адрес, который был выдан вашему физическому серверу. Повторите данные шаги на других гипервизорах, после чего перезагрузите на них networking сервис, сделайте пинг до соседней ноды по IP адресу Virtual Switch. Если пинг прошел успешно, то вы успешно установили соединение между серверами по Virtual Switch.

Я также приложу конфигурационный файл sysctl.conf, он понадобится, если у вас будут проблемы с форвардингом пакетом и прочими сетевыми параметрами:

Добавление IPv4 подсети в Hetzner

Перед началом работ вам необходимо заказать подсеть в Hetzner, сделать это можно через панель Robot.

Создадим сетевой мост с адресом, который будет из этой подсети. Пример конфигурации:

Теперь переходим в настройки виртуальной машины в Proxmox и создаем новый сетевой интерфейс, который будет прикреплен к мосту vmbr2. Я использую LXC контейнер, его конфигурацию можно изменять сразу же в Proxmox. Итоговая конфигурация для Debian:

Обратите внимание: я указал 26 маску, а не 29 — это требуется для того, чтобы сеть на виртуальной машине работала.

Добавление IPv4 адреса в Hetzner

Ситуация с одиночным IP адресом отличается — обычно Hetzner дает нам дополнительный адрес из подсети сервера. Это означает, что вместо vmbr2 нам требуется использоваться vmbr0, но на данный момент его у нас нет. Суть в том, что vmbr0 должен содержать IP адрес железного сервера (то есть использовать тот адрес, который использовал физический сетевой интерфейс enp2s0). Адрес необходимо переместить на vmbr0, для этого подойдет следующая конфигурация (советую заказать KVM, чтобы в случае чего возобновить работу сети):

Перезапустите сервер, если это возможно (если нет, перезапустите сервис networking), после чего проверьте сетевые интерфейсы через ip a:

Как здесь видно, enp2s0 подключен к vmbr0 и не имеет IP адрес, так как он был переназначен на vmbr0.

Теперь в настройках виртуальной машины добавляем сетевой интерфейс, который будет подключен к vmbr0. В качестве gateway укажите адрес, прикрепленный к vmbr0.

В завершении

Надеюсь, что данная статья пригодится вам, когда вы будете настраивать Proxmox кластер в Hetzner. Если позволит время, то я расширю статью и добавлю инструкцию для OVH — там тоже не все очевидно, как кажется на первый взгляд. Материал получился достаточно объемным, если найдете ошибки, то, пожалуйста, напишите в комментарии, я их исправлю. Всем спасибо за уделенное внимание.

Автор: Илья Андреев, под редакцией Алексея Жадан и команды «Лайв Линукс»

Этот вопрос относится к большей части обсуждения в том, что связано выше, однако в настоящее время у меня есть очень конкретный вопрос, который, я думаю, стоит выделить.

Версия упаковщика:

Строитель: proxmox

Версия Proxmox:

Я пытаюсь запустить сборку Packer с помощью ubuntu-20.04-live-server-amd64.iso, но когда boot_command запускает сборку, сборка просто зависает в ожидании подключения SSH к запущенному экземпляру. По достижении ssh_timeout сборка завершается ошибкой, и виртуальная машина уничтожается.

Журнал Packer сообщает, что адрес SSH не может быть получен, поскольку гостевой агент QEMU не запущен. Ясно, что на свежий ISO не устанавливается. Я также установил коммуникатор на ssh, отключил qemu_agent и настроил альтернативный ssh_port, поэтому я не уверен, почему это происходит?

журнал упаковщика:

Из связанной темы:

Новый установщик Ubuntu Server запускает SSH-сервер.
Учетные данные установщика:
Packer ошибочно пытается подключиться к этому SSH, думая, что виртуальная машина готова к дальнейшим действиям по обеспечению, а это НЕ.

Благодаря @JulyIghor мы нашли обходной путь.
Мы просто меняем порт, который упаковщик ожидает от ssh-сервера, на что-то еще, И во время cloud-init late_commands мы соответственно переопределяем порт сервера. Таким образом, после того, как cloud-init завершит работу и перезагрузит виртуальную машину, ssh-сервер будет работать на новом порте - теперь упаковщик улавливает это и продолжает подготовку, как мы привыкли.
В качестве последнего шага во время подготовки мы удаляем файл conf, по сути сбрасывая порт ssh-сервера на значение по умолчанию 22.

Я пробовал использовать другой ssh_port (2222 в приведенном ниже примере), но это не помогло.

Для полноты, команда boot_command действительно приводит к тому, что вновь запущенная виртуальная машина входит в правильный процесс автоматической установки (а не в стандартный диалог установки), о чем свидетельствуют следующие снимки экрана, сделанные во время отладочной сборки Packer:

Я скопировал полный файл сборки Packer и данные пользователя ниже.

Любые рекомендации о том, как гарантировать, что сборка Packer использует ssh, а не агент qemu, будут очень признательны (или что-то еще, что, по вашему мнению, может быть виновником).

Читайте также: