Proxmox — яркий представитель систем, которые при должной настройке работают годами без перерыва. Максимальный аптайм моих серверов уже превысил три года — и это не предел. Да, он не идеален и до сих пор у него были недостатки, с которыми приходилось мириться. А вот недавно на официальном форуме была опубликована альфа-версия новой системы управления Proxmox Datacenter Manager — должно помочь! Что же это за софт? Давайте разбираться.
Перед тем как начнем — короткая справка для тех, кто Proxmox ни разу не использовал. Это система виртуализации с открытым исходным кодом, построенная на базе Debian GNU Linux. В составе KVM для традиционной виртуализации и LXC для контейнеров. Раньше применялся OpenVZ, но это было достаточно давно и вызывало приличное количество проблем.
Запустить Proxmox можно двумя способами. Первый — взять готовый образ с официального сайта и установить в качестве основной операционной системы на сервер. Там все заранее настроено, так что такой способ будет самым простым. После завершения установки и перезагрузки станет доступен веб-интерфейс управления (ну или API, если вы решили интегрировать его с собственными системами). Еще им можно рулить из локальной консоли и через SSH.
Второй способ чуть сложнее. Proxmox устанавливается на любой сервер с Debian. При этом систему стоит предварительно подготовить. Среди многих сисадминов именно второй способ считается предпочтительным, но на практике они оба работают хорошо. Просто с готовым образом чуть меньше вариантов свободы действий.
Кластер или не кластер
Обычно у пользователей одного сервера Proxmox никогда не возникает лишних вопросов по управлению. Зашли в веб-интерфейс или по SSH, сделали что нужно и отключились. Но как только вы обзаводитесь двумя нодами, то кажется, что теперь возможностей по управлению должно стать больше. Например, хочется организовать миграцию виртуальных машин или делать бэкап на соседний узел. Да и управлять ими желательно из одного веб-интерфейса.
Все это возможно, когда ноды объединены в кластер, но есть одна неочевидная проблема. Для создания кластера используется система управления сообщениями corosync. В его составе есть очень важная служба votequorum, задача которой — подсчитывать «голоса» работающих узлов и определение наличия кворума. К тому же в ее обязанности входит предотвращение split-brain. Это когда часть узлов может отделиться от кластера и образовать собственные подкластеры, каждый из которых будет себя считать единственным. Такой ситуации нужно всячески избегать.
Еще votequorum решает вопросы пограничных случаев, например, когда количество узлов равно двум. Это особый режим работы, ведь формально кворум достигается только если обе ноды онлайн. Получается, что если любая из двух нод отключится, то и кворум будет потерян. Поэтому votequorum имеет особую настройку в случае с двумя нодами: она всегда принудительно сообщает corosync, что кворум есть. Казалось бы, это решает проблему, но на практике без третьего узла система не может надежно определить, какому из серверов передать управление в случае сбоя.
Поэтому, если вы планируете создавать кластер, он должен содержать в себе минимум три узла в одном сегменте сети, а это не всегда достижимо. Часто есть ситуации, когда имеется много одиночных узлов, которыми хочется управлять из одной точки, без необходимости включения их в кластер. До недавнего времени это было невозможно штатными средствами, но теперь есть решение — Proxmox Datacenter Management.
Установка и добавление узла
Proxmox Datacenter Management на момент написания этого текста находится в альфа-версии. Разработчики собрали загрузочный ISO-образ proxmox-datacenter-manager_0.1-ALPHA-1.iso, основанный на базе Debian Bookworm (12.8) с ядром Linux версии 6.8.12-5. Инсталлятор там точно такой же, как и в обычном Proxmox. После завершения установки и перезагрузки становится доступным веб-интерфейс по адресу:
https://[server_ip_address]:8443
Пусть вас не пугает надпись No valid subscription. Proxmox не ограничивает возможности системы виртуализации при этом. Просто своеобразное напоминание о том, что вы можете приобрести у них платную подписку на техническую поддержку и обновляться из Enterprise-репозитория. Пришла пора добавить первый Remote-сервер с помощью нажатия кнопки Add в соответствующем виджете.
Сам процесс добавления узла не слишком сложный. Он разбит на три части. Первая требует указания IP-адреса и «отпечатка пальца» (fingerprint) сервера. Посмотреть его можно непосредственно через веб-интерфейс добавляемого узла. Выберите имя узла — System — Certificates и дважды щелкните на самоподписанный сертификат для SSL (pve-ssl.pem). Откроется окно, в котором будет искомая строка:
Скопируйте это значение и вставьте его в соответствующее поле Proxmox Datacenter Manager. После этого нажмите кнопку Connect и дождитесь появления надписи Connection OK:
Теперь станет доступна кнопка Next — раньше она была неактивна. Она нужна для перехода в следующее окно ввода данных. Здесь нужно выбрать способ авторизации, ввести реквизиты доступа и имя подключаемого сервера, а потом нажать на кнопку Scan для проверки.
Если все данные введены правильно, появится надпись Scan OK, а кнопка Next позволит перейти в следующее окно:
Здесь можно добавить еще узлы или даже целые кластеры:
После завершения процесса добавленный узел будет отображен в главном меню. Вы увидите его дашборд, словно находитесь в его собственном веб-интерфейсе:
Миграция между нодами
Давайте посмотрим на самую востребованную функцию, которая обычно работает только в кластере — миграцию виртуальных машин. Для этого мы добавим в интерфейс вторую ноду (node2) и перенесем машину с одного узла на другой. Вне кластера такое раньше делалось только с помощью «костылей». На втором узле создавалась пустая виртуальная машина с точно такими же характеристиками и разово запускалась или останавливалась для того, чтобы Proxmox создал пустой файл жесткого диска.
Потом нужно было каким-либо способом снять образ накопителя виртуальной машины и перенести на другой узел взамен пустого у новой ВМ. Только теперь можно было останавливать машину на первом узле и стартовать ее на втором. Не самый удобный, но вполне рабочий способ переноса. Теперь же, с помощью Proxmox Datacenter Manager, это делается значительно проще.
Выберите узел, с которого нужно перенести виртуальную машину. Напротив нужной есть кнопка с пиктограммой бумажного самолетика. Откроется окно, в котором можно выбрать необходимые параметры. Для примера выполним миграцию с node1 на node2. Выберите node2 в качестве Target Remote, проверьте, что в Target Storage достаточно места, и нажмите кнопку Migrate:
Спустя несколько секунд начнется процесс создания новой виртуальной машины и копирование данных на другой узел:
Когда задание будет завершено, вы увидите надпись TASK OK:
Виртуальная машина была успешно запущена на node2. Тем же образом можно переносить и LXC-контейнеры:
Что в итоге
Proxmox Datacenter Manager демонстрирует отличный потенциал даже в самой сырой альфа-версии. Пройдет еще немало времени, прежде чем она выйдет в релиз. Управлять разрозненными нодами и кластерами станет значительно проще. Также это позволит в реальном времени отслеживать нагрузку на них и без проблем переносить машины и контейнеры с одного узла на другой.
По мере развития этот продукт будет наполняться новыми функциями и улучшениями. Именно такой вывод можно сделать из опубликованного роадмапа. Но уже сейчас очевидно, что он будет полезным инструментом для системных администраторов, управляющих разношерстным парком узлов виртуализации.
Надеюсь, уже скоро этот софт станет такой же неотъемлемой частью экосистемы Proxmox, как в свое время стал Proxmox Backup Server. Ну а приверженность разработчиков к миру программного обеспечения с открытым исходным кодом позволит пользоваться этим продуктом всем желающим.
А вы уже попробовали новинку? Ждем вас в комментариях.
Комментарии (44)
werter_l
13.01.2025 10:33Вдруг, кому пригодится
https://forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-%D0%B8-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5-%D1%87%D0%B0%D1%81%D1%82%D1%8C-2
YaKrabik
13.01.2025 10:33Я не вижу никакой разницы с VE. Там и раньше можно было создавать кластеры и перемещать машинки между ними. И окна абсолютно такие же при этом появляются.
DM -- это VE с вырезанным функционалом управления машинами?
ereinion
13.01.2025 10:33Это надстройка над PVE, которая позволяет получить единый интерфейс управления несколькими кластерами или отдельными серверами. Ключевое - не требуется собирать стоящие в сильно разных местах инсталляции в единый кластер.
vvzvlad
13.01.2025 10:33Кластер требует кворума, и если там например 2-3 машины, да еще и через интернет соединенные, то легко получить ситуацию, когда линк потерялся, кворума нет, и все, даже в GUI не зайти, заходи по ссаш и чини кластер. А на больших инсталляциях ощутимый трафик по синхронизации состояния кластера(разработчики предполагают, что сервера кластера у вас стоит в одном месте и связан быстрыми короткими линками). А дает он при этом не так уж и много, единый интерфейс, миграцию и HA. И если нет нужды в HA, то вот такой интерфейс удобнее кластера.
zatorax
13.01.2025 10:33Это не правда. Даже если кворума нет, то гуи продолжает работать, вм тоже. Единственное что нельзя сделать, это запустить vm, потому что кластер "не знает" какие vm на других нодах.
Это можно решить вручную, отправив команду от рута pvecm e 1
Консоль ноды есть в веб интерфейсе, по ssh я туда вообще перестал ходить, после того как веб терминал допили и там стала работать мышка и копипаст
vvzvlad
13.01.2025 10:33Это не правда. Даже если кворума нет, то гуи продолжает работать,
Правда. Для логина требуется кворум: "Yes. You need quorum to log into the GUI"
cjmaxik
13.01.2025 10:33Буквально вчера заходил на развалившийся кластер. В GUI входит, а вот в терминал уже нет, только через SSH.
vvzvlad
13.01.2025 10:33У меня не заходил, login failed. Возможно, зависит от версии. Возможно, вы заходили в ту часть, где кворум оставался, а я заходил на ноду, которая осталась в одиночестве.
leonP4
13.01.2025 10:33Автору топика: Спасибо за публикацию! Пропустил как-то информацию о выпуске такого важного продукта.
Подскажите, как вы считаете, данный центр имеет смысл разворачивать при наличии одного кластера? Интересно послушать разные точки зрения.Другой вопрос направлен vvzvlad. Предположим есть десяток кластеров, они разнесены между собой через интернет сеть. С помощью нового центра их можно вместе объединить, но встает вопрос, на каком кластере размещать этот Центр? Предположим случится так что потеряется доступ между несколькими кластерами, а на одном из них был установлен Центр. Доступ к центру тоже потерян. При таком сценарии потребуется разворачивать Центр в каждом кластере с балансировкой? Просто вашему сценарию с подключением по интернету чего-то не хватает, ведь проблема появится в том что с недоступностью линка у конкретного кластера теряется и доступ к его узлам, следовательно и к центру, который мог бы на нем находиться. Продолжая логическую цепочку можно предположить и развернуть Центр на всех кластерах, но стоит ли? Задумывался ли такой подход разработчиками? На мой взгляд - маловероятно.
Буду рад прочесть ваши ответы.
UPD: Нашел ответ на свой вопрос в дорожной карте!
— " Evaluate if an active-standby like architecture for the Proxmox Datacenter Manager makes sense, to have a native method to avoid a single point of failure.User can just use two Proxmox Datacenter Manager instances for now, metrics collection is doubled, but besides that, it's not much extra overhead."
https://pve.proxmox.com/wiki/Proxmox_Datacenter_Manager_Roadmap
То есть они тоже рассуждают над единой точкой отказа. Возможно это стоит включить в статью, это поднимет понимание людей в самой идеи развертывания центра на каждом кластере.vvzvlad
13.01.2025 10:33Предположим есть десяток кластеров, они разнесены между собой через интернет сеть. С помощью нового центра их можно вместе объединить, но встает вопрос, на каком кластере размещать этот Центр? Предположим случится так что потеряется доступ между несколькими кластерами, а на одном из них был установлен Центр. Доступ к центру тоже потерян. При таком сценарии потребуется разворачивать Центр в каждом кластере с балансировкой? Просто вашему сценарию с подключением по интернету чего-то не хватает, ведь проблема появится в том что с недоступностью линка у конкретного кластера теряется и доступ к его узлам, следовательно и к центру, который мог бы на нем находиться. Продолжая логическую цепочку можно предположить и развернуть Центр на всех кластерах, но стоит ли? Задумывался ли такой подход разработчиками? На мой взгляд - маловероятно.
Хз, я центр-то не ставил, я о нем в статье узнал. Плясать надо от того, что именно надо от конкретной инсталляции. Собирать кластеры не с выделенным линком через сети общего пользования — это плохая идея, не для продакшена, опять РКН сломает что-нибудь, и весь кластер встанет. Центр эту проблему решает, дает возможность управлять нодами и мигрировать виртуалки, не требуя взамен кворума.
Мне кажется, этот датацентр достаточно поставить в одном экземпляре. Он все равно просто удобный способ управления отдельными нодами или кластерами, не несет каких-то критичных фич, и если доступ к одной ноде потерян, то его все равно придется чинить, а если во время этого срочно потребовалось остановить виртуалку, то панель управления проксмоксом никуда не делась.
Rekken
13.01.2025 10:33Максимальный аптайм моих серверов уже превысил три года
У меня для вас плохие новости - обновлять ядро с перезагрузкой системы стоило бы чуть почаще.
sukharichev
13.01.2025 10:33За это время я не помню ни одной RCE именно в ядре, так что для домашней лабы, или даже прода в малом\среднем бизнесе вполне допустимо.
DaemonGloom
13.01.2025 10:33Всевозможные дыры в процессорах и их митигация - тоже завязаны на перезагрузку.
И да, RCE в ядре тоже было порядочно. Например, https://soc.cyber.wa.gov.au/advisories/20240624001-Linux-Kernel-ICMPv6-Router-RCE-Vulnerability/ . Гугл по запросу "linux kernel rce" много интересного выдаст.
dtmse
13.01.2025 10:33Миграция виртуальных машин "на живую" (без прерывания работы) поддерживается?
YaKrabik
13.01.2025 10:33да. мы как-то софтовый роутер переносили. простой меньше секунды оказался (по версии проксмоса что-то по типу 300мс)
vvzvlad
13.01.2025 10:33Ага, а реальный простой больше, потому что роутеру требуется время, чтобы перестроить таблицу ARP, когда ему не ответит прошлый сервер. По моим экспериментам — от 2 до 5 секунд. Ну, т.е. да, с точки зрения ВМ ее на 300мс заморозили. Но плюс к этому соединиться ни с кем она не могла в течении 4 секунд.
zatorax
13.01.2025 10:33Живая миграция там столько сколько я его помню. Вообще это ключевая фишка любого кластера. Есть даунтайм в момент переключения в пару микросекунд, но это вообще не заметно. Мигрировали в том числе и СУБД, все прекрасно работает
falcon4fun
13.01.2025 10:33Люблю, когда люди кичатся своими пиписьками, ой, аптаймами по 3-5 лет.
Сразу видно, что: апдейтов фирмвар: ipmi, bios, диски, рейд контроллер, сетевухи, бекплейн, psu (и куча других) за это время не было. Апдейтов гипервизора за эти годы не было. Дрова никто не обновлял. Тестирования фейловера кластера за эти годы не было. Даже банальные действия, вроде апдейта сервера Veeam легко требуют ребута нод.
sukharichev
13.01.2025 10:33я как раз вчера проводил ревизию прошивок своих супермайкр, схд dell и ни в одном из девайсов не исправляли ничего такого, что требовало бы обновления. Бездумное обновление всего подряд без оснований - такая же нелепость как "работает - не трогай"
falcon4fun
13.01.2025 10:33Что в MSA, что в ME, что в Компелленте, что в Rxxx каждый год фиксилось огромное количество проблем, большинство из которых даже не будет указано в патчноуте.
Во всех последних биосах делл 12-14 серии была гора обновлений и лишь один отозвали по причине кривого серта секьюрбута. Как минимум изменения связанные с микрокодом и обновлением PPR (post package repair) логики. Ну и как минимум вышла 2025 винда.
А после "зачем обновлять, ничего же не пофиксили", я примерно и получил десяток шкафов. Привет разным версиям фв, железа, тонне непонятных глюков и косяков. Особенный пламенный привет. Компелентам, которые никто не обновил за 6 лет, чтобы пофиксить детские болячки, залипшие снапшоты (которые видны только из снмп) и прочее прочее. Разные версии винды, обычно не обновленные с запуска (работает ж)
А потом народ сидит, ждет и дожидается очередного бага на 32768 часов с потерей всех данных.
З.Ы. по классике: с таким же успехом советую не обновлять Винду. "В патчноутах ничего интересного нету". А потом выясняется, что перелопатили весь RCT и не указали в патч ноуте ничего про это и также пофиксили миллион багов.
sukharichev
13.01.2025 10:33А потом народ сидит, ждет и дожидается очередного бага на 32768 часов с потерей всех данных
Это вы про знаменитую фигню с дисками HP\Seagate?
А разве прошивка с исправлением выходила ДО катастрофы? У меня, к счастью ни HP ни Seagate не было и нет, поэтому я подробно не следил, но мне кажется, исправили это уже только по факту, разве нет?
Ну и это, в целом-то не передергивайте, одно дело не обновлять винду с пользователями, а другое - гипервизор с единственным патчнотом в котором поправили неведомую фигню, которая у тебя вообще выключена.DaemonGloom
13.01.2025 10:33Прошивка выходила после начала катастрофы. Но избежать проблемы у себя вы вполне могли, если конкретно ваши диски столько не наработали.
И да, у гипервизоров тоже периодически находят уязвимости, дающие побег из виртуалки.
sukharichev
13.01.2025 10:33Не просто периодически, а прям часто последнее время, но в модели угроз малого\среднего бизнеса это не очень существенно, Кто там из мамкиных кулхацкеров будет эксплуатировать эфемерные RowHammer\Spectre и т. п., когда есть mimikatz, уязвимости обхода аутентификации и т. п., ближе, проще, вкуснее.
Патчится, несомненно надо, всегда когда можно. Но иногда нельзя, или можно, но не сразу. И сначала надо потестить, почитать релизы. И ко многим из патчей прямо пишут "Если у вас нет конкретной проблемы, которую решает этот патч, не ставьте". И разумеется нормальный админ между риском нетестированного апдейта и фейла всей инфраструктуры и гипотетической эксплуатации уязвимости выберет подождать и потерпеть второй риск.falcon4fun
13.01.2025 10:33Другой вопрос: что для вас малый и средний бизнес? Это в каких числах физических серваков и ВМок?
У меня только клиенских виртуалок будет под 1к штук. Разношерстных. И больше половины мы не админим, что там внутри: в душе не знаем. (: Не говоря уже про свою внутреннюю инфру.
И автоматом встаёт проблема: да, можно не обновлять. Можно даже на старом типе гипервизора сидеть, если хочется. До момента, пока все дружно не обосрутся и рансомвара в гости не забежит :) 99,9% апдейтов проходят без каких либо проблем. Обычно обосраться можно на кривоте своих рук: например, весело порой бывает обновлять FW сервака через примаунченный ISOшник, когда выкинуло из сессии, а потом бежать за новой мамкой, т.к. идрак больше ни алё :)
Ну и по классике: за раз никто не заставляет натягивать апдейты на всю инфру :)
гипервизор с единственным патчнотом в котором поправили неведомую фигню, которая у тебя вообще выключена
Этого даже в патчноуте не пишут. Например, Вим + Майки поправили давний баг 5 летней давности, тянущийся 5 лет в одном из патчей. В патчноуте есть? Да хер там плавал. Уже 500 страниц накапало: https://forums.veeam.com/microsoft-hyper-v-f25/windows-server-2019-hyper-v-vm-i-o-performance-problem-t62112.html
Плюс: Со времен 2012r2 пропал уже рекомендуемый список патчей под Hyper-V и страничка с ними. ESXi тоже после выкупа Броадкакашкой стал рандомным в плане кач-ва патчей. Как некоторый фирмвары: привет Intel X710.
"Если у вас нет конкретной проблемы, которую решает этот патч, не ставьте"
У Делла большинство патчей критикал-ургент-update_at_your_earliest_convenience :D Ну и прю любом косяке суппорт успешно пинает на тему: сходи, обновись, потом приходи.
между риском нетестированного апдейта
Тогда вам нужен миррор прод. среды на том же железе. Вот только очень сильно сомневаюсь, что там, где возникает вопрос "обновлять или нет" - есть такая тест среда. Чуть дороговато встают AFA СХД с 3-4 фуллпак гипервизорами :)
подождать и потерпеть второй риск
Пока CISO не знает о серьёзности риска :D
Подытожу:
Гипервизор. Раз в 3-6 месяцев можно накатить патчей, почитав отзывов и собрав статистику (привет реддиту), особенно если fault tolerance кластера под 33-50%. Апдейты, как железу, так ОСи. Лишний раз сбросить счетчик ECC и прогнать PPR колдбутом: привет "The self-heal operation successfully completed at DIMM DIMM_A12"
-
Сторадж. Раз в год спокойно можно сделать тоже самое, особенно, если есть куда скинуть данные временно. Как раз потестить фейловер голов. Видел я, как после долгого аптайма успешно ребутится NetApp, теряя коннект между менеджмент процессором и сервис процессором. Успешно считает, что батарейки больше нет и ребутится через 24 часа таймера, больше не поднимаясь :) А дальше начинается веселье в поисках батареек и мольбы, чтобы второй контроллер не ушел в ребут в тоже время :)
Плюс это добавляет информации, что оно всё еще работает и седалище не сожмется в сверхновую, как ребут чего-то с аптаймом в 5-6-7 лет. Т.к. того, кто запускал это всё чудо уже может и в живых не быть :D Т.к. немного отличается падение, когда ты сделал бэкапы, перетащил данные и подготовился, чем когда оно немножко упало и не поднялось. Лучше, чтобы в критическом случае оно само всё заведлось и мне не пришлось запускать что-то пинками, потому что банально сдохла батарейка стораджа и оно отказывается бутится (привет EqualLogic-ам с их батарейками со "сроком годности в Н лет". Клёвая была идея)
Просто серваки с ОСью: вполне успешно пушатся апдейты раз в месяц.
vasiliev-s
13.01.2025 10:33Надеюсь, в pdm реализуют миграцию с hyper-v в proxmox.
Dorlas
13.01.2025 10:33Думаю, быстрее в StarWind V2V Converter мы такую фичу увидим, чем в PDM/PVE....
А судя по этой статье и скриншотам - уже есть: https://www.starwindsoftware.com/blog/starwind-v2v-converteroverview-part-3-converting-vms-to-and-from-proxmox/
zatorax
13.01.2025 10:33Коллега, очень много неточностей, вам надо больше поработать с proxmox. Процесс переноса vm прям чудовищно описан. Вообще никто так не делает. Да и не думаю что много кто по ssh работает с виртуализацией, у proxmox прекрасный веб интерфейс и о боже, он может мигрировать vm даже если у хостов нет общего хранилища. Дико медленно, по ssh но может
vvzvlad
13.01.2025 10:33и о боже, он может мигрировать vm даже если у хостов нет общего хранилища
Между нодами не в кластере? :)
AntonSurikov
13.01.2025 10:33Есть опыт работы с Proxmox и Vmmanager. И то, и то в целом норм. Но для меня Proxmox уступает открытым кодом и недоработками интерфейса, у vmmanager свой закрытый код - это безопаснее и интерфейс удобный и понятный. А так потенциал хороший у обеих СВ.
vvzvlad
13.01.2025 10:33vmmanager свой закрытый код - это безопаснее
Чем?
AntonSurikov
13.01.2025 10:33Тем, что опенсорс продукт сильно уязвимие. Туда непонятно кто и непонятно что напихать может. Как по мне лучше брать проприетарный продукт, который вендор не бросит внезапно. Решение опенсорс как бы тоже должен поддерживать вендор, но как показывает практика, он в любой момент может бросить свой продукт. Например, Redhat вышел из проекта ovirt, и что там дальше будет с продуктом - большииииие вопросики. Про историю с отстранением разработчиков от ядра Линукс вообще молчу, очень показательно все. Мне так рисковать не хочется совсем.
Pinkbyte
13.01.2025 10:33Как по мне лучше брать проприетарный продукт, который вендор не бросит внезапноА как вы собираетесь это понять, что не бросит внезапно или не сменит политику лицензирования так, что многие побегут от такого вендора куда угодно(привет Broadcom)?
sunfixer
13.01.2025 10:33VE миграцию без проблем поддерживает, уже давно. Если нет общего сториджа, копирует тачку на другую ноду целиком, если есть - тогда мету тачки копирует, жёсткий виртуалки остаётся на месте, при миграции даже пинг не пропадет.
vasilisc
13.01.2025 10:33PVE нужно периодически обновлять. В кластере с единым хранилищем легко и просто ВМ перегонять с ноды на ноду в online режиме (Live Migration) и осуществлять плановые работы, в том числе обновление серверов один за другим.
vladimirkhazov
13.01.2025 10:33Зачем все эти танцы с бубном, когда есть православные zvirt и vmmanager. первый больше понта за много денех, второй меньше возможностей за норм прайс. а городить сейчас что-то на опенсорсе - моветон, схлопнется - концов будет не найти
ereinion
С подачи одного из друзей, приближенных к вендору использую PDM в домашней лабе (2 сервера PVE в отдельных сетях - один для домашних сервисов, другой - песочница). Да, пока сыроват интерфейс и не хватает фич, кривовато отображается статистика. Но потенциал заметен, и главное - миграция работает как часы.