pve8to9 ругается на old machine version: почему сменить тип машины мало и что будет со старыми снимками

Вы запустили pve8to9 перед переездом на Proxmox VE 9 и получили список ID виртуалок с «old machine version». Первая мысль — поправить тип машины в вебморде и забыть. Так делать нельзя: предупреждений там на самом деле четыре, они про разные вещи, и ровно одно из них лечится правкой конфига. Остальные три — про уже записанное на диск состояние, в котором версия машины зашита навсегда. Ниже — что именно проверяет скрипт, откуда взялся рубеж 6.0, почему у половины Windows-ВМ в конфиге вообще нет строки machine, и что делать со снимками, если откат на них вам всё-таки нужен.

Это не одно предупреждение, а четыре

Проверку версий машин в pve8to9 добавили отдельным патчем (Fiona Ebner, июль 2025, коммит 8f09d5932b), и сделали её честно: скрипт обходит не только текущий конфиг ВМ, но и состояние гибернации, и все снимки — отдельно «живые», то есть с сохранённой памятью, и отдельно холодные. На выходе вы получаете до четырёх разных списков VMID, и путать их нельзя, потому что цена вопроса у них разная.

По каждой машине скрипт смотрит четыре места, и каждое даёт свой список VMID с собственной формулировкой предупреждения — они перечислены ниже в том порядке, в каком идут в выводе.

Разница между первым пунктом и остальными тремя — принципиальная. Конфигурация — это текстовая строка в /etc/pve/qemu-server/<vmid>.conf, её меняют командой за секунду. А vmstate гибернации и vmstate «живого» снимка — это дамп памяти QEMU, снятый конкретным бинарником с конкретной раскладкой виртуального железа. Возобновить или откатить его можно только на совместимой версии машины. Никакого «сконвертировать» там нет и не будет.

Отдельно отмечу четвёртый случай — холодные снимки. Он самый безобидный и самый коварный одновременно. Откатиться на такой снимок PVE 9 даст: памяти в нём нет, гость поднимется с нуля. Но вместе с диском откатится и секция конфига из снимка — вместе со старой строкой machine. То есть вы аккуратно обновили версию машины у 40 ВМ, через месяц кто-то откатил одну из них на снимок трёхмесячной давности — и она снова на pc-i440fx-5.2, снова в списке проблемных, и хорошо если она вообще стартует.

• machine в текущем конфиге — то, с чем ВМ стартует прямо сейчас;
• runningmachine у ВМ в гибернации (когда есть vmstate в корне конфига) — «возможно, не получится возобновить»;
• снимки с памятью (в секции снимка есть vmstate) — «возможно, не получится откатиться»;
• снимки без памяти — «версию машины, возможно, придётся обновлять после отката».

Откуда взялся рубеж 6.0 и почему паниковать рано

Логика такая. Начиная с QEMU 10.1 апстрим удаляет версии машин старше шести лет — раньше их таскали практически вечно. Мажорные релизы Proxmox VE выходят примерно раз в два года, значит каждый мажорный релиз PVE поддерживает версии машин примерно от двух предыдущих мажорных релизов PVE. Это прямо написано в административном руководстве, в разделе «QEMU Machine Version Deprecation».

Дальше конкретика. Для PVE 8 политика удаления ещё не действовала, там базовой версией остаётся 2.4 — то есть на восьмёрке заводилось буквально всё, что вы когда-либо создавали. Последним бинарником QEMU в составе PVE 9 ожидается QEMU 11.2, и вот он уже выкинет поддержку версий машин старше 6.0. Отсюда и рубеж: 6.0 — это базовая версия на весь жизненный цикл девятки. Для PVE 10 ожидается 8.0, и так дальше по два мажора за релиз.

Теперь то, ради чего я это пишу: сразу после апгрейда на PVE 9.0 ваши ВМ на pc-i440fx-5.2 никуда не денутся и продолжат стартовать. QEMU, который приезжает с девяткой на старте, старые версии машин ещё знает. Предупреждение pve8to9 — про будущее: про тот момент, когда в рамках девятки прилетит обновление pve-qemu-kvm до 11.x и старые версии молча исчезнут. То есть у вас есть не «ночь до апгрейда», а весь цикл жизни PVE 9 минус запас на обновления QEMU. Это принципиально другой уровень срочности.

Мой практический вывод: не надо в панике менять версию машины у всего парка в ночь апгрейда. Апгрейд гипервизора и смена виртуального железа гостей — две отдельные работы, и совмещать их — верный способ полдня искать, что именно сломалось. Сначала переезжаете на девятку и убеждаетесь, что кластер живой. Потом отдельным окном, по 3-5 машин за подход, разбираетесь с версиями машин и снимками.

• Proxmox VE 8: базовая версия 2.4, политика удаления ещё не действует;
• Proxmox VE 9: базовая версия 6.0, последним QEMU в цикле ожидается 11.2;
• Proxmox VE 10: ожидаемая базовая версия 8.0;
• каждый следующий мажор PVE поднимает базу примерно на две мажорные версии QEMU.

Главная ловушка: у Windows-ВМ строки machine в конфиге может не быть вообще

Каждый второй, кто получает это предупреждение, лезет в конфиг, не находит там строки machine и решает, что скрипт ошибся. Скрипт не ошибся. У Windows-гостей версия машины закрепляется при создании, потому что Windows крайне болезненно реагирует на смену виртуального железа — даже между холодными загрузками. Но старые конфиги, созданные годы назад, эту привязку в явном виде не хранят.

В коде qemu-server (модуль PVE::QemuServer::Machine, функция get_vm_machine) это выглядит так: если тип машины не задан или задан в общем виде — pc, q35, virt — и гость опознан как Windows по ostype, то берётся базовая версия 5.1. Именно 5.1, а не «последняя». Причина историческая: в QEMU 5.2 поправили раскладку ACPI, и Windows от этого изменения сильно путался. Начиная с QEMU 9.1 поведение изменили: если в строке meta поле creation-qemu не ниже 9.1, привязка делается к версии, на которой ВМ была создана. Если meta есть, но ВМ создана на более старом QEMU, база остаётся той же 5.1 — в коде рядом прямо написано, что поддержку 5.1 ожидают убрать в QEMU 11.1.

Складываем: старая Windows-ВМ, созданная на PVE 6 или 7, без строки machine и без meta, — по факту работает на pc-i440fx-5.1+pve0. Это ниже базовой версии 6.0, и pve8to9 её справедливо подсвечивает, хотя визуально в конфиге «ничего такого». Более того, в комментарии к коду прямо стоит пометка про PVE 10: там такую ВМ — Windows без явной версии машины и без meta — планируют просто отказываться запускать.

Проверять надо не глазами по файлу, а с учётом этой подстановки. Быстрый обход всего узла, который показывает корневые записи и секции снимков, а заодно ostype и meta:

awk '/^\[/{snap=$0} /^(machine|runningmachine|vmstate|ostype|meta):/{print FILENAME, snap, $0}' \
    /etc/pve/qemu-server/*.conf

В выводе ищите три вещи: Windows-гостей (ostype win*) без строки machine в корне, значения machine и runningmachine с версией ниже 6.0 и любые секции снимков, где есть vmstate.

• нет строки machine + ostype win* + нет meta → фактически 5.1, требует внимания;
• нет строки machine + ostype win* + есть meta с creation-qemu ≥ 9.1 → привязка к версии создания, скорее всего всё в порядке;
• нет строки machine + ostype win* + meta с creation-qemu ниже 9.1 → всё равно 5.1, требует внимания;
• нет строки machine + Linux/BSD-гость → используется Latest, то есть максимум, который умеет установленный QEMU; такие ВМ в предупреждение не попадают.

Снимки: обновление конфига их не чинит

Теперь самое неприятное и то, ради чего вообще стоит читать эту статью. Версию машины у существующего снимка изменить нельзя. Вообще. В руководстве это сформулировано без обиняков: «Unfortunately, there is no way to change the machine version of a snapshot, so you'd need to load the snapshot to salvage any data from it» — то есть чтобы вытащить данные из такого снимка, его придётся загрузить, пока поддержка ещё есть.

Механика простая. Когда вы делаете снимок с памятью, PVE пишет в секцию снимка строку runningmachine — точную версию машины того QEMU-процесса, который в этот момент крутил ВМ. Это сделано специально: живая миграция и снимки с RAM обязаны сохранять прежнюю версию машины, иначе состояние памяти не сойдётся с раскладкой железа и гость развалится. Соответственно, при откате PVE поднимет ВМ ровно на той версии, что записана в runningmachine, — и если её в бинарнике уже нет, откат просто не состоится.

Отсюда единственно правильная последовательность действий, и она контринтуитивна: сначала разбираемся со снимками, потом меняем версию машины. Не наоборот. Если снимок с памятью вам действительно нужен как точка отката — откатитесь на него сейчас, пока текущий QEMU его понимает, снимите с гостя то, что нужно (или просто примите его как новое актуальное состояние), удалите снимок, и только после этого поднимайте версию машины и делаете новый снимок. Если снимок нужен только «на всякий случай» и последний раз его смотрели полгода назад — удалите его и не изображайте деятельность.

И совсем прямо: снимки в Proxmox — это не резервная копия. Я регулярно вижу парки, где живут снимки годовалой давности «чтобы было», занимают половину тонкого пула и ломают производительность. Разбор machine version — хороший повод их наконец вычистить. Резервная копия — это Proxmox Backup Server или хотя бы vzdump на отдельное хранилище; в бэкапе версия машины лежит в конфиге, и её при восстановлении можно поправить, в отличие от снимка.

• снимок с памятью откатывается только на версию из своей строки runningmachine;
• изменить версию машины у существующего снимка штатно нельзя — только загрузить его и спасти данные;
• холодный снимок при откате возвращает в конфиг старую строку machine;
• бэкап PBS/vzdump, в отличие от снимка, восстанавливается с правкой версии машины в конфиге;
• снимки старше пары месяцев без понятной цели — первые кандидаты на удаление.

Практика: 9 ВМ в фитнес-клубе, две из них — сюрприз

Разбирали парк у клиента — фитнес-клуб «Пульс-Арена», 14 рабочих мест: ресепшн, отдел продаж, администрация и бухгалтерия. Один узел Proxmox VE 8.4 с локальным ZFS-зеркалом плюс отдельная небольшая машина под Proxmox Backup Server. Виртуалок девять: контроллер домена, сервер 1С с клубной базой и MS SQL, файловый, терминальный сервер для бухгалтерии, сервер СКУД турникетов, регистратор видеонаблюдения и три линукса под мониторинг, телефонию и шлюз.

Первый прогон pve8to9 --full дал 4 ID в списке про устаревшую версию машины в конфиге и, что важнее, 2 ID в списке «живых» снимков со старой версией. Из четырёх две оказались Linux-гостями с явно прописанными pc-i440fx-5.2 и pc-q35-5.2 — наследие переноса с другого гипервизора, когда версию зафиксировали руками и забыли. Эти лечатся тривиально. Две оставшиеся — как раз тот самый случай: Windows Server 2016 (терминальный сервер и сервер СКУД), конфиг без строки machine, без meta, по факту 5.1.

Сюрприз был в снимках. Терминальный сервер нёс снимок с памятью, снятый перед обновлением конфигурации 1С два года назад и с тех пор не тронутый, — 16 ГБ vmstate на ZFS, который никто не удалил, потому что «а вдруг». У сервера 1С снимок с памятью остался от криво настроенной процедуры патчей: скрипт делал снимок перед обновлением и удалял старый только при следующем запуске, а запусков не было с зимы. Вместе с дисковыми дельтами снимки держали около 40 ГБ на пуле объёмом меньше терабайта и были бесполезны.

Что сделали. Снимки: терминальный откатили в тестовом окне, убедились, что ничего уникального внутри нет, удалили. Второй — просто qm delsnapshot, предварительно сняв полноценный бэкап на PBS. Дальше версии машин: двум линуксам подняли до 9.2+pve1 через qm set, обе перезагрузились без замечаний. Windows-машины — по одной за вечер, после закрытия клуба, с бэкапом до и выписанными IP-настройками. Итог предсказуемый: на обеих сетевой адаптер определился как новый, статика слетела, вернули руками за пять минут; на сервере СКУД пришлось заново указать адрес контроллера турникетов в настройках службы. Утром pve8to9 показал «All VM machine versions are recent enough», и апгрейд на девятку прошёл штатно.

Времени ушло около трёх часов чистой работы, растянутых на неделю. Если бы мы делали всё в ночь апгрейда одним заходом, клуб в 7 утра получил бы неработающие турникеты на входе и терминал бухгалтерии без сети — и разбирательство, виноват ли Debian 13, новое ядро или всё-таки сетевой адаптер.

• 1 узел PVE 8.4 + отдельный PBS, 9 ВМ;
• 4 ВМ со старой версией в конфиге: 2 Linux с явной 5.2, 2 Windows Server 2016 с неявной 5.1;
• 2 снимка с памятью, около 40 ГБ на пуле, оба удалены после бэкапа;
• на Windows-гостях после смены версии слетела статика сети — восстановлено вручную;
• около трёх часов работы в нескольких вечерних окнах, апгрейд на PVE 9 без простоя клуба днём.

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

Начинаем с полного прогона проверки — она ничего не меняет, только читает и отчитывается:

pve8to9 --full

Дальше смотрим фактическую картину по узлу. Мне удобнее один awk, который вытаскивает и корневые записи, и секции снимков, чтобы сразу видеть, какая строка к какому снимку относится:

awk '/^\[/{snap=$0} /^(machine|runningmachine|vmstate):/{print FILENAME, snap, $0}' \
    /etc/pve/qemu-server/*.conf

Разбираемся со снимками — по каждой ВМ из «живых» списков смотрим, что за снимки и с какой версией они сняты, и решаем их судьбу:

qm listsnapshot 104
qm config 104 --snapshot before-1c-update | grep -E '^(machine|runningmachine|vmstate)'
# снимок больше не нужен (бэкап уже снят)
qm delsnapshot 104 before-1c-update

Снимки закрыты — меняем версию машины. Формат строки: pc-i440fx-<версия>+pve<ревизия> для 440FX, pc-q35-<версия>+pve<ревизия> для Q35. Суффикс +pveN — это downstream-ревизия Proxmox, она нужна, когда PVE меняет раскладку железа или дефолты, не дожидаясь релиза QEMU; для новой версии машины ревизия начинается с 0 и в этом случае в записи опускается. Сама смена — одна команда на ВМ; текущий конфиг без отложенных изменений удобно проверять через --current:

qm config 104 --current | grep -E '^(machine|ostype|meta)'
qm set 104 --machine pc-i440fx-9.2+pve1
qm set 107 --machine pc-q35-9.2+pve1
# если на q35 используется vIOMMU — параметр составной
qm set 107 --machine type=pc-q35-9.2+pve1,viommu=intel

После смены — обязательный холодный старт ВМ. Не «Reboot» из гостя: строка machine применяется при создании QEMU-процесса, а не при перезагрузке гостевой ОС. Останов и запуск. Для Windows — заранее выписанные IP-настройки под рукой.

qm shutdown 104 && qm start 104

• запустить pve8to9 --full и разложить вывод на четыре списка, а не в один;
• по каждой ВМ из списков снимков — решить: откатываемся, вытаскиваем данные или удаляем снимок;
• снять бэкап на PBS/vzdump до любых правок; для Windows — выписать сетевые настройки;
• поднять версию машины через qm set, целиться не в «самую новую», а в разумную и совместимую;
• холодный старт, проверка сети и дисков внутри гостя;
• повторить pve8to9 до чистого «All VM machine versions are recent enough».

Порядок апгрейда Proxmox VE 8 → 9, в который встраивается эта работа

Разбор версий машин — подготовительный этап, а не часть самого апгрейда. Официальная вики задаёт последовательность, и я её не нарушаю: сначала узел доводится до актуальной 8.4 (минимум 8.4.1), затем pve8to9 --full прогоняется до отсутствия ошибок, и только после этого меняются репозитории на Debian 13 Trixie и выполняется dist-upgrade. Предупреждения про версии машин формально не блокируют апгрейд, но закрыть их до смены репозиториев удобнее всего: у вас ещё работает привычный QEMU, а откатиться на снимок можно без сюрпризов.

# на PVE 8: довести узел до последней 8.4
apt update && apt dist-upgrade
pveversion

# проверка до чистого результата
pve8to9 --full

Дальше — смена репозиториев: все упоминания bookworm в списках APT (основной Debian, репозиторий Proxmox VE enterprise или no-subscription, Ceph, если он есть) меняются на trixie, после чего выполняется dist-upgrade и перезагрузка в новое ядро. Точные строки репозиториев берите из вики для своего варианта подписки — они отличаются, и путать enterprise с no-subscription на боевом узле не стоит. В кластере узлы обновляются по одному, ВМ с обновляемого узла предварительно мигрируют.

# после правки репозиториев на trixie
apt update
apt dist-upgrade
reboot

# после перезагрузки
pveversion
pve8to9 --full

После апгрейда проверяю три вещи из списка известных проблем: ВМ с пробросом PCI стартуют на новом ядре (если нет — загрузка на старом ядре и его пин), настройки из /etc/sysctl.conf перенесены в /etc/sysctl.d/, а сторонний бэкап вроде Veeam не сломался на ВМ, которым успели поднять версию машины до 10.0 и выше.

• обновить узел до последней Proxmox VE 8.4 (не ниже 8.4.1) и снять свежие бэкапы всех ВМ;
• прогнать pve8to9 --full, разобрать снимки и версии машин, повторять до чистого результата;
• сменить репозитории bookworm → trixie согласно вики для своей подписки;
• выполнить apt dist-upgrade и перезагрузиться в новое ядро, в кластере — по одному узлу;
• проверить старт ВМ с пробросом PCI, перенос sysctl и работу бэкапа.

Чего делать не надо и где я сам не уверен

Не гонитесь за «Latest». Соблазн выставить самую свежую версию машины понятен, но именно на этом в PVE 9 обожглись пользователи Veeam: в официальной вики Proxmox по апгрейду с 8 на 9 висит известная проблема — резервное копирование Veeam ломается на ВМ с версией машины 10.0 и выше, потому что изменился способ подключения дисков. Штатный обходной путь — зафиксировать машину на 9.2+pve1 или отложить обновление версии. К моменту, когда вы это читаете, Veeam мог уже выпустить совместимый билд — проверьте матрицу совместимости своей версии, я бы на память тут не полагался. Для клиентов на PBS вопрос не стоит вовсе.

Не меняйте заодно тип машины. Если ВМ работает на i440fx и вам не нужен PCIe-проброс или vIOMMU — оставьте i440fx. Переезд на q35 «за компанию» — это отдельный проект с риском не найти загрузочный диск. Одна работа за один заход.

Не забывайте, что параллельно с версией машины апгрейд на девятку приносит смену базы на Debian 13 Trixie со своими сюрпризами: /tmp становится tmpfs и съедает до половины памяти, а systemd-sysctl перестаёт читать /etc/sysctl.conf — настройки надо переносить в /etc/sysctl.d/. Плюс на релизных ядрах 6.14 часть пользователей жаловалась на невозможность старта ВМ с PCI-проброшенным железом; обходной путь — пин ядра. Если в вашем парке есть ВМ с проброшенным GPU или контроллером, планируйте отдельную проверку.

И честно про спорное. Единого мнения, до какой именно версии поднимать машины, нет и быть не может: 6.0 — это минимум выживания на всю девятку, но если вы поднимете ровно до 6.0, то через два года в PVE 10 будете делать эту же работу заново с базовой версией 8.0. Я в 2026-м целюсь в диапазон 9.2–10.x: 9.2+pve1 — консервативный выбор, который переживёт и десятку, и не поссорится со сторонним бэкапным софтом. Если у вас всё на PBS и парк чисто линуксовый — берите то, что предлагает интерфейс по умолчанию, и не усложняйте.

• не выставлять «Latest» машинам, которые бэкапит Veeam, — пин на 9.2+pve1, пока нет совместимого билда;
• не менять i440fx на q35 заодно с версией машины;
• не поднимать версию ровно до 6.0 — в PVE 10 база уже 8.0;
• не совмещать смену версий Windows-гостей с ночью апгрейда гипервизора;
• не забывать про /tmp на tmpfs, sysctl.d и ядро 6.14 с PCI-пробросом.

Частые вопросы