Віртуальна машина Windows на Proxmox не бачить диск: правильно встановіть драйвери VirtIO

Під час виконання інсталяції Windows VM успішно завантажується з ISO, а потім в діалогі «Куди ви хочете встановити Windows?» список порожній. Або вже встановлена Windows раптово повідомляє про відсутність завантажувального пристрою після того, як ви «тільки-но» переключилися на VirtIO, бо хтось сказав, що це швидше. Тут люди зазвичай панікують, перезавантажують тричі та звинувачують ZFS, RAID-карту або місяць.

Насправді причина зазвичай прозаїчна: Windows не вміє спілкуватися з віртуальним контролером зберігання, який ви представили. Вирішується це представленням правильного контролера та встановленням відповідного драйвера VirtIO у потрібний момент і в правильному середовищі Windows (Setup проти встановленої ОС). Зробіть це акуратно — отримаєте швидкі диски, менше дивних переривань та передбачувану поведінку під навантаженням.

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

Якщо вам потрібне правило 80/20 — ось воно. Виконуйте зверху вниз. Зупиніться, щойно знайдете невідповідність.

Спочатку: ви в Windows Setup чи в установленій Windows?

• Windows Setup (інсталятор): потрібно натиснути «Завантажити драйвер» і вказати VirtIO ISO, або тимчасово використати контролер, який Windows вже знає (SATA).
• Вже встановлена Windows: драйвери VirtIO потрібно встановити до перемикання диска/контролера, інакше ризикуєте INACCESSIBLE_BOOT_DEVICE.

По-друге: який контролер ви обрали в Proxmox?

• VirtIO SCSI (рекомендовано) з virtio-scsi-single у Proxmox: потребує драйвера vioscsi.
• VirtIO Block: потребує драйвера viostor.
• SATA: Windows бачить його без драйверів VirtIO; повільніше і менш «cloud-native», але відмінно підходить як тимчасовий bootstrap.

По-третє: чи змонтовано VirtIO ISO і чи видно його у VM?

• Змонатуйте virtio-win.iso як другий CD/DVD-привід у Proxmox.
• У «Load driver» Setup переходьте до правильної папки для вашої версії Windows (зазвичай \vioscsi\w11\amd64, \vioscsi\w10\amd64 або серверні еквіваленти).

По-п’яте: нюанси secure boot і підписування драйверів

• Windows 11 + Secure Boot: поточні драйвери VirtIO підписані, але старі ISO можуть спричиняти проблеми. Використовуйте свіжий VirtIO ISO і уникайте «якого-небудь ISO зі старого шару».
• Якщо ви використовуєте UEFI/OVMF, тримайте це послідовно. Зміна типу BIOS під час процесу змінює механіку завантаження.

По-п’яте: підтвердіть, що Proxmox справді представляє диск

• Так, це очевидно. Але все одно перевірте конфігурацію VM і стан сховища Proxmox. Відсутній або заблокований том виглядає точно як «немає диска» з боку гостьової ОС.

Жарт #1: Інсталятор Windows наче вчитель на вході: якщо ваш драйвер зберігання не в списку — ваш диск не проходить.

Цікаві факти й контекст (чому це повторюється)

• VirtIO виник як оптимізація ери KVM/QEMU: це паравіртуалізована модель пристрою, створена щоб уникнути великого накладного емулювання.
• Windows не включає драйвери VirtIO для зберігання за замовчуванням, саме тому в Linux «просто працює», а в Windows — ні.
• IDE досі використовується здебільшого для сумісності: повільно, обмежено і корисно передусім для старих інсталяторів або як fallback для CD-ROM.
• VirtIO SCSI існує не просто так: він дає SCSI-абстракцію поверх VirtIO і підтримує функції на кшталт TRIM/UNMAP у віртуалізованих стеків за правильної конфігурації.
• VirtIO Block проти VirtIO SCSI — це не просто назви: для них різні Windows-драйвери (viostor проти vioscsi) і різна поведінка в певних навантаженнях.
• Вбудовані драйвери Microsoft віддають перевагу широкій сумісності, тому SATA/AHCI працює скрізь, а VirtIO — ні.
• Windows Setup — це окреме невелике середовище ОС: завантаження драйвера в Setup не означає автоматичне «підготовлення» встановленої Windows (і навпаки).
• Зміни контролера — критичні для завантаження у Windows: драйвери зберігання мають бути присутні та налаштовані на ранній старт, інакше отримаєте помилки завантаження.
• За замовчуванням Proxmox з часом покращився, але багато блогів досі цитують старі рекомендації (наприклад, використання застарілих моделей або дивних BIOS-настроювань).

Що означає «не бачить диск» на Proxmox

«Windows не бачить диск» — це симптом. Під капотом може відбуватися одне з наступного:

• Диск фактично не прикріплений (помилка конфігурації VM, проблема сховища, неправильний ID VM, видалений том, заблокований том або диск прикріплено на шині, з якої ваше ПЗ прошивки не завантажує).
• Диск прикріплений, але у Windows немає драйвера для контролера (класична ситуація з VirtIO під час Setup).
• Диск прикріплений і драйвер є, але Windows ще не може ним користуватися (драйвер не завантажений у WinPE/Setup, неправильна архітектура папки, проблема з підписуванням драйвера).
• Диск видно, але ним неможливо користуватися (політика офлайн-диску, невідповідність GPT/MBR під певними режимами завантаження, Storage Spaces або застаріла метадані).
• Диск видно, але продуктивність катастрофічна (неправильний режим кешування, відсутній iothread, невідповідність конфігурації QEMU або насичення сховища хоста).

Отже план простий: доведіть, що Proxmox представляє потрібний пристрій, доведіть, які драйвери завантажує Windows, а потім зв’яжіть обидві сторони правильним пакетом VirtIO.

Виберіть правильну віртуальну модель зберігання (припиніть імпровізувати)

Ось що я рекомендую для більшості production Windows VM на Proxmox:

• Шина/контролер: VirtIO SCSI з virtio-scsi-single (Proxmox GUI: SCSI Controller → «VirtIO SCSI single»).
• Тип диска: SCSI диск (наприклад, scsi0).
• Кеш: Зазвичай «Write back» лише якщо ви розумієте ризики; інакше за замовчуванням «None» (як правило безпечніше). Якщо ви на ZFS, будьте особливо обережні з подвійним кешуванням і семантикою відмов.
• IO thread: Увімкніть I/O thread для зайнятих дисків. Часто це зменшує стрибки латентності під змішаним навантаженням.
• Trim/Discard: Увімкніть discard для тонкопровізованого сховища або пулів на SSD, коли хочете звільняти місце (і переконались, що підкладка це коректно підтримує).

Коли я не використаю VirtIO SCSI?

• Під час bootstrap інсталятора: якщо не хочете завантажувати драйвери під час Setup, використайте SATA для інсталяції, а потім переключіться пізніше (але робіть це безпечно).
• Дуже старі версії Windows: драйвери існують, але операційні ризики зростають. Якщо у вас надто стара ОС, ви вже робите непрості вибори.

VirtIO Block може бути прийнятним, але VirtIO SCSI зазвичай — «безпечний вибір» у світі Proxmox, бо краще працює з множинними дисками, чергуванням та типовими операційними сценаріями.

Нова інсталяція: завантажте драйвери VirtIO під час Windows Setup

Це чистіший шлях: одразу представте диск на VirtIO, потім завантажте драйвер у Setup, щоб Windows його побачила і встановилась коректно.

Крок 1: Прикріпіть обидва ISO

Змонатуйте ваш Windows ISO як CD/DVD привід 1. Змонатуйте virtio-win.iso як CD/DVD привід 2. Якщо ви змонтуєте тільки VirtIO і забудете Windows — матимете час подумати про життєві рішення.

Крок 2: Використайте VirtIO SCSI single і SCSI-диск

У апаратних налаштуваннях Proxmox VM:

• SCSI Controller: VirtIO SCSI single
• Hard Disk: SCSI (scsi0)

Крок 3: У Windows Setup натисніть «Завантажити драйвер»

Коли дійдете до вибору диска і нічого не видно:

1. Клацніть Load driver.
2. Перейдіть до VirtIO CD-приводу.
3. Виберіть папку драйвера, що відповідає вашій ОС та архітектурі. Приклади:
   • \vioscsi\w11\amd64
   • \vioscsi\w10\amd64
   • \vioscsi\2k22\amd64 (для Windows Server 2022)
4. Виберіть драйвер і продовжуйте. Ваш диск має з’явитися.

Крок 4: Встановіть додаткові драйвери після першого завантаження Windows

Зберігання — це ключовий елемент, але не зупиняйтесь на ньому. Встановіть:

• Мережевий драйвер (NetKVM), якщо ви використовували VirtIO NIC
• Balloon драйвер, якщо використовуєте механізми динамічної пам’яті (хтось використовує, хтось ні)
• QEMU Guest Agent для коректного завершення роботи, звітування IP та кращої оркестрації

Існуюча Windows VM: безпечно перейдіть з SATA/IDE на VirtIO/SCSI

Ось де люди ламають речі. Режим відмови передбачуваний: Windows завантажується на SATA, ви переключаєте диск на VirtIO SCSI, Windows видає синій екран з INACCESSIBLE_BOOT_DEVICE, бо завантажувальний драйвер не встановлений/неактивний.

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

Метод A (рекомендовано): додайте другий диск VirtIO, встановіть драйвери, потім мігруйте

1. Залиште поточний завантажувальний диск на SATA (або на тому, що працює).
2. Додайте другий диск на VirtIO SCSI (scsi1) або VirtIO Block, залежно від плану.
3. Завантажте Windows. Вона виявить нове обладнання і ви зможете вказати VirtIO драйвери (або встановити пакет VirtIO).
4. Підтвердіть, що драйвер встановлено і новий диск видно в Disk Management.
5. Потім мігруйте завантажувальний диск/контролер або клонувати дані за потреби.

Метод B: підготуйте драйвер і відразу переключіть контролер (швидко, ризиковано)

Якщо треба зробити в один прийом:

• Змонатуйте VirtIO ISO у VM.
• Встановіть пакет драйверів VirtIO всередині Windows.
• Вимкніть, змініть шину/контролер диска в Proxmox, завантажтесь і трохи менше моліться, ніж зазвичай.

Це часто працює. «Часто» — не стратегія надійності. Використовуйте Метод A, коли несете відповідальність за час безвідмовної роботи.

Жарт #2: Міняти контролери збереження Windows без підготовки драйверів — як міняти кермо автомобіля на шосе: технічно можливо, але суспільно не рекомендується.

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

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

Завдання 1: Підтвердіть конфігурацію апаратури VM (яку шину диска ви фактично представили?)

cr0x@server:~$ qm config 104
boot: order=scsi0;ide2;net0
cores: 4
memory: 8192
name: win11-prod
net0: virtio=DE:AD:BE:EF:10:40,bridge=vmbr0
scsihw: virtio-scsi-single
scsi0: rpool:vm-104-disk-0,discard=on,iothread=1,size=120G
ide2: local:iso/Win11_23H2.iso,media=cdrom
ide3: local:iso/virtio-win.iso,media=cdrom

Що це означає: Ця VM використовує VirtIO SCSI single і завантажувальний диск на scsi0. Windows Setup потребуватиме vioscsi.

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

Завдання 2: Підтвердіть, що том диска існує на сховищі Proxmox

cr0x@server:~$ pvesm list rpool | grep vm-104-disk-0
rpool:vm-104-disk-0  raw  128849018880  0

Що це означає: Том існує і видимий Proxmox.

Рішення: Якщо його немає — це вже не питання драйверів VirtIO, а проблема відображення сховища, видалення або неправильного ID VM.

Завдання 3: Перевірте, чи блокують операції диска бекапи/снепшоти або лок

cr0x@server:~$ qm status 104
status: stopped

Що це означає: VM зупинена; тут немає активного блоку.

Рішення: Якщо бачите lock у GUI або в логах завдань — усуньте причину перед очікуванням стабільного прикріплення диска.

Завдання 4: Перевірте, чи присутній VirtIO ISO на хості

cr0x@server:~$ ls -lh /var/lib/vz/template/iso/virtio-win.iso
-rw-r--r-- 1 root root 705M Dec  2 11:40 /var/lib/vz/template/iso/virtio-win.iso

Що це означає: ISO існує в стандартному шляху Proxmox.

Рішення: Якщо його немає — завантажте коректно; не монтуйте випадковий файл і не називайте це правильним рішенням.

Завдання 5: Підтвердіть, що VM дійсно монтує VirtIO ISO як CD-ROM

cr0x@server:~$ qm config 104 | egrep 'ide2|ide3|sata2'
ide2: local:iso/Win11_23H2.iso,media=cdrom
ide3: local:iso/virtio-win.iso,media=cdrom

Що це означає: VirtIO ISO прикріплено як CD-ROM.

Рішення: Якщо не прикріплено — Windows Setup ніколи не знайде драйвер. Прикріпіть, перезавантажте VM у Setup і спробуйте знову.

Завдання 6: Перевірте параметри процесу QEMU для VM (Proxmox застосував налаштування?)

cr0x@server:~$ ps -ef | grep -E 'kvm.*-id 104' | head -n 1
root     22188     1 12 11:52 ?        00:01:44 /usr/bin/kvm -id 104 -name win11-prod -machine type=pc-q35-8.1 ... -device virtio-scsi-pci,id=scsihw0 ...

Що це означає: QEMU запущено з пристроєм VirtIO SCSI.

Рішення: Якщо ви очікували SATA, але бачите пристрої VirtIO — конфігурація не така, як ви думаєте. Виправте невідповідність перед втручанням у Windows.

Завдання 7: Перевірте логи ядра хоста на наявність помилок диска/сховища під час старту VM

cr0x@server:~$ journalctl -k --since "30 min ago" | egrep -i 'zfs|scsi|blk|i/o error|qemu' | tail -n 15
Dec 26 11:51:10 server kernel: zfs: spa_sync: doing sync pass
Dec 26 11:51:12 server kernel: blk_update_request: I/O error, dev zd16, sector 123456 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Dec 26 11:51:12 server kernel: Buffer I/O error on dev zd16, logical block 15432, async page read

Що це означає: Хост викидає I/O помилки. Це може проявлятися у гості як «немає диска» або пошкоджені інсталяції.

Рішення: Не звинувачуйте одразу драйвери VirtIO — перевірте стан сховища хоста (стан пулу, дисків, контролера) перш ніж продовжувати.

Завдання 8: Перевірте стан ZFS пулу (якщо ви на ZFS)

cr0x@server:~$ zpool status -x
all pools are healthy

Що це означає: Немає відомих проблем ZFS.

Рішення: Якщо звітує degraded/faulted — виправляйте це спочатку. Невидимість диска у Windows Setup не завжди історія про драйвери.

Завдання 9: Підтвердіть режим прошивки/завантаження VM (UEFI vs SeaBIOS)

cr0x@server:~$ qm config 104 | egrep 'bios|efidisk0|machine'
bios: ovmf
efidisk0: rpool:vm-104-disk-1,size=4M
machine: q35

Що це означає: VM використовує UEFI (OVMF) з EFI-диском і машинний тип Q35.

Рішення: Тримайте це послідовно. Якщо ви встановили Windows у режимі UEFI — не переключайтеся на SeaBIOS пізніше, якщо не хочете копатися у завантажувачі.

Завдання 10: Перевірте модель NIC (потім вам знадобиться мережа для завершення налаштувань)

cr0x@server:~$ qm config 104 | grep '^net0'
net0: virtio=DE:AD:BE:EF:10:40,bridge=vmbr0

Що це означає: Використовується VirtIO NIC. Windows Setup також може не мати мережевого драйвера.

Рішення: Якщо вам потрібна мережа під час Setup (для приєднання до домену, завантаження драйверів або оновлень), будьте готові завантажити NetKVM з VirtIO ISO або тимчасово використати емульований Intel E1000 NIC.

Завдання 11: Перевірте журнали завдань Proxmox на недавні зміни обладнання

cr0x@server:~$ tail -n 30 /var/log/pve/tasks/index
UPID:server:00005A1C:0002A9F4:676D8B6E:qmset:104:root@pam:
UPID:server:00005A9F:0002B0A1:676D8BAA:qmstart:104:root@pam:
UPID:server:00005B10:0002B733:676D8BE2:qmstop:104:root@pam:

Що це означає: Хтось змінив налаштування VM і запускав/зупиняв її.

Рішення: Якщо диск/шина контролера була змінена нещодавно — спочатку припустіть невідповідність драйверів. Відкат або застосування правильної процедури міграції вирішить проблему.

Завдання 12: Проінспектуйте ефективні рядки відображення диску (SCSI vs VirtIO vs SATA)

cr0x@server:~$ qm config 104 | egrep '^(scsi|virtio|sata|ide)[0-9]+:'
scsi0: rpool:vm-104-disk-0,discard=on,iothread=1,size=120G
ide2: local:iso/Win11_23H2.iso,media=cdrom
ide3: local:iso/virtio-win.iso,media=cdrom

Що це означає: Єдиний жорсткий диск — VirtIO SCSI (scsi0). Якщо Windows не бачить його — вам бракує vioscsi в Setup.

Рішення: Не змінюйте п’ять речей одразу. Спочатку виправте завантаження драйвера.

Завдання 13: Якщо підозрюєте баг «диск не прикріплений», порівняйте запущену конфігурацію з файлами дисків на сховищі

cr0x@server:~$ ls -lh /rpool/images/104/
total 121G
-rw-r----- 1 root root 120G Dec 26 11:50 vm-104-disk-0
-rw-r----- 1 root root 4.0M Dec 26 11:45 vm-104-disk-1

Що це означає: Файли дисків існують у очікуваному місці (приклад для mount-подібного шляху ZFS dataset). Відображення Proxmox, ймовірно, в порядку.

Рішення: Якщо файл диска відсутній — не продовжуйте перевстановлення Windows. Відновіть з бекапу або виправте відображення сховища.

Завдання 14: Перевірте наявність апаратних віртуалізаційних флагів CPU і стан KVM (рідко, але виключає клас дивних проблем)

cr0x@server:~$ egrep -m 1 '(vmx|svm)' /proc/cpuinfo
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ...

Що це означає: Присутні апаратні розширення віртуалізації.

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

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

Цей розділ — те, що спалює години в реальних середовищах, бо всі припускають неправильний шар.

1) Симптом: Windows Setup не показує жодних дисків

• Корінь проблеми: Представлено контролер VirtIO, але в Setup не завантажено драйвер зберігання VirtIO.
• Виправлення: Змотаюйте VirtIO ISO, натисніть «Load driver», оберіть vioscsi для VirtIO SCSI або viostor для VirtIO Block, що відповідає вашій версії Windows і amd64.

2) Симптом: «No device drivers were found» при перегляді VirtIO ISO

• Корінь проблеми: Неправильна папка (не та версія ОС), неправильна архітектура, або ви використовуєте VirtIO Block, але переглядаєте vioscsi (або навпаки).
• Виправлення: Повторно перевірте шину диска в Proxmox. Потім виберіть правильний шлях драйвера. Якщо сумніваєтесь: VirtIO SCSI → \vioscsi\...\amd64; VirtIO Block → \viostor\...\amd64.

3) Симптом: Існуюча Windows VM видає blue screen INACCESSIBLE_BOOT_DEVICE після зміни контролера

• Корінь проблеми: Драйвер зберігання не встановлено/не налаштовано на ранній старт перед зміною контролера.
• Виправлення: Відкотіть на старий контролер, щоб завантажитись. Потім підготуйте драйвери, додавши другий VirtIO диск. Лише після цього змінюйте шину завантажувального диска.

4) Симптом: Диск з’являється в Setup після завантаження драйверу, але інсталяція пізніше ламається або пошкоджується

• Корінь проблеми: Нестабільність сховища хоста, I/O помилки або небезпечний режим кешування при відсутності охорони від втрати живлення.
• Виправлення: Перевірте логи хоста і стан пулу. Використовуйте консервативні налаштування кешування, поки не доведете надійність збереження даних (і не маєте UPS і коректних семантик write barrier у стеку).

5) Симптом: Windows встановлено, але мережі немає під час Setup або після першого завантаження

• Корінь проблеми: Обрано VirtIO NIC, але NetKVM драйвер не встановлено.
• Виправлення: Завантажте NetKVM з VirtIO ISO під час Setup або тимчасово використайте емульований NIC, щоб вийти в мережу і встановити пакет VirtIO пізніше.

6) Симптом: Windows бачить диск, але продуктивність жахлива (велика латентність, низький IOPS)

• Корінь проблеми: Неправильні налаштування диска (відсутній iothread, субоптимальний режим кешування), конкуренція на хості або насичення сховища бекенду.
• Виправлення: Увімкніть iothread для зайнятих дисків, перегляньте режим кешування та виміряйте латентність сховища хоста. Не «оптимізуйте» наосліп.

7) Симптом: Після встановлення драйвера Windows досі не бачить диск до перезавантаження

• Корінь проблеми: Драйвер встановлено, але перерахунок пристроїв ще не відбувся в середовищі.
• Виправлення: У Setup перерахуньте диски або поверніться назад/вперед. У встановленій Windows перерахунок дисків у Disk Management або перезавантаження. Це нормально; не панікуйте.

Контрольні списки / поетапний план

Контрольний список A: Нова інсталяція Windows на VirtIO SCSI (рекомендований шлях)

1. Створіть VM з UEFI (OVMF), якщо хочете сучасні налаштування Windows; тримайте машинний тип Q35 послідовним.
2. Встановіть SCSI Controller на VirtIO SCSI single.
3. Додайте диск як SCSI (scsi0); увімкніть iothread для очікуваного інтенсивного I/O; розгляньте discard, якщо тонкопровізовано/SSD.
4. Змонатуйте Windows ISO як CD-ROM.
5. Змонатуйте VirtIO ISO як другий CD-ROM.
6. Завантажте Windows ISO, дійдіть до вибору диска, натисніть «Load driver».
7. Завантажте vioscsi драйвер, що відповідає версії ОС і amd64.
8. Підтвердіть появу диска; встановіть Windows.
9. Після першого завантаження встановіть повний пакет VirtIO (storage, net, balloon, qemu-ga) з VirtIO ISO.
10. Перезавантажтеся і перевірте, щоб у Device Manager не було невідомих пристроїв для зберігання/мережі.

Контрольний список B: Перевести існуючу Windows VM з SATA на VirtIO SCSI без драми

1. Зробіть сніпшот або бекап VM. Це не опційно, якщо ви відповідаєте за надійність.
2. Змонатуйте VirtIO ISO у існуючій VM.
3. Додайте невеликий тестовий диск як SCSI під VirtIO SCSI single (scsi1), залишивши завантажувальний диск без змін.
4. Завантажте Windows; встановіть драйвери VirtIO (або пакет). Підтвердіть, що Windows виявляє новий диск і контролер.
5. Вимкніть VM коректно.
6. Змініть шину завантажувального диска на SCSI (VirtIO SCSI single).
7. Завантажте і перевірте, що Windows стартує без проблем зі зберіганням.
8. Видаліть тестовий диск, якщо він використовувався лише для підготовки драйверів.

Контрольний список C: Якщо ви застрягли під час інсталяції і потрібен тактичний обхід

1. Тимчасово переключіть завантажувальний диск на SATA (AHCI), щоб Windows Setup побачив його без драйверів.
2. Встановіть Windows.
3. У встановленій Windows встановіть VirtIO драйвери з VirtIO ISO.
4. Використайте Метод A для подальшого переходу на VirtIO SCSI.

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

Міні-історія 1: Інцидент через неправильне припущення

В організації був стандартний «золотий шаблон» для Windows VM. Хтось його створив місяці тому, використовуючи SATA диски, бо «працювало скрізь». З часом команда віртуалізації модернізувала все інше: Q35, UEFI, VirtIO NIC. Сховище залишилося на SATA, бо ніхто не хотів чіпати. Потім прийшов новий інженер і зробив те, що нові інженери часто роблять: «покращив» очевидно невдале.

Вони мігрували кілька VM з SATA на VirtIO SCSI одна за одною під час вікна технічного обслуговування. Вони припустили, що Windows сама виявить контролер при завантаженні і встановить драйвери автоматично, бо Linux так робить. Перший VM видав BSOD. Другий теж. Вікно перетворилося на пожежний сценарій, а канал підтримки заповнився креативною лексикою.

Корінь проблеми не був екзотичним. Драйвер VirtIO не був підготовлений як драйвер раннього старту. Windows не мала можливості говорити з завантажувальним диском, тому не могла завантажити ОС, щоб встановити драйвер, який потрібен, щоб говорити з диском, щоб … Це ідеальний замкнений цикл.

Відновлення було простим, коли хтось заспокоївся: переключили диски назад на SATA, завантажили VirtIO ISO, встановили пакет драйверів, додали тестовий VirtIO SCSI диск для примусового перерахунку, підтвердили драйвери і повторили міграцію. Але простою жертвували, бо на старті зробили неправильне припущення: «драйвер з’явиться сам».

Тривале рішення не було героїчним скриптом. Це був runbook міграції з однією обов’язковою кроком: підготувати драйвер, поки VM ще завантажується.

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

Інша команда пишалася своїм кластером Proxmox. Солідне залізо, ZFS і достатньо моніторингу, щоб розбудити мертвих. Вони помітили, що бенчмарки дисків у Windows VM були «нижчі за очікування», і хтось вирішив налаштувати все до блиску. Вони змінили режим кешу на writeback, увімкнули discard скрізь і включили iothread для кожного диска по флоту, поспішаючи.

Продуктивність дійсно покращилася — короткочасно. Потім відбувся перезавантаження хоста після оновлення ядра. Частина VM повернулися з помилками файлової системи і пошкодженнями додатків. Розбори були болючими, бо не було однієї вказівної причини; була купа невірних припущень. Writeback може бути безпечним якщо ви розумієте, звідки приходить підтвердження запису і що відбувається при відключенні живлення або раптовому перезапуску хоста. У їхньому середовищі така історія безпеки не була повністю доведена.

Їм довелося відкотити налаштування кешу, відновлювати частину даних з бекапів і пояснювати менеджменту, чому «оптимізація продуктивності» спричинила інцидент надійності. Жорсткий урок: тонкі налаштування сховища не безкоштовні. Якщо не можете пояснити модель збереження даних сумнівному SRE — не впроваджуйте.

В результаті залишили iothread для конкретних високонавантажених дисків, використовували консервативне кешування за замовчуванням і включали агресивні режими лише там, де додаток може терпіти ризик і інфраструктура має захист від втрати живлення.

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

Одна команда керувала невеликою приватною хмарою на Proxmox з мішаною інфраструктурою Linux і Windows. Нічого екстраординарного. Їхня «нудна практика» — стандартизований чекліст збірки VM: завжди прикріплювати VirtIO ISO, завжди встановлювати пакет VirtIO і QEMU guest agent, завжди перевіряти, що Device Manager чистий, завжди робити сніпшот перед зміною контролерів дисків.

Потім прийшла задача: перевести Windows VM на VirtIO SCSI single для продуктивності та операційної узгодженості. Це не було гламурно. Це були повторювані кроки: додати другий VirtIO диск, завантажитись, підтвердити драйвер, вимкнути, переключити контролер, завантажитись, перевірити, видалити тестовий диск.

Під час розгортання одна VM відмовилася завантажуватись після перемикання. Ніякої драми. Вони відкотилися через сніпшот, завантажились, виявили, що прикріплений VirtIO ISO був древньої збірки з проблемами підписування під їхні налаштування Secure Boot, оновили ISO, підготували драйвери і завершили міграцію.

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

Одна операційна цитата (перефразована ідея)

Перефразована ідея (Werner Vogels): «Все ламається постійно», тому проектуйте системи та процедури, виходячи з того, що відмова — нормальний стан.

Поширені запитання (FAQ)

1) Який драйвер VirtIO мені потрібен: vioscsi чи viostor?

VirtIO SCSI (коли контролер SCSI у Proxmox встановлено на VirtIO SCSI / VirtIO SCSI single) зазвичай потребує vioscsi. VirtIO Block (диск на virtio0) потребує viostor. Перевірте qm config, щоб впевнитися, що саме ви налаштували.

2) Чому Linux бачить диск, а Windows — ні?

Ядра Linux зазвичай включають драйвери VirtIO за замовчуванням. Windows не має драйверів VirtIO з коробки у середовищі інсталятора, тому їх треба завантажити з VirtIO ISO.

3) Чи можна встановити Windows на SATA, а потім переключитися на VirtIO?

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

4) Я завантажив драйвер в Windows Setup, але диск досі не з’явився. Що робити?

Перевірте тип контролера (VirtIO SCSI vs VirtIO Block), папку драйвера (правильна версія Windows + amd64) та переконайтесь, що VirtIO ISO справді змонтовано. Якщо в логах хоста є I/O помилки — зупиніться і виправте стан сховища хоста перш ніж продовжувати.

5) Чи блокує Secure Boot Windows 11 драйвери VirtIO?

Може, якщо ви використовуєте застарілий VirtIO ISO з проблемами підписування відносно вашої політики Secure Boot. Використовуйте свіжий VirtIO ISO і тримайте вибір прошивки VM послідовним (UEFI залишається UEFI).

6) Який найкращий контролер диска для Windows на Proxmox?

Для більшості production-навантажень: VirtIO SCSI single з SCSI-дисками. Це добрий баланс продуктивності, функцій і операційної передбачуваності.

7) Я змінив контролер і тепер VM не завантажується. Яке найшвидше відновлення?

Поверніть диск на старий контролер (SATA/IDE), щоб Windows завантажилась. Потім встановіть драйвери VirtIO коректно (переважно додавши вторинний VirtIO диск). Після підтвердження драйверів повторіть зміну контролера.

8) Чи потрібен QEMU Guest Agent для видимості дисків?

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

9) Чи варто увімкнути discard (TRIM) на віртуальному диску?

Якщо ваш бекенд отримує вигоду від звільнення місця (тонкопровізовані пули, SSD) і ви розумієте поведінку стеку зберігання — так. Якщо сумніваєтесь — починайте консервативно і вимірюйте. Неправильне discard-поведення рідко призведе до невидимості диска, але може створити несподівані проблеми з продуктивністю.

10) Чому VirtIO ISO має стільки папок?

Бо версії Windows і вимоги підписування відрізняються, і драйвери упаковані по сімействам ОС та архітектурам. Інсталятору потрібен точний набір inf/sys/cat. «Десь поруч» — не працює для Windows-драйверів.

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

Якщо Windows не бачить ваш диск на Proxmox, ставтеся до цього як до невідповідності контракту: Proxmox представив контролер; Windows потребує правильного драйвера, щоб з ним говорити. Виправте невідповідність, не слідуйте випадковим налаштуванням.

• Нові інсталяції: використовуйте VirtIO SCSI single з першого дня і завантажуйте vioscsi у Setup з VirtIO ISO.
• Існуючі інсталяції: підготуйте драйвери спочатку (додайте вторинний VirtIO диск), потім переключайте завантажувальний диск/контролер.
• Якщо все ще не працює: перевірте здоров’я сховища хоста і відображення VM за допомогою команд, а не інтуїції.

Дотримуйтесь цього послідовно, і проблема «Windows не бачить диск» перестане бути ритуалом. Ви також краще спатимете — а це справжня метрика продуктивності.