Ліцензування VMware ESXi у 2026 році: що змінилося, скільки коштує та кращі альтернативи (включно з Proxmox)

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

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

Якщо ви відповідаєте за продукційну віртуалізацію, то, ймовірно, за останній рік у вас тричі відбувалася одна й та сама розмова: фінанси питають, чому продовження коштує вдвічі дорожче; безпека — чому ви не можете швидше патчити; керівництво — чому ви „ще на VMware“, наче це ваше хобі.

У 2026 році розмова про VMware все менше про функції і більше про «комерційну фізику». Ліцензування змінилося, пакування перероблено, і багато організацій зрозуміли, що „ми просто продовжимо“ — це план з доволі багатьма гострими краями.

Що змінилося в ліцензуванні ESXi (і чому це важливо для операцій)

Головна зміна — не новий планувальник гіпервізора чи складна функція зберігання. Це пакування й комерційні умови. Модель власності та go-to-market VMware зсунулась, і разом із цим змінилась продуктова розповідь: менше окремих перемикачів, більше наборів, наголос на підписках та менше толерантності до „мені потрібна лише одна дрібниця”.

У практичних термінах SRE, зміни в ліцензуванні проявляються як:

Волатильність бюджету: продовження стають менш передбачуваними, особливо коли нове пакування змушує перейти на вищий рівень.
Архітектурний тиск: ліцензування за ядрами або згруповані пакети можуть карати „велику кількість невеликих хостів“ або винагороджувати консолідацію — іноді до небезпечного рівня.
Операційне тертя: ви витрачаєте більше часу на доведення того, що ви запускаєте, ніж на саме запускання.
Ризик дорожньої карти: рішення, які раніше можна було скасувати (ще рік продовжити), стають «липкими» (багаторічні підписки, корпоративні угоди).

Конкретні зрушення, які варто очікувати у 2026

Точні SKU залежать від контракту, регіону й поведінки реселерів, але більшість організацій стикається з тими самими темами:

Економіка з орієнтиром на підписки: довічні ліцензії стали менш центровими, а підпискові набори домінують у закупівлях.
Консолідація наборів: функції, які були окремими, тепер прив’язані до суїтів; ви можете платити за те, чого не використовуєте, і водночас втратити дешевші точки входу.
Розгляд у розрізі ядер стає одиницею болю: якщо ви масштабувалися горизонтально з великою кількістю ядер, ліцензування може рости швидше за ваші доходи.
Право на підтримку має таке ж значення, як ключі ліцензій: робота на непідтримуваних версіях стає більшим операційним ризиком, бо й вендори, й аудитори це враховують.

Цікаві факти та історичний контекст (те, що пояснює сьогодення)

Ось кілька пунктів контексту, які допомагають зрозуміти, чому 2026 виглядає так:

ESX (оригінал) починався як архітектура на базі Linux; ESXi пізніше видалив повну Linux „серверну консоль“, зменшивши поверхню атаки та змінивши спосіб взаємодії адміністраторів із хостами.
vMotion змінив соціальний контракт обслуговування: простої перестали бути „нормальними“, і кластери стали одиницею операцій.
HA/DRS зробили питання «скільки хостів нам потрібно?» настільки ж питанням ліцензування, як і питанням доступності, бо резервна потужність не безкоштовна.
vCenter еволюціонував від зручного інструмента до критичної інфраструктури; багато організацій важко дізналися, що „ми можемо його відновити“ — не план відновлення.
vSAN нормалізував ідею hyperconverged в VMware-середовищах, але також зв’язав архітектуру зберігання з матрицями ліцензування та підтримки.
Зростання KVM зробив „гіпервізор“ меншим фортецею і більш товарним, підштовхуючи вендорів монетизувати управління, безпеку та екосистему.
NVMe та 25/100GbE змістили вузькі місця: сучасні кластери часто обмежені CPU/ліцензіями до того, як стануть I/O-зв’язаними, що змінює стимули до консолідації.
Прийняття хмари привчило керівників очікувати підписну модель виставлення рахунків, навіть якщо вони не люблять рахунок; локальне ПО пішло за грошима.

Операційна реальність: ви не відчуваєте змін у ліцензуванні під час закупівлі. Ви відчуваєте їх о 02:13 під час інциденту, коли хтось питає, чи можна додати ще один хост, щоб зупинити витік.

Короткий жарт №1: Ліцензування — єдина частина стека, що може вивести продукцію з ладу, не торкнувшись жодного пакета.

Що насправді означає «змінилося» для архітектури

Коли комерційна модель штовхає вас до більших, але менших за кількістю серверів боксів, вас потягне до агресивної консолідації. Це може бути правильним — поки не стане ні. Момент, коли ви переходите від „N+1“ до „надії й молитви“, — ваш домен відмови зростає. Один збій хоста стає кризою потужності, а не рутинною подією.

Тож правильне питання не „яке найнижче ліцензування“. Це:

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

Скільки це коштує у 2026: як думати про витрати, не здалеку дивлячись

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

Модель витрат: змінні, що реально рухають стрілку

Для більшості середовищ ці драйвери вартості важливіші за рекламні матеріали:

Загальна кількість фізичних ядер по ліцензованих хостах (або ядра на CPU помножені на кількість CPU).
Кількість хостів (бо підтримка та операційні практики масштабуются з ними, навіть якщо ліцензування базується на ядрах).
Рівень набору (феномен «змушеного оновлення»: ви хотіли лише A, але тепер купуєте A+B+C).
Рівень підтримки (час реакції й покриття визначають, як ви формуєте on-call).
Додаткові компоненти, які на практиці не є опціональними (інтеграція бекапу, моніторинг, зберігання логів, MFA/SSO).
Швидкість зростання: якщо ви додаєте хости щоквартально, підписки накопичуються швидше, ніж ви думаєте.

Перестаньте порівнювати рахунки; порівнюйте архітектури

Коли хтось каже „Proxmox безкоштовний“ або „Hyper-V вже є“, зазвичай порівнюють рядок у кошторисі з цілою системою. Це несерйозно.

Справедливе порівняння включає:

Інженерний час на міграцію та реплатформінг.
Операційні інструменти: моніторинг, бекапи, патчинг, секрети, RBAC, аудитні логи.
Вартість ризику: ймовірність простою, час відновлення та blast radius.
Вартість вендор-локінгу: опції виходу, коли контракт стає неприємним.

Жорстока правда: VMware часто залишається найменш ризиковим варіантом з операційної точки зору, коли ви вже його маєте, уже знаєте та вже побудували процеси навколо нього. Але коли комерційна модель змінюється достатньо, крива ризику перевертається: залишатися стає ризиком.

Як ухвалити рішення про витрати у 2026, не обманюючи себе в таблицях

Використовуйте три сценарії:

Продовження статус-кво: що коштує продовження і збереження поточного стану.
Підігнати + продовжити: зменшити ядра/хости, вивести з експлуатації мертві кластери, стандартизувати SKU, а потім оновити.
Вихід по фазах: перемістити некритичні навантаження першими, залишити VMware для „важких“ речей (legacy appliances, суворе вендорське підтримання) і поступово зменшувати слід.

Третій сценарій — там, де багато зрілих організацій опиняються у 2026. Це не ідеологія. Це управління ризиками.

Ризики аудиту та відповідності: де команди дивуються

Проблеми з ліцензуванням рідко починаються зі зла; вони починаються з припущень: „цей хост лише для DR“, „ті ядра не рахуються“, „цей лабораторний кластер не має значення“, „ми вирівняємо пізніше“. Потім хтось просить доказ, і ви дізнаєтесь, що ваш доказ — застаріла вікі-сторінка, написана інженером, який звільнився через дві реорганізації.

Режими відмов, що провокують неприємні розмови про ліцензії

Тіньові кластери: тест/розробка, що стали продукцією, бо комусь потрібна була „тимчасова“ потужність.
DR, що не холодний: стендбай-хости, які насправді запускають навантаження під час обслуговування, роблячи їх „гарячими“ навіть якщо ви їх так називаєте.
Зсув після оновлення CPU: ви замінили двопроцесорні хости на щільні з великою кількістю ядер і випадково подвоїли експозицію ліцензій.
Функціональний крееп: ви ввімкнули функції (шифрування, distributed switching, просунуте зберігання), що прив’язали вас до вищого рівня.
Розбіжність контракту: закупівля купила одне, інженерія розгорнула інше. Ніхто не бреше. Вони просто живуть у різних всесвітах.

Цитата, варта повісити на стіні

Вернер Вогельс (CTO Amazon) сказав просто: „Усе ламається, весь час“. Якщо ви проектуєте під це, вибір ліцензій та архітектури стає менш емоційним і більш правильним.

Короткий жарт №2: Єдина річ більш постійна, ніж тимчасова VM, — це відділ витрат, у якому вона врешті оселиться.

Швидкий план діагностики: що перевірити першим/другим/третім, щоб швидко знайти вузьке місце

Це мій триажний потік, коли хтось каже „VMware повільний“, а подтекст — „треба мігрувати“. Іноді треба мігрувати. Іноді ви всього лиш одна неправильно підібрана черга від кінця до спокою.

Перше: підтвердіть, що симптом реальний і має межі

Це одна VM, один хост, один датастор чи весь кластер? Якщо ви не можете відповісти, ви не діагностуєте — ви вгадуєте.
Це CPU ready/steal, затримка сховища, дефіцит пам’яті чи втрати в мережі? Виберіть вісь, перш ніж обирати винуватця.
Щось змінилося? Патчі, прошивки, бекап-завдання, снапшоти, нові агенти безпеки, новий драйвер NIC. Звали провину на зміни, поки не доведете інше.

Друге: ізолюйте клас ресурсів

Ознаки навантаження на CPU: високий CPU ready time, черги виконання, часті co-stop на SMP VM.
Ознаки дефіциту пам’яті: свопінг, ballooning, тиск на стиснення пам’яті, гострі сторінгові шторми.
Ознаки проблем зі сховищем: тривалі стрибки затримки датастору, насичення черги, трясіння шляхів (path thrashing).
Ознаки проблем у мережі: втрати, повторні передачі, насичення pNIC, невідповідний MTU, неправильна конфігурація LACP.

Третє: доведіть, чи вузьке місце — „платформа“, чи „дизайн“

Якщо ваш дизайн крихкий, зміна гіпервізора його не виправить. Те саме навантаження просто зазнає фіаско з іншим акцентом.

Перевірте, чи ви не працюєте «на межі» (немає запасу для подій HA).
Перевірте розповсюдження снапшотів і накладки бекапів.
Перевірте макет сховища (занадто багато VM на датасторі, невірний RAID/ZFS recordsize, рулетка тонкого провізування).
Перевірте мережу: MTU, offloads, сумісність драйверів/прошивок.

Практичні завдання з командами: виміряти, вирішити та уникнути самонанесеної шкоди

Ось практичні перевірки, які ви можете виконати сьогодні. Деякі специфічні для ESXi (через SSH і shell ESXi). Інші з Linux-нод, які, ймовірно, у вас уже є (сервери бекапу, моніторингу), бо реальні операції — мультиплатформені. Кожне завдання включає: команду, що означає вивід, і яке рішення це визначає.

Завдання 1: Визначити версію/build ESXi на хості (базовий рівень підтримки та вразливостей)

cr0x@server:~$ ssh root@esxi-01 'vmware -vl'
VMware ESXi 8.0.2 build-23305546
VMware ESXi 8.0.2 GA

Що означає вивід: Ви на ESXi 8.0.2 з певним build. Це важливо для права на підтримку, сумісності драйверів та чи ви в рамках матриць підтримки постачальника.

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

Завдання 2: Інвентаризація фізичних CPU ядер (це часто одиниця ліцензування)

cr0x@server:~$ ssh root@esxi-01 'esxcli hardware cpu global get'
   Package Count: 2
   Core Count: 32
   Core Count Per Package: 16
   Thread Count: 64
   Thread Count Per Package: 32
   HV Support: 3
   HV Replay Support: 1

Що означає вивід: Цей хост має 32 фізичних ядра загалом. Ігноруйте потоки для дискусій про ліцензування, якщо ваш контракт не каже інакше.

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

Завдання 3: Підтвердити, які ESXi-хости підключені та здорові (щоб уникнути „фантомного“ ліцензування)

cr0x@server:~$ ssh root@vcenter-01 'vim-cmd vmsvc/getallvms | head'
Vmid   Name              File                      Guest OS        Version   Annotation
1      vcenter-01        [vsanDatastore] ...        vmwarePhoton64  vmx-19
12     backup-proxy-01   [ssd01] backup-proxy...    ubuntu64Guest   vmx-19
34     app-prod-02       [ssd02] app-prod-02...     centos64Guest   vmx-19

Що означає вивід: Ви перелічуєте зареєстровані VM. Якщо бачите несподівані „lab“ або „тимчасові“ навантаження, вони не теоретичні — вони споживають потужність і, можливо, ліцензовані функції.

Рішення: Позначте та класифікуйте VM (prod/dev/lab/DR). Найшвидше скорочення витрат — видалити те, що більше не потрібно — після перевірки, що воно справді мертве.

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

cr0x@server:~$ ssh root@esxi-02 'find /vmfs/volumes -name "*.vmsn" -o -name "*-delta.vmdk" | head'
/vmfs/volumes/datastore1/app-prod-02/app-prod-02-000002-delta.vmdk
/vmfs/volumes/datastore1/app-prod-02/app-prod-02-Snapshot2.vmsn
/vmfs/volumes/datastore2/db-prod-01/db-prod-01-000001-delta.vmdk

Що означає вивід: Існують delta-диски і файли пам’яті снапшотів. Довготривалі снапшоти можуть руйнувати латентність, збільшувати використання сховища і ламати RPO-очікування.

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

Завдання 5: Швидка перевірка латентності датастору (чи сховище — вузьке місце?)

cr0x@server:~$ ssh root@esxi-01 'esxtop -b -n 2 -d 2 | grep -E "CMDS/s|DAVG/cmd|KAVG/cmd|GAVG/cmd" | head'
CMDS/s   DAVG/cmd   KAVG/cmd   GAVG/cmd
120.00   8.12       0.44       8.56
135.00   22.50      0.60       23.10

Що означає вивід: GAVG — латентність, яку бачить гість. Стрибки понад ~20ms у стійкому режимі часто корелюють з «усе здається повільним», особливо для баз даних.

Рішення: Якщо GAVG стрибає, не звинувачуйте спочатку гіпервізор. Дослідіть масив зберігання, чергу запитів, multipathing і «шумних сусідів».

Завдання 6: Підтвердити multipath і стан шляхів (безшумне погіршення сховища)

cr0x@server:~$ ssh root@esxi-01 'esxcli storage core path list | head -n 12'
fc.20000024ff2a1b33:vmhba2:C0:T0:L12
   Runtime Name: vmhba2:C0:T0:L12
   Device: naa.600508b1001c3a2f9e3f0d2b7f3b0001
   Device Display Name: DGC Fibre Channel Disk (naa.600508b1...)
   Path State: active
   Adapter: vmhba2
   Target Identifier: 20000024ff2a1b33
   LUN: 12

Що означає вивід: У вас є активні шляхи. Якщо ви бачите «dead» або «standby», де очікується active/active, продуктивність і стійкість можуть бути скомпрометовані.

Рішення: Виправте pathing перед будь-якими іншими змінами. Міграція не виправить зламаний SAN-фабрикат.

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

cr0x@server:~$ ssh root@esxi-03 'df -h /vmfs/volumes/* | head'
Filesystem                         Size   Used   Available Use% Mounted on
/vmfs/volumes/datastore1           9.8T   9.1T     700G    93% /vmfs/volumes/datastore1
/vmfs/volumes/datastore2           7.3T   6.0T     1.3T    82% /vmfs/volumes/datastore2

Що означає вивід: datastore1 зайнятий на 93%. Саме там снапшоти люблять вмирати і де продуктивність сховища починає поводитися дивно.

Рішення: Впровадьте мінімальні пороги вільного місця (звично 15–20%) і припиніть overcommit без оповіщення. Якщо ви плануєте міграцію, вам потрібен запас місця.

Завдання 8: Перевірити NTP/дрейф годинника (бо Kerberos і логи — примхливі)

cr0x@server:~$ ssh root@esxi-01 'esxcli system time get'
   Local Time: 2025-12-28 03:14:06
   Universal Time: 2025-12-28 03:14:06

cr0x@server:~$ ssh root@esxi-01 'esxcli system ntp get'
   Enabled: true
   Servers: 10.0.0.10, 10.0.0.11

Що означає вивід: NTP увімкнено і вказано на внутрішні сервери.

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

Завдання 9: Перевірити ballooning/свопінг на хості (дефіцит пам’яті)

cr0x@server:~$ ssh root@esxi-02 'esxtop -b -n 2 -d 2 | grep -E "MCTL|SWCUR|MEMSZ" | head'
MCTL(GB)  SWCUR(GB)  MEMSZ(GB)
0.00      0.00       512.00
12.50     4.00       512.00

Що означає вивід: Ballooning (MCTL) і свопінг (SWCUR) ненульові в другому зразку — цей хост під тиском пам’яті.

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

Завдання 10: Підтвердити стан vSwitch / vmnic (мережеві проблеми виглядають як проблеми додатків)

cr0x@server:~$ ssh root@esxi-01 'esxcli network nic list'
Name    PCI Device    Driver  Admin Status  Link Status  Speed  Duplex  MAC Address
vmnic0  0000:3b:00.0  i40en   Up            Up           25000  Full    3c:fd:fe:aa:bb:01
vmnic1  0000:3b:00.1  i40en   Up            Down           0     Half   3c:fd:fe:aa:bb:02

Що означає вивід: vmnic1 адміністративно ввімкнений, але лінк — down. Це може зменшити дублювання або порушити очікування LACP.

Рішення: Виправте фізичні лінки перед тим, як ганятися за „нестабільністю VMware“. Половина кластера на одній нозі — це не проблема платформи.

Завдання 11: Виміряти наклад бекапів (бекап — це робоче навантаження на продуктивність)

cr0x@server:~$ ssh root@backup-01 'systemctl status veeamservice | head -n 12'
● veeamservice.service - Veeam Service
     Loaded: loaded (/lib/systemd/system/veeamservice.service; enabled)
     Active: active (running) since Sun 2025-12-28 00:01:10 UTC; 3h 12min ago
   Main PID: 2143 (veeamservice)
     Tasks: 34
     Memory: 1.2G

Що означає вивід: Сервіс бекапу активний. Це не означає, що він здоровий, але підтверджує розклад і час роботи.

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

Завдання 12: Оцінити CPU/пам’ять VM із Linux-гість (підбір розміру для будь-якої платформи)

cr0x@server:~$ ssh cr0x@app-prod-02 'uptime; free -h; nproc'
 03:18:40 up 47 days,  6:22,  2 users,  load average: 1.12, 0.98, 0.91
               total        used        free      shared  buff/cache   available
Mem:            32Gi        9.1Gi        2.3Gi        1.0Gi         21Gi         22Gi
Swap:          4.0Gi          0B        4.0Gi
16

Що означає вивід: VM має 16 vCPU і 32GiB RAM; використовує ~9GiB RAM і помірне навантаження CPU. Імовірно, завелика.

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

Завдання 13: Перевірити затримку зберігання з Linux-гість (контрольна перевірка з боку гостя)

cr0x@server:~$ ssh cr0x@db-prod-01 'iostat -x 1 3 | sed -n "1,20p"'
Linux 6.5.0 (db-prod-01) 	12/28/2025 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.21    0.00    2.10    9.88    0.00   81.81

Device            r/s     w/s   rMB/s   wMB/s avgrq-sz avgqu-sz await r_await w_await  svctm  %util
sda             45.0    30.0     5.1     8.3    355.2     2.14  27.4    19.2    39.8   1.9   14.3

Що означає вивід: await близько 27ms вказує на затримку зберігання, видиму всередині VM.

Рішення: Якщо гості бачать високий await, а хости також показують латентність, це реальне сховище. Якщо лише гості бачать це, перевірте файлову систему гостя, планувальник I/O або «шумний» процес в гості.

Завдання 14: Перевірити стан пулу ZFS на вузлі-кандидаті Proxmox (якщо розглядаєте HCI)

cr0x@server:~$ ssh root@pve-01 'zpool status -x'
all pools are healthy

Що означає вивід: На даний момент немає відомих помилок ZFS.

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

Завдання 15: Перевірити стан кластера Ceph (якщо альтернатива використовує розподілене зберігання)

cr0x@server:~$ ssh root@pve-01 'ceph -s'
  cluster:
    id:     8b1b2c42-1a72-4c8d-8d4a-0a7c1c6b5d1a
    health: HEALTH_WARN
            1 osds down
  services:
    mon: 3 daemons, quorum pve-01,pve-02,pve-03 (age 2h)
    mgr: pve-01(active, since 2h)
    osd: 9 osds: 8 up (since 5m), 9 in (since 2h)
  data:
    pools:   2 pools, 128 pgs
    objects: 2.1M objects, 8.3 TiB
    usage:   24 TiB used, 48 TiB / 72 TiB avail
    pgs:     126 active+clean, 2 active+degraded

Що означає вивід: Кластер має попередження: один OSD down, деякі PG деградовані. Продуктивність і стійкість знижені до завершення відновлення.

Рішення: Якщо ви не можете терпіти деградовані стани операційно (оповіщення, реагування on-call, запасні частини), не вибирайте розподілене сховище для найкритичнішого шару з першого дня.

Завдання 16: Конвертувати та перевірити образ диска VMware для тестування міграції (не вгадуйте; тестуйте)

cr0x@server:~$ qemu-img info disk.vmdk
image: disk.vmdk
file format: vmdk
virtual size: 200 GiB (214748364800 bytes)
disk size: 78 GiB

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 disk.vmdk disk.qcow2
    (100.00/100%)

cr0x@server:~$ qemu-img info disk.qcow2
image: disk.qcow2
file format: qcow2
virtual size: 200 GiB (214748364800 bytes)
disk size: 79 GiB

Що означає вивід: Ви верифікували формат джерела і конвертували у qcow2 для платформ на базі KVM (наприклад, Proxmox).

Рішення: Використайте це, щоб виконати ізольований тест завантаження репрезентативної VM. Якщо вона не завантажується коректно — ви дешево отримали цінну інформацію.

Завдання 17: Перевірити відповідність прошивок/драйверів на Linux-хостах, що використовуються для віртуалізації (щоб уникнути «таємничих перезавантажень»)

cr0x@server:~$ sudo dmesg -T | grep -E "firmware|Microcode|IOMMU" | tail -n 8
[Sun Dec 28 02:41:11 2025] microcode: updated early: 0x2c -> 0x31, date = 2024-11-12
[Sun Dec 28 02:41:12 2025] DMAR: IOMMU enabled
[Sun Dec 28 02:41:12 2025] AMD-Vi: Interrupt remapping enabled

Що означає вивід: Мікрокод оновлено і IOMMU увімкнено — важливо для стабільності та функцій pass-through.

Рішення: Якщо ви мігруєте на KVM, переконайтеся, що мікрокод і налаштування BIOS готові для продакшену. „Налаштуємо пізніше“ стає „чому хост перезавантажився під навантаженням?“

Три корпоративні міні-історії з поля бою

Міні-історія №1 (інцидент через неправильне припущення): «DR — це не стиль життя»

Середня SaaS-компанія мала первинний кластер VMware і „DR-кластер“ у дешевшому колокаційному центрі. DR-проєкт починався як холодний стендбай: мінімум хостів, достатньо сховища для реплік і план розкрутити додаткову потужність під час катастрофи.

Але реальність зробила своє. DR-сайт став зручним місцем для запуску „тимчасових“ пакетних робіт і кількох некритичних внутрішніх сервісів. Ніхто не хотів ризикувати продукційною потужністю, тож вони тихо перемістили навантаження до DR „на місяць“. Місяці стали роком.

Неправильне припущення: фінанси й закупівлі все ще трактували DR як просто неактивну потужність. Інженерія — як розширення продукції. Під час переговорів про продовження вендор запросив інвентар середовища. Інвентар показав DR-кластер із реальними навантаженнями та увімкненими функціями, що відповідали продукційному шаблону.

Інцидент був не в аудиті сам по собі. Інцидент був в операційному метушні, що наступив: керівництво вимагало негайно евакуювати навантаження з DR, щоб зберегти наратив „холодного стендбаю“. Вони агресивно намагалися vMotion та Storage vMotion через обмежений WAN, у робочий час, на кластері, що вже працював на межі.

Латентність стрибнула, бекапи відстали, і одна база даних потрапила в шторм консолідації снапшотів, що потягнуло датастор у червону зону. Наслідок: вплив для користувачів, в постмортемі атрибутований «неочікуваній латентності сховища». Справжня причина — провал управління: у них не було наведеного визначення DR і запобіжників, щоб воно не стало продукцією.

Міні-історія №2 (оптимізація, що обернулася проти): «Консолідація: тихий убивця SLO»

Команда корпоративного IT отримала пропозицію на оновлення, що змусила керівництво раптом зацікавитись архітектурою віртуалізації. Команда запропонувала консолідацію: менше хостів, більші CPU, більше ядер на коробку. Таблиця виглядувала чудово. Схеми в стойці були охайні. Усі аплодували.

Вони перейшли від комфортного кластера з запасом до більш щільного дизайну. HA все ще „працювало“ в сенсі, що VM включалися десь після збою хоста. Але продуктивність під час відмови була жахливою: CPU ready time зріс, черги сховища заповнилися, і кілька латентно-чутливих сервісів почали таймаутитись під навантаженням.

Потім рутинне оновлення прошивки вивело один хост з ладу. Нічого драматичного — поки DRS не перебалансував. Кластер фактично працював у режимі надзвичайної потужності кілька годин. Користувачі скаржились, інциденти накопичувались, і команда виявила, що вони спроектували себе в постійний «режим деградації».

Оптимізація, що обернулася проти, — не сама консолідація. А неспроможність розглядати запас потужності як вимогу, а не як розкіш. Консолідація заощадила на ліцензіях і створила податок на доступність, що сплачувався під час кожного вікна обслуговування та кожного інциденту.

Вони відновились, додавши ще один хост (так, те, чого намагалися уникнути) і підігнавши надто великі VM. Остаточний дизайн коштував трохи більше, ніж „ідеальна“ таблиця, але значно менше за операційну метушню.

Міні-історія №3 (нудна, але правильна практика, що врятувала): «Інвентар — це фіча»

Одна медична організація мала репутацію консервативної — ввічливий спосіб сказати „вони не люблять сюрпризів“. Вони підтримували щомісячний автоматичний експорт інвентарю віртуалізації: специфікації хостів, кількість ядер, увімкнені функції, кількість VM по категоріях і тренди споживання сховища.

Це була нудна робота. За неї не давали оплесків. Але це дозволяло їм швидко відповідати на складні питання: що ми запускаємо, де це живе і скільки коштує підтримка цього в роботі?

Коли змінювалось пакування ліцензій, вони не панікували. Вони прогнали сценарії на основі інвентаря, знайшли кластери з невикористаною потужністю і перемістили навантаження з низьким ризиком з преміальних функцій. Вони також знайшли „легасі“ VM, за якими ніхто не відповідав, і вивели їх після верифікації впливу на бізнес із командами застосунків.

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

Практика, що врятувала день, — не продукт. Це дисципліна: інвентар, класифікація і стабільне управління потужністю.

Кращі альтернативи у 2026 (включно з Proxmox), з компромісами

Альтернативи стали реальними не тому, що VMware перестав добре віртуалізувати, а тому, що ринок перестав приймати одно-вендорну „данину“ як неминучу. Ваша найкраща альтернатива залежить від того, на що ви реально покладаєтесь: семантика HA, жива міграція, інтеграція зі сховищем, екосистема бекапів, мережеві можливості та людський фактор — хто зможе це експлуатувати о 03:00.

1) Proxmox VE (KVM + QEMU + LXC): прагматичний фаворит

Proxmox популярний, бо простий: KVM для VM, LXC для контейнерів, кластеринг, жива міграція і кілька бекендів сховища. Це не „безкоштовний VMware“. Це інша система з інакшими гострими краями.

Де Proxmox сильний:

Контроль витрат: підписка здебільшого про підтримку, а не про блокування функцій, і ви можете обирати рівні.
Операційна прозорість: під капотом — Linux. Дебагінг не вендорський магічний ящик.
Гнучке зберігання: ZFS для локальної стійкості, Ceph для розподіленого сховища, NFS/iSCSI для зовнішніх масивів.
Швидке ітераційне оновлення: оновлення та спільнотні практики розвиваються швидко, екосистема жива.

Де Proxmox кусає:

Ви більше відповідаєте за інтеграцію: глибина RBAC, інтеграція IAM і деякий корпоративний робочий процес вимагають реальних інженерних зусиль.
Правильність сховища — на вас: ZFS і Ceph потужні, але вони не „налаштував і забув“. Вони винагороджують компетентність і карають оптимізм.
Підтримка вендорних appliance: деякі сторонні вендори все ще підтримують лише VMware і можуть використати це, щоб відмовити в тикетах.

Моя думка: Proxmox — найкращий варіант «вийти з в’язниці VMware» для команд, готових серйозно експлуатувати Linux. Якщо ваша організація ставиться до Linux як до дивного хобі — виправте це спочатку.

2) Microsoft Hyper-V / Azure Stack HCI: корпоративний стандартизатор

Hyper-V рідко захоплює. Це комплімент. Для середовищ, орієнтованих на Windows, це може бути шлях найменшого опору, особливо якщо ви вже використовуєте Microsoft identity і інструменти управління.

Сильні сторони: добра інтеграція з Windows, зріла база віртуалізації, великий пул операційних кадрів і звичність закупівель.

Слабкі сторони: гостьові Linux часто працюють нормально, але іноді виглядають другокласно в операційному сенсі, а «ціла історія рішення» може втягнути вас у суміжні Microsoft-стеки, які ви не планували впроваджувати.

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

3) Nutanix AHV: інтегрована платформа, інша економіка

Nutanix продає платформу: обчислення + сховище + управління. AHV — гіпервізор. Досвід може бути плавним, і операційно це цілісний продукт.

Сильні сторони: інтегроване управління, сильна HCI-історія, хороші day-2 операції для багатьох середовищ.

Слабкі сторони: ви міняєте одну вендор-історію на іншу. Вартість виходу й складність контрактів реальна; ви купуєте екосистему, а не лише гіпервізор.

Для кого підходить: команди, що хочуть упаковану платформу і комфортно ставляться до залежності від вендора, якщо це знижує операційне навантаження.

4) Чистий KVM/libvirt (DIY): максимальний контроль, максимальна відповідальність

Так, можна запускати KVM із libvirt, Ansible і обраним бекендом зберігання. Багато провайдерів так роблять. Це потужно й економічно вигідно.

Сильні сторони: повний контроль, мінімальні ліцензійні тертя, глибокі можливості автоматизації.

Слабкі сторони: ви будуєте власний шар „як vCenter“ — моніторинг, RBAC, робочі процеси, запобіжники. Якщо команда недоукомплектована, DIY перетворюється на „зроби сам вночі“.

Для кого підходить: команди з сильною Linux/SRE зрілістю і чіткою культурою автоматизації.

5) Керована хмара (IaaS): ядерна опція, що іноді правильна

Переміщення навантажень у хмарний IaaS — це не стільки альтернатива VMware, скільки інший модель операцій. Це може знизити управління апаратурою і гіпервізором, але ви платите в дизайні мережі, контролі витрат і обмеженнях сервісів.

Сильні сторони: еластичність, керовані сервіси і менше клопоту по життєвому циклу обладнання.

Слабкі сторони: несподівані витрати, гравітація даних і нові режими відмов (IAM, ліміти, інциденти на рівні регіону).

Для кого підходить: команди, що можуть дисципліновано виконувати cloud FinOps і мають навантаження, що підходять для керованих сервісів.

А що якщо залишити VMware і просто адаптуватися?

Іноді це правильний крок. Якщо у вас є:

глибока операційна зрілість VMware,
стабільна команда платформи,
критичні вендорні appliance, прив’язані до заяв підтримки VMware,
і домовлений контракт, з яким ви можете жити,

…тоді продовжуйте, стандартизуйте і припиніть кровотечу. Але робіть це на основі даних і все одно побудуйте план виходу. „Ми ніколи не підемо“ — це не стратегія; це запис заручника в Excel.

Поширені помилки: симптом → корінь проблеми → виправлення

1) Симптом: пропозиція на продовження вибухає після оновлення апаратури

Корінь: ви значно збільшили кількість ядер на хості, а ваша модель ліцензування масштабується з ядрами або мінімумами наборів.

Виправлення: змоделюйте вплив ліцензування перед оновленням CPU. Розгляньте менше ядер з вищою частотою, якщо це підходить за продуктивністю, або перерозподіл кластерів (залиште хости з великою кількістю ядер для щільного dev/test).

2) Симптом: „VMware повільний“ після консолідації

Корінь: ви прибрали запас; події HA і обслуговування тепер змушують конкуренцію ресурсів (CPU ready, черги сховища).

Виправлення: ввести політику потужності: N+1 запас плюс буфер продуктивності. Підігнати розмір VM. Планувати руйнівні роботи (бекапи, сканування) з урахуванням потужності кластера.

3) Симптом: vMotion працює, але продуктивність стає нестабільною

Корінь: мережна надлишковість скомпрометована (вимкнені лінки, неправильно налаштований LACP, невідповідний MTU), або шляхи сховища деградували.

Виправлення: перевірити стан NIC і multipath сховища. Ставте мережу і сховище як першокласні залежності, а не „чужу проблему“.

4) Симптом: бекапи раптом тривають удвічі довше і впливають на продукцію

Корінь: нашарування снапшотів, невідповідності CBT або збільшена паралельність бекапів без запасу сховища.

Виправлення: аудит снапшотів, налаштуйте паралельність бекапів і ізолюйте I/O бекапів. Не запускайте „усі задачі опівночі“, якщо ви любите самосаботаж.

5) Симптом: тести міграції на Proxmox завантажуються, але додатки поводяться дивно

Корінь: драйвери гостей (VMware Tools проти virtio), зміни імен NIC, різниці контролерів сховища або різниці синхронізації часу.

Виправлення: стандартизувати драйвери гостя і верифікувати завантаження + мережу + продуктивність диска за тест-планом. Розглядайте підготовку гостя як окремий робочий потік міграції, а не думку „потім“.

6) Симптом: керівництво думає „ми просто перемкнемо гіпервізор за квартал“

Корінь: недооцінка складності міграції: мережа, сховище, бекапи, моніторинг і заяви підтримки вендора.

Виправлення: представте поетапний план з категоріями навантажень і критеріями прийняття. Прив’яжіть терміни до реальності: контроль змін, вікна обслуговування і плани відкату.

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

План A: продовжити VMware, не потрапивши в фінансову чи операційну пастку

Інвентаризувати все: хости, ядра, кластери, увімкнені функції, кількість VM по категоріях.
Підігнати розмір VM: зменшити vCPU і RAM там, де безпечно; вивести мертві навантаження.
Видалити випадкові преміальні функції: якщо вам не потрібні просунуті мережеві/сховищні функції скрізь, не використовуйте їх повсюдно.
Перерахувати математику запасу: доведіть, що ви переживете відмову хоста і все ще відповідатимете SLO.
Вести переговори з варіантами: йдіть з реальною фазовою програмою. Вендори по-іншому ціниють, коли вірять, що ви можете піти.
Документувати позицію по відповідності: щомісячні експорти і записи змін.

План B: зменшити слід VMware, залишивши критичне стабільним

Класифікувати навантаження у: легкі (stateless apps), середні (стандартні Linux/Windows сервери), важкі (вендорні appliance, latency-sensitive БД).
Обрати альтернативну платформу для „легких“ навантажень першими (часто Proxmox або Hyper-V).
Побудувати операційну паритетність: моніторинг, бекапи, патчинг, контролі доступу, логування.
Запустити пілот з 10–20 репрезентативних VM; верифікувати продуктивність і відновлення (тести відновлення, тести відмови).
Перемістити некритичну продукцію далі; зберігати плани відкату і паралельний запуск там, де можливо.
Тримати VMware для важких навантажень, доки альтернатива не доведе себе або вендори не оновлять заяви підтримки.

План C: вирішальна міграція з VMware (тільки якщо у вас є персонал)

Заморозити архітектурні зміни в вікно міграції; припинити „покращувати“ все одночасно.
Стандартизувати мережевий дизайн (VLAN, MTU, маршрутизація, firewalling) перед переміщенням навантажень.
Встановити тести прийняття міграції: завантаження, здоров’я застосунку, латентність, бекап/відновлення, моніторинг, логування, SSO доступ.
Автоматизувати якомога більше (конвертація, провізіонування, валідація), щоб зменшити людський фактор.
Проводити хвильові cutover-и з чіткими критеріями відкату. Жодних героїчних маневрів.
Чисто вивести з експлуатації: видалити старі хости, відкликати доступи, оновити CMDB і припинити платити за привидів.

Поширені питання

1) Чи ESXi і досі технічно відмінний у 2026?

Так. Більшість проблем, якими звинувачують ESXi, — це питання потужності, сховища, мережі чи процесів. Біль 2026 — комерційний і операційний ризик, не планувальник CPU.

2) Яка найбільша пастка ліцензування, у яку потрапляють команди?

Незнання того, що вони реально запускають: кількість ядер, увімкнені функції і „тимчасові“ кластери. Інвентар — протиотрута.

3) Чи варто нам консолідувати хости, щоб зменшити ліцензії?

Іноді варто. Роби це лише після доведення, що ви переживете збій хоста і обслуговування без життя в умовах конкуренції ресурсів. Консолідація без запасу — атака на SLO.

4) Чи Proxmox — реальний варіант для підприємства?

Так, якщо ви добре оперуєте Linux і готові взяти на себе більше інтеграції. Він особливо сильний для загальної віртуалізації і для команд, що цінують прозорість.

5) Чи Proxmox „безкоштовний“?

Програмне забезпечення можна використовувати без підписки, але продакшн-команди повинні бюджетувати підтримку і інженерний час на побудову операційних запобіжників.

6) Що з замінами vSAN?

Поширені патерни: зовнішнє сховище (iSCSI/FC/NFS), ZFS на локальних дисках для менших кластерів або Ceph для розподіленого сховища. Кожне має різні режими відмов і операційні вимоги.

7) Чи можна мігрувати, просто конвертувавши диски?

Конвертація диска — легка частина. Складніше — драйвери гостей, мережа, бекап/відновлення, моніторинг, доступ і доведення роботи відновлення.

8) Який найбезпечніший підхід до міграції?

Фазований: перемістіть легкі навантаження першими, побудуйте операційну паритетність, а потім беріть важчі категорії. Залишайте VMware для вендорних appliance, доки не матимете план підтримки.

9) Як уникнути паніки через аудит?

Автоматизуйте щомісячні експорти інвентарю, маркуйте навантаження по категоріях/власниках і впровадьте контроль змін при розширенні кластерів і ввімкненні функцій.

10) Якщо ми лишаємося на VMware, що слід робити інакше у 2026?

Вести це як продукт: SLO по потужності, стандарти конфігурації, регулярний інвентар, гігієна снапшотів і архітектурні огляди, прив’язані до реальності ліцензування.

Висновок: наступні кроки, що дійсно знижують ризик

У 2026 році ліцензування VMware ESXi — це не просто подія закупівлі. Це архітектурне обмеження і множник операційного ризику. Ви не зможете його пересперечити, але можете перевершити інженерною роботою.

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

Побудуйте реальний інвентар (ядра, хости, функції, категорії VM). Трактуйте його як production-дані.
Підігнати і почистити: снапшоти, мертві VM, надмірно великі гості, датастори на 90%+.
Переоцініть запас: якщо консолідація викликає конкуренцію, перестаньте називати це оптимізацією.
Обрати вихідну рампу, навіть якщо ви продовжуєте: зробіть пілот Proxmox або Hyper-V з некритичними навантаженнями і побудуйте операційну паритетність.
Приймайте рішення на основі тестів, а не ідеології. Тести завантаження, відновлення, відмови — потім переговори або міграція.

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