Proxmox VM не запускається після зміни типу CPU: робочі кроки відновлення

January 27, 2026 • February 3, 2026 • Читання: 5 хв • Views: 5

Було корисно?

Ви змінили тип CPU у Proxmox VM, бо хотіли кращу продуктивність, узгодженість при міграції або слідували пораді з форуму. Тепер ВМ не стартує, Proxmox показує «QEMU exited with code 1», і ви дивитесь на зупинене навантаження, яке ще п’ять хвилин тому працювало нормально.

Ця помилка поширена, зазвичай виправляється за кілька хвилин і іноді вказує на те, що ви довго працювали на тонкій крижині. Давайте безпечно відновимо ВМ, пояснимо, що саме зламалося, і підготуємо вас до того, щоб змінювати типи CPU без ризику наступного разу.

Швидкий план діагностики

Якщо у вас є лише десять хвилин, перш ніж хтось запитає, чому панель червона, зробіть це в такому порядку. Мета — визначити, чи маєте ви справу з чистою проблемою моделі CPU QEMU, реакцією гостьової ОС або невідповідністю апаратного забезпечення/хоста.

По-перше: читайте фактичну помилку QEMU, а не повідомлення GUI

Перегляньте журнал завдань та системний журнал для спроби старту ВМ.
Шукайте конкретні фрази на кшталт unsupported CPUID, host doesn’t support requested feature, invalid CPU model або kvm: failed to init.

По-друге: підтвердіть конфігурацію ВМ зараз і порівняйте з попередньою

Перевірте рядок cpu: та будь-які перевизначення в args:.
Якщо є резервні копії, порівняйте поточний конфіг з останнім відомо робочим.

По-третє: вирішіть, чи виправлення — «відкотити тип CPU» або «змінити на безпечніший базовий рівень»

Якщо ВМ має запуститися зараз: відкотіть до попереднього типу CPU (або host, якщо раніше працювало).
Якщо ВМ має мігрувати між нодами: оберіть базовий рівень, наприклад x86-64-v2/x86-64-v3 (де підтримується) або модель з іменем, що є на всіх нодах.

По-четверте: якщо вона стартує — перевірте, як гість бачить CPU і чи стабільний він

Для Windows: перевірте наслідки активації/ліцензування та підтвердіть запуск критичних сервісів.
Для Linux: перевірте dmesg на попередження щодо функцій CPU, повідомлення мікрокоду та зміни джерела часу (clocksource).

Одна операційна істина: ВМ, яка не запускається, зазвичай має невідповідність конфігурації. ВМ, яка запускається, але поводиться дивно — зазвичай має регрес функцій CPU, зсув таймера/джерела часу або проблему очікувань драйверів гостя.

Що саме зламалося при зміні типу CPU

У Proxmox налаштування «тип CPU» — це не косметика. Воно контролює, яку віртуальну модель CPU QEMU рекламує для гостя і які можливості KVM має прискорювати. Це включає:

CPUID прапорці функцій (SSE4.2, AVX, AVX2, AES-NI, BMI, FMA тощо).
Рівень набору інструкцій і особливі випадки (деякі моделі означують набори прапорців).
Відображення топології (сокети/ядра/потоки) і інколи кеш/таймінг.
Сумісність для міграції між хостами: модель CPU — це контракт, який має дотримуватися на всіх вузлах, куди може потрапити ВМ.

Коли ви обираєте host, QEMU намагається показати CPU, що відповідає хосту, дозволяючи все, що підтримує фізичний процесор. Чудово для продуктивності. Але відмінно і для того, щоб загнати себе в глухий кут, якщо потім ви перемістите ВМ на хост з меншими можливостями або іншою мікроархітектурою.

Коли ви обираєте модель за іменем (наприклад, Skylake-Server, EPYC, Broadwell), QEMU показує підібраний набір прапорців. Це може поліпшити сумісність при міграції, але також може спричинити жорсткий збій, якщо:

фізичний CPU хоста не підтримує одну з вимогливих функцій;
збірка QEMU на вузлі не розпізнає назву моделі;
ВМ має явну args: рядок, що примушує прапорці, які конфліктують з вибраною моделлю;
ви змішуєте Intel ↔ AMD і модель передбачає вендор-специфічну поведінку.

Іноді ВМ стартує, але гостьова ОС заперечує після цього. Windows може вирішити, що це “нове обладнання”, а Linux може змінити поведінку джерела часу або відключити певні швидкі шляхи ядра.

Коротка реальність з гумором (жарт №1): Зміни типу CPU схожі на «швидкі рефактори». Слово «швидкі» — це здебільшого емоційна підтримка.

Цікаві факти та історичний контекст

Це не просто дрібниці заради цікавості. Кожен пункт пояснює, чому зміна типу CPU може поламати раніше стабільну ВМ.

CPUID був полем мін для сумісності з 1990-х. Гості не просто «використовують, що є»; вони приймають рішення на основі повідомлених прапорців і ідентифікатора вендора.
KVM — не емулятор у першу чергу; це прискорювач. Якщо ви попросите функції CPU, яких хост не може надати, KVM відмовиться — швидко та безкомпромісно.
Назви моделей CPU в QEMU не вічні. Моделі та псевдоніми змінюються між версіями QEMU; оновлення Proxmox можуть додавати моделі, позбавляти старих або змінювати значення за замовчуванням.
Живі міграції сприяли появі базових моделей CPU. Уся причина існування «загальних» типів CPU — зробити можливим «перемістити цю ВМ куди завгодно».
Віртуалізація Intel і AMD відрізняються у пограничній поведінці. Навіть коли обидва підтримують ті ж інструкції, вендор-специфічні фічі та мікрокод можуть впливати на гостей і гіпервізори.
Епоха Spectre/Meltdown вплинула на віртуалізацію. Мікрокод і ядерні патчі змінювали продуктивність і інколи змінювали видимі функції; кластери бачили, як «однакові CPU» поводяться інакше після оновлень.
Активація Windows може трактувати зміну CPU/плати як зміну обладнання. Зміна моделі CPU може бути достатньою для тригеру перевірок ліцензії, залежно від редакції та методу активації.
Вкладена віртуалізація дуже чутлива. Якщо гість запускає гіпервізор, йому часто потрібні специфічні VMX/SVM прапорці; зміни моделі CPU можуть їх прибрати.

Практичні завдання відновлення (команди, виводи, рішення)

Нижче — практичні кроки, які можна виконати на вузлі Proxmox. Кожен містить: команду, що означає типовий вивід, і яке рішення слідує. Виконуйте їх по черзі, доки не запустите ВМ або не отримаєте чітку корінну причину.

Завдання 1: Знайдіть запис про помилку старту ВМ у журналі

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy -u pvestatd --since "30 min ago" | tail -n 80
Dec 26 11:02:15 pve01 pvedaemon[2217]: starting task UPID:pve01:00004A3C:0001B2D1:676D1D97:qmstart:105:root@pam:
Dec 26 11:02:15 pve01 pvedaemon[2217]: VM 105 start failed: command '/usr/bin/kvm -id 105 ... -cpu Skylake-Server,...' failed: exit code 1
Dec 26 11:02:15 pve01 pvedaemon[2217]: end task UPID:pve01:00004A3C:0001B2D1:676D1D97:qmstart:105:root@pam: VM 105 start failed: exit code 1

Що це означає: Ви підтвердили, що це збій запуску QEMU/KVM, а не крах гостьової ОС після завантаження.

Рішення: Переходьте до пошуку точної помилки QEMU (Завдання 2). Не здогадуйтеся.

Завдання 2: Витягніть детальну помилку QEMU з журналу завдання

cr0x@server:~$ cat /var/log/pve/tasks/active | head
UPID:pve01:00004A3C:0001B2D1:676D1D97:qmstart:105:root@pam:
cr0x@server:~$ cat /var/log/pve/tasks/UPID:pve01:00004A3C:0001B2D1:676D1D97:qmstart:105:root@pam: | tail -n 60
kvm: host doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
TASK ERROR: start failed: QEMU exited with code 1

Що це означає: Вибрана модель CPU (або кастомні прапорці) запитує VMX, але хост не може її надати (або вона відключена).

Рішення: Перевірте підтримку віртуалізації на хості та налаштування BIOS (Завдання 3 і Завдання 4). Якщо ця ВМ не потребує вкладеної віртуалізації, пізніше приберіть цю вимогу у прапорцях CPU.

Завдання 3: Переконайтеся, що KVM завантажено і віртуалізація доступна

cr0x@server:~$ lsmod | egrep 'kvm|vhost' | head
kvm_intel             385024  0
kvm                  1200128  1 kvm_intel
vhost_net              36864  0
vhost                  53248  1 vhost_net

Що це означає: Модулі KVM завантажені. Це необхідно, але не достатньо.

Рішення: Підтвердіть прапорці CPU, які бачить хост (Завдання 4).

Завдання 4: Підтвердіть, що прапорці CPU хоста включають те, що запитує ВМ

cr0x@server:~$ lscpu | egrep 'Vendor ID|Model name|Flags|Virtualization' -A1
Vendor ID:           GenuineIntel
Model name:          Intel(R) Xeon(R) Silver 4210R CPU @ 2.40GHz
Virtualization:      VT-x
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ... vmx ... avx avx2 ...

Що це означає: VT-x (прапорець vmx) є. Якщо QEMU сказав, що VMX не підтримується, або BIOS його вимкнено, або ядро маскує його, або ви не на тій ноді, яку вважаєте.

Рішення: Якщо у рядку Virtualization порожньо або прапорець відсутній — виправте налаштування BIOS/прошивки. Якщо він присутній — у конфігурації ВМ, ймовірно, є примусові несумісні вимоги (Завдання 6 і Завдання 7).

Завдання 5: Перевірте поточну конфігурацію ВМ щодо типу CPU і примусових прапорців

cr0x@server:~$ qm config 105
boot: order=scsi0;net0
cores: 8
cpu: Skylake-Server,flags=+pcid;+spec-ctrl;+md-clear
memory: 16384
name: payroll-app01
net0: virtio=DE:AD:BE:EF:10:05,bridge=vmbr0
scsi0: local-lvm:vm-105-disk-0,discard=on,iothread=1
scsihw: virtio-scsi-pci

Що це означає: Модель CPU явно встановлена як Skylake-Server з додатковими прапорцями. Якщо хост старший або AMD — це може не запуститися.

Рішення: Якщо ви змінили це недавно і ВМ раніше стартувала — відкотіть до попереднього типу CPU (Завдання 8). Якщо потрібна сумісність для міграцій — оберіть базовий рівень пізніше.

Завдання 6: Перевірте приховані перевизначення в `args:`

cr0x@server:~$ grep -nE '^(cpu:|args:|machine:|bios:|ostype:)' /etc/pve/qemu-server/105.conf
3:cpu: Skylake-Server,flags=+pcid;+spec-ctrl;+md-clear

Що це означає: Тут немає сюрпризів у args:. Добре. Якщо ви бачите рядок args:, вважайте його підозрілим до доказу зворотного.

Рішення: Якщо args: присутній і включає -cpu або -machine, видаліть/відкоригуйте його; налаштування GUI Proxmox не врятують вас від вашого старого ручного правлення.

Завдання 7: Перевірте, чи розпізнає ваша збірка QEMU назву моделі CPU

cr0x@server:~$ /usr/bin/qemu-system-x86_64 -cpu help | egrep -i 'skylake|broadwell|epyc|x86-64' | head -n 20
x86-64-v2
x86-64-v3
Broadwell
Skylake-Server
EPYC
EPYC-Rome

Що це означає: Модель існує на цій ноді. Якби ні, QEMU видав би одразу «invalid CPU model».

Рішення: Якщо модель відсутня на деяких нодах кластера — у вас проблема розбіжності версій. Узгодьте версії Proxmox/QEMU у нодах або стандартизуйтесь на моделі, що є скрізь.

Завдання 8: Відкотіть тип CPU до останнього відомо робочого (швидке відновлення)

cr0x@server:~$ cp -a /etc/pve/qemu-server/105.conf /root/105.conf.before-revert
cr0x@server:~$ qm set 105 --cpu host
update VM 105: -cpu host
cr0x@server:~$ qm start 105

Що це означає: Ви відкотитесь до host, що зазвичай запускає ВМ, якщо вона раніше працювала на цій ноді.

Рішення: Якщо це завантажиться — зупиніться та ліквідуйте прямий збиток. Потім вирішіть, чи потрібен вам інший тип CPU (див. пізніше розділ). Якщо й тут відмова — проблема не лише в «імені моделі»; можливо, це прапорці, тип машини або відсутність апаратної віртуалізації.

Завдання 9: Якщо `host` не працює, спробуйте безпечніший загальний базис

cr0x@server:~$ qm stop 105
stopping VM 105 (timeout = 60 seconds)
cr0x@server:~$ qm set 105 --cpu x86-64-v2
update VM 105: -cpu x86-64-v2
cr0x@server:~$ qm start 105

Що це означає: Ви просите консервативний набір функцій CPU, який зазвичай працює на багатьох сучасних хостах.

Рішення: Якщо це запускається, ймовірно у старій моделі або прапорцях були невідомі/незабезпечені функції. Тримайте x86-64-v2 (або v3, якщо кластер підтримує) як базовий рівень для кластера.

Завдання 10: Переконайтеся, що процес ВМ існує і використовує прискорення KVM

cr0x@server:~$ pgrep -a -f 'kvm.*-id 105' | head -n 1
24788 /usr/bin/kvm -id 105 -name payroll-app01 ...
cr0x@server:~$ ps -o pid,comm,%cpu,%mem,args -p 24788
  PID COMMAND         %CPU %MEM COMMAND
24788 kvm              8.2  4.1 /usr/bin/kvm -id 105 -name payroll-app01 ...

Що це означає: ВМ фактично запущена і працює як процес QEMU/KVM.

Рішення: Перейдіть від «гіпервізор може запустити» до «гість здоровий». Якщо ВМ недоступна по мережі, налагоджуйте всередині гостя (консоль, мережа, сервіси).

Завдання 11: Перевірте рядок команд QEMU для ефективного визначення CPU

cr0x@server:~$ qm showcmd 105 --pretty | sed -n '1,120p'
/usr/bin/kvm \
  -id 105 \
  -name payroll-app01,debug-threads=on \
  -no-shutdown \
  -chardev socket,id=qmp,path=/var/run/qemu-server/105.qmp,server=on,wait=off \
  -mon chardev=qmp,mode=control \
  -machine type=pc-q35-8.1+pve0 \
  -cpu x86-64-v2 \
  -smp 8,sockets=1,cores=8,maxcpus=8 \
  -m 16384 \
  ...

Що це означає: Це єдиний джерело правди для того, що QEMU насправді виконує (після трансформацій Proxmox конфіга).

Рішення: Якщо ви бачите інший -cpu, ніж очікувалося, у вас є конфліктуючі записи конфіга або перевизначення в args:.

Завдання 12: Перевірте сумісність функцій CPU у кластері (реальність міграції)

cr0x@server:~$ pvesh get /nodes --output-format json-pretty
[
  {
    "node": "pve01",
    "status": "online"
  },
  {
    "node": "pve02",
    "status": "online"
  }
]
cr0x@server:~$ for n in pve01 pve02; do echo "== $n =="; ssh $n "lscpu | egrep 'Vendor ID|Model name|Flags' -A1 | head -n 6"; done
== pve01 ==
Vendor ID:           GenuineIntel
Model name:          Intel(R) Xeon(R) Silver 4210R CPU @ 2.40GHz
Flags:               ... avx avx2 vmx ...
== pve02 ==
Vendor ID:           GenuineIntel
Model name:          Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz
Flags:               ... avx avx2 vmx ...

Що це означає: Ноди схожі, але не ідентичні. Невеликі відмінності мають значення: один степпінг CPU, інший рівень мікрокоду, різні налаштування BIOS — і раптом прапорець зникає.

Рішення: Якщо ви очікуєте міграції, оберіть базову модель CPU, що підтримується всіма нодами. «Працює на моїй ноді» — не стратегія.

Завдання 13: Перевірте повідомлення про мікрокод і ядро, якщо функції «мають бути», але їх немає

cr0x@server:~$ dmesg | egrep -i 'microcode|kvm|vmx|svm' | tail -n 30
[    0.812345] microcode: microcode updated early to revision 0x2006e04, date = 2023-10-12
[    6.112233] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround
[    6.112455] kvm_intel: enabling virtualization on CPU0

Що це означає: Мікрокод і ініціалізація KVM видимі. Якщо KVM скаржиться на відключену віртуалізацію — це ваш явний індикатор.

Рішення: Якщо віртуалізація відключена на апаратному рівні платформи — виправте BIOS і перезавантажте ноду. Не намагайтесь «обходити» відсутній VMX/SVM.

Завдання 14: Якщо Windows не завантажується після зміни CPU, перевірте, чи це цикл перезавантажень чи помилка гіпервізора

cr0x@server:~$ qm terminal 105
starting serial terminal on interface serial0 (press Ctrl+O to exit)

Що це означає: Серійний термінал — швидкий спосіб побачити проблеми раннього завантаження в Linux; для Windows він менш корисний, якщо ви не налаштували серійну діагностику. Якщо у вас є VGA-консоль у GUI — використайте її.

Рішення: Якщо ВМ стартує, але відразу перезавантажується, ви пройшли етап помилки запуску моделі CPU і перейшли в поведінку гостя. Тримайте гіпервізор стабільним і налагоджуйте гостя окремо.

Завдання 15: Відновіть відомо робочий конфіг файл ВМ, якщо потрібен миттєвий відкат

cr0x@server:~$ ls -l /root/105.conf.*
-rw-r--r-- 1 root root 512 Dec 26 11:05 /root/105.conf.before-revert
cr0x@server:~$ cp -a /root/105.conf.before-revert /etc/pve/qemu-server/105.conf
cr0x@server:~$ qm start 105

Що це означає: Ви примусово повертаєте попередній збережений конфіг, ігноруючи те, що зробив GUI.

Рішення: Якщо це вирішує проблему, вважайте попередню зміну типу CPU корінною причиною і переходьте до контрольованого повторного внесення змін з тестуванням, а не на око.

Завдання 16: Переконайтеся, що ви не боретесь з невідповідністю типу машини, що з’явилася через «допоміжні» правки

cr0x@server:~$ qm config 105 | egrep '^(machine:|bios:|efidisk0:|ostype:)'
machine: pc-q35-8.1+pve0
ostype: l26

Що це означає: Тип машини — Q35. Деякі зміни моделі CPU супроводжуються зміною типу машини (ручні правки, старі гайди). Така комбінація може змінити експозицію пристроїв і поведінку завантаження гостя.

Рішення: Якщо ви змінювали тип машини приблизно в той же час, відкотіть і його. Міняйте одну змінну за раз, якщо вам не подобається детективне розслідування.

Коротка реальність з гумором (жарт №2): Якщо ви змінили тип CPU, тип машини і режим BIOS в одному редагуванні — ви не «оптимізували». Ви створили детективний роман.

Типові помилки: симптом → корінна причина → виправлення

Цей розділ навмисно прямий. Ось шаблони, які постійно спливають у продакшені.

1) Симптом: «QEMU exited with code 1» + «host doesn’t support requested feature»

Корінна причина: Вибрана модель CPU або прапорці включають функції, яких немає на хості (або відключені в BIOS).
Виправлення: Відкотіть до host або до нижчого базового рівня, наприклад x86-64-v2. Якщо відсутня VMX/SVM — виправте налаштування BIOS і перезавантажте хост.

2) Симптом: «invalid CPU model» після вибору іменованої моделі

Корінна причина: Збірка QEMU на тій ноді не знає цю назву моделі (розбіжність версій, інший набір пакетів або застаріла нода Proxmox).
Виправлення: Використайте /usr/bin/qemu-system-x86_64 -cpu help, щоб вибрати доступну модель. Уніфікуйте версії Proxmox/QEMU по кластеру.

3) Симптом: ВМ стартує на вузлі A, відмовляється стартувати після міграції на вузол B

Корінна причина: Тип CPU встановлено на host або занадто сучасну модель; вузол B не має потрібних прапорців.
Виправлення: Виберіть базову модель CPU, яку підтримують всі вузли. Застосуйте її до ВМ до міграції (вікно обслуговування, якщо гість чутливий).

4) Симптом: Linux завантажується, але продуктивність падає після зміни типу CPU

Корінна причина: Ви видалили AVX/AVX2/AES або інші прискорення, які використовував робочий навантажувач (криптографія, стиснення, JVM, контрольні суми бази даних). Або гість змінив джерело часу.
Виправлення: Порівняйте прапорці CPU до/після. Виберіть базу, що зберігає потрібні функції і лишається мігрувальною. Перевірте clocksource і повідомлення ядра.

5) Симптом: Windows завантажується, але скаржиться активація/ліцензування

Корінна причина: Windows бачить зміну ідентичності обладнання (зміни моделі CPU/топології можуть сприяти цьому).
Виправлення: Віддавайте перевагу стабільним моделям CPU на довгий термін. Якщо змінюєте — зробіть це раз, документуйте і очікуйте робочі процеси активації в залежності від методу ліцензування.

6) Симптом: Вкладена віртуалізація перестала працювати

Корінна причина: Зміна моделі CPU прибрала vmx (Intel) або svm (AMD) експозицію гостю.
Виправлення: Оберіть модель CPU, що містить розширення віртуалізації, і підтвердіть, що BIOS хоста їх підтримує. Уникайте випадкового редагування прапорців; тестуйте вкладені навантаження окремо.

7) Симптом: «KVM: entry failed» або помилки ініціалізації KVM

Корінна причина: Обмеження ядра/KVM на хості, мікрокодні особливості або несумісна комбінація прапорців CPU і типу машини.
Виправлення: Приберіть кастомні прапорці і відкотіться до відомо робочої моделі CPU. Якщо хост нещодавно змінив ядро/мікрокод — уніфікуйте ноди і перезавантажте до консистентного стану.

8) Симптом: ВМ стартує тільки після того, як ви приберете один «прапорець безпеки»

Корінна причина: Ви скопіювали набір прапорців CPU з іншого покоління процесора. Деякі прапорці мітрацій та пом’якшення відносяться до специфічних можливостей і MSR, яких може не бути скрізь.
Виправлення: Перестаньте вручну включати прапорці пом’якшення, якщо точно не розумієте, що роблять. Використовуйте підтримувані моделі CPU і довіряйте QEMU/KVM розумним дефолтам відповідно до ваших версій.

Три корпоративні короткі історії з практики

Коротка історія 1: Інцидент через хибне припущення

Середня компанія мала двовузловий Proxmox-кластер, який «очевидно» мав однакові CPU. Закупівля замовила два сервери у тому ж кварталі. Специфікації збігалися. Команда встановила більшість продукційних ВМ з cpu: host для максимальної продуктивності.

Під час планового перезавантаження кількох хостів кілька ВМ не змогли запуститися на залишковій ноді. Помилка виглядала як загальний збій QEMU. Під тиском команда ганялася за проблемами зі сховищем та мережею — бо зазвичай саме вони ламаються в їхньому середовищі.

Корінна причина: одна нода мала трохи новіший степпінг CPU і інший мікрокод, що відкривала кілька прапорців, яких іншій ноді не вистачало. Коли ВМ опинилися на старішому вузлі, KVM відмовив запитуваний набір CPUID. Припущення «сервери ідентичні» виявилося хибним.

Відновилися, переключивши постраждалі ВМ на консервативну базову модель CPU, що підтримувалася обома нодами, а потім запланували інвентаризацію та стандартизацію апаратного забезпечення. Аварія не була драматичною. Вона була гіршою: вона була передбачуваною та нудною.

Постійне виправлення було культурним: тепер будь-яка зміна, що впливає на сумісність міграції, вимагає перевірки моделей CPU на всіх нодах до вікна обслуговування.

Коротка історія 2: Оптимізація, що обернулась проти

Внутрішня платформа розміщувала збірні воркери і CI-ранеери у Proxmox ВМ. Команда гналася за швидшою збіркою, тому змінила тип CPU з базового на host і додала прапорці для AES та AVX2 «на всяк випадок». Продуктивність на основній ноді покращилась.

Потім одна нода пішла в обслуговування, і планувальник перемістив ВМ. Деякі гості стартували, деякі — ні. Ті, що стартували, видавали дивні, неповторювані помилки збірки. Це такий баг, що змушує інженерів сумніватися у виборі професії.

Проблема не в «AVX2 — погано». Проблема була в гетерогенності: одна нода підтримувала набір фіч і мікроархітектури, інша — ні, і ранери не були закріплені. Система збірки опинилась у флоті, де бінарники інколи будувалися під різними можливостями CPU, і тести поводилися інакше через різні таймінги і прискорення криптооперацій.

Вони відкотилися до базової моделі CPU для раннерів і дозволили host тільки для закріплених, немігруючих робочих навантажень з явними правилами розміщення. Команда також перестала розкидати прапорці CPU як сіль. Якщо немає вимірювань і плану відкату — ви не оптимізуєте, ви граєте у казино.

Коротка історія 3: Сумна, але правильна практика, що врятувала день

Фінансова організація тримала критичні Windows ВМ на Proxmox. Вони не були голосними; вони просто дисципліновані. Перед будь-якою зміною, пов’язаною з апаратним забезпеченням ВМ (CPU, прошивка/режим BIOS, тип машини), вони робили дві речі: знімали снапшот конфігурації файлу ВМ і перевірену процедуру відкату.

Одної п’ятниці хтось змінив тип CPU ВМ, щоб «підлаштувати під інші сервери» для живої міграції під час патчів. ВМ не стартувала. У повідомленні про помилку згадувався непідтримуваний CPUID. Рівень стресу зріс; це був тиждень виплат, звісно.

Черговий SRE не вів дискусій з всесвітом. Він відновив попередній /etc/pve/qemu-server/<vmid>.conf зі збереженої копії, запустив ВМ і відновив бізнес-процеси. Потім відкрив зміну з двома наступними завданнями: вибрати підтримуваний базовий CPU для кластера і запланувати зміну у вікні з валідацією та можливістю переактивації.

Ось у чому сила нудних практик: вони здаються повільними, поки не знадобляться. Тоді вони — найшвидший інструмент, який у вас є.

Чеклісти / покроковий план

Покроковий план відновлення (мінімізація простою)

Збережіть докази. Скопіюйте поточну конфігурацію ВМ і вивід журналу завдань. Потрібно щось вивчити, а не лише відновити сервіс.
Прочитайте помилку QEMU/KVM. Не чіпайте налаштувань, поки не з’ясуєте, чи це «invalid model», «unsupported feature» чи «KVM init failure».
Відкотіть тип CPU до останнього відомо робочого. Якщо ВМ працювала раніше сьогодні — відкотіть і запустіть. Відновіть сервіс.
Якщо відкат не допоміг — приберіть кастомізацію. Видаліть кастомні прапорці та будь-які args: рядки, що впливають на -cpu. Зробіть конфіг простим, поки вона не стартує.
Якщо все ще не працює — перевірте віртуалізацію хоста. Переконайтеся в модулях KVM, прапорцях CPU і налаштуваннях BIOS. Перезавантажте хост, якщо потрібно.
Після старту — перевірте стан гостя. Консоль, диски, мережа, сервіси. Слідкуйте за ліцензуванням і драйверами.
Лише після цього повторно міняйте тип CPU. Оберіть базову модель, що є на всіх нодах. Протестуйте старт на кожній ноді, якщо міграція має значення.

Чекліст: вибір типу CPU, що не підведе вас пізніше

Якщо ВМ ніколи не мігрує і вам потрібна продуктивність: cpu: host — прийнятний вибір, але документуйте, що ВМ прив’язана до сумісного апаратного забезпечення.
Якщо ВМ може мігрувати в однорідному кластері: оберіть іменовану модель, що є і підтримується на всіх нодах.
Якщо кластер змішаний або очікуються апаратні зміни: оберіть консервативний базовий рівень (x86-64-v2 або подібний) і прийміть невелике падіння продуктивності.
Уникайте ручних прапорців CPU, якщо не можете пояснити кожен, протестувати його і відкотити.

Чекліст: безпечна процедура зміни (як я робив би в продакшені)

Зареєструйте поточний конфіг: скопіюйте /etc/pve/qemu-server/<vmid>.conf.
Підтвердіть, що QEMU підтримує цільову модель CPU на кожній ноді.
Підтвердіть, що фізичні CPU на кожній ноді підтримують потрібні прапорці.
Заплануйте можливі ефекти на гість (активація Windows, вкладена віртуалізація, зміни clocksource ядра).
Змініть лише тип CPU спочатку. Запустіть і перевірте.
Лише після успіху: розгляньте інші налаштування (NUMA, hugepages, pinning), по одному пункту за раз.

Питання та відповіді (FAQ)

1) Чому Proxmox дозволяє мені вибрати тип CPU, який хост не може запустити?

Тому що Proxmox не батько. Він передає ваш запит QEMU/KVM; KVM вже накладає апаратні обмеження під час старту. Деякі несумісності виявляються лише коли QEMU збирає остаточний опис CPU.

2) Чи завжди `cpu: host` — найкращий вибір?

Найкраще для продуктивності на одиночній ноді, часто так. Найгірше для міграції у разі змішаного апаратного забезпечення. Якщо потрібна мобільність — виберіть базову модель CPU і прийміть, що «максимальні прапорці скрізь» ≠ «надійні операції».

3) У чому різниця між іменованими моделями (Skylake, EPYC) і `x86-64-v2`/`v3`?

Іменовані моделі відповідають конкретним мікроархітектурам з набором прапорців. Рівні x86-64-v* прагнуть стандартизованого мінімального ISA-базису. Базиси зазвичай кращі для портативності; іменовані моделі — для передбачуваної продуктивності в відомому флоті.

4) ВМ стартує після зміни типу CPU, але продуктивність впала. Чи варто відкотити?

Якщо навантаження використовує крипто/стиснення/векторні інструкції, ймовірно ви видалили функцію, від якої воно залежало. Порівняйте прапорці CPU у гості до/після (або перевірте ефективний рядок QEMU). Якщо продуктивність критична для бізнесу — відкотіться і оберіть базу, що зберігає потрібні можливості скрізь ноди.

5) Чи може зміна типу CPU пошкодити диски або дані?

Не безпосередньо. Зміни моделі CPU впливають на доступність інструкцій, а не на операції запису на диск. Справжній ризик — непрямий: крахи, несумісні завантаження, некоректне завершення файлової системи або прикладні помилки після нестабільних стартів. Тому перевіряйте гостя та додатки.

6) Чому жива міграція раптом перестала працювати після зміни типу CPU?

Жива міграція вимагає сумісності CPU між джерелом і цільовим вузлом. Якщо ви змінили на host на новішому CPU, ВМ може тепер вимагати функцій, яких немає на іншій ноді. Використовуйте кластерний базовий тип CPU, щоб зробити міграцію передбачуваною.

7) Чи потрібно вимикати ВМ, щоб змінити тип CPU?

Так, у практичному сенсі. Модель CPU встановлюється під час старту ВМ. Ви можете змінити конфіг живо, але вона не застосується до запущеної ВМ до наступного перезавантаження. Також: змінити тип CPU на працюючій ВМ і «перезавантажити пізніше» — це закладання пасток для майбутнього вас.

8) Як дізнатися, яку модель CPU фактично бачить гість?

На хості використайте qm showcmd <vmid>, щоб побачити ефективний аргумент -cpu. Всередині Linux-гостя — lscpu і /proc/cpuinfo показують те, що гість вважає реальністю. У Windows — перевірте назву CPU в Диспетчері завдань і використайте системні утиліти для інфо.

9) Який найбезпечніший «загальний» тип CPU для змішаного Intel-кластера?

Зазвичай x86-64-v2 — безпечна відправна точка, якщо ваші ноди досить сучасні. Якщо ноди новіші і ви перевірили підтримку на всіх, x86-64-v3 може бути компромісом. Не вгадуйте — перевіряйте на кожній ноді.

10) У нас є ноди Intel і AMD. Чи можемо ми мігрувати одну й ту саму ВМ між ними?

Іноді можна, але це складно. Різниці вендорів, CPUID рядки та набори функцій можуть порушити припущення. Якщо потрібно — використовуйте консервативні базиси і тестуйте міграції. У багатьох середовищах правильна відповідь — «не змішуйте вендори в домені міграції».

Висновок: наступні кроки, що запобігають повторенню

Коли Proxmox VM не запускається після зміни типу CPU, виграшний підхід зазвичай такий: прочитати помилку QEMU, відкотити до останнього відомо робочого стану, запустити ВМ, а потім обрати CPU-базу, що відповідає вашій операційній реальності.

Практичні наступні кроки:

Стандартизувати політику типу CPU за класом ВМ: продуктивні закріплені ВМ можуть використовувати host; мігрувальні ВМ — базову модель, що підтримується всім кластером.
Уникнути прихованих перевизначень: видаліть ризикові args: рядки, якщо не можете їх обґрунтувати і протестувати.
Проведіть інвентар і вирівнювання кластера: моделі CPU, мікрокод, налаштування BIOS для віртуалізації та версії Proxmox/QEMU не повинні випадково розходитись.
Зробіть резервні копії конфігурацій рутинними: збереження файлу конфігурації ВМ перед змінами — це нудна звичка, що скорочує простій.

Одна ідея надійності перефразована від Werner Vogels: Все ламається, тому будуй системи, що очікують відмови, і роби відновлення швидким. Це справедливо і тут. Зміни типу CPU переживані — якщо ставитися до них як до реальних змін у продакшені, а не як до пригоди з випадаючим списком.