Proxmox Windows VM без мережі: виправлення драйвера VirtIO NIC, які реально працюють

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

Якщо у вас є лише 10 хвилин і менеджер нависає поруч, зробіть це в такому порядку. Мета — знайти перший «зламаний» проміжок: Windows ↔ VirtIO драйвер ↔ QEMU tap ↔ Proxmox міст ↔ фізична NIC ↔ мережа/ DHCP вгору по ланцюжку.

1) Доведіть, чи VM взагалі випромінює трафік

• На хості Proxmox знайдіть tap-інтерфейс VM і просніффте на ARP/DHCP.
• Якщо трафіку нуль, проблема всередині гостьової системи (драйвер, відключений адаптер, IP-стек, невідповідність тегу VLAN у конфігурації VM).
• Якщо трафік є, але немає відповідей — проблема зовні гостьової системи (міст, брандмауер, VLAN, комутатор, DHCP).

2) Перевірте підключення мосту Proxmox

• Чи прикріплено NIC VM до очікуваного мосту (зазвичай vmbr0)?
• Чи дійсно vmbr0 підключений до фізичної NIC або бонду, який ви очікуєте?
• Чи Proxmox firewall мовчазно не блокує egress або DHCP?

3) Перевірте адаптер і драйвер у Windows

• Чи бачить Windows пристрій NIC взагалі?
• Якщо бачить — чи завантажено драйвер і чи підписаний він? (VirtIO NetKVM)
• Чи показує ipconfig /all спробу DHCP або лише APIPA (169.254.x.x)?

4) Лише потім ганяйте «просунуті» причини

• Тегування VLAN і конфігурація транку.
• Невідповідність MTU / джамбо-кадрів у частині шляху.
• Взаємодія multi-queue / offloads з певними віртуальними фільтрами/брандмауерами.
• Мережевий профіль Windows і правила брандмауера (рідше, ніж думають, але буває).

Ментальна модель: де пакети гинуть

З мережевими відмовами простіше працювати, якщо ставитися до них як до затримок у зберіганні: ви картографуєте канал, потім вимірюєте кожний етап. Windows VM на Proxmox зазвичай виглядає так:

1. Мережевий стек Windows (IP/DHCP/ARP), що спілкується з…
2. Пристрій VirtIO NIC (virtio-net у QEMU), який використовує…
3. Драйвер NetKVM (Windows драйвер для virtio-net), що передає пакети до…
4. QEMU tap інтерфейс (наприклад, tap100i0) на хості, підключений до…
5. Linux-міст (vmbr0) можливо з фільтрацією VLAN, далі…
6. Фізична NIC/бонд (наприклад, eno1, bond0) до…
7. Порт комутатора з політикою транку/доступу, потім…
8. Верхній рівень — шлюз, DHCP і будь-які пристрої безпеки.

Ваша задача — вирішити, який шар брешe. І щось завжди брешe.

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

Цікаві факти й історичний контекст (щоб дивність була зрозумілою)

• VirtIO створено, щоб уникнути накладних витрат емуляції. Емульовані NIC, як Intel E1000, зручні, але вони витрачають CPU, бо гіпервізор удає обладнання зі старої ери.
• Міф «E1000 працює скрізь» дорого обходиться. Він часто «просто працює» на Windows без додаткових драйверів, але при високій пропускній здатності може стати вузьким місцем, поки ви цього не помітите.
• Windows не постачає VirtIO драйвери за замовчуванням. На відміну від багатьох дистрибутивів Linux, Windows зазвичай потребує VirtIO ISO (або втиснутих драйверів) для дисків і мережі.
• Назва драйвера VirtIO важлива. Windows-драйвер зазвичай називають NetKVM; змішування версій може спричинити дивні збої після оновлень Windows, що посилюють політики драйверів.
• QEMU/Proxmox можуть показувати кілька моделей NIC. VirtIO (паравіртуалізований), E1000, RTL8139 (древній) та інші. Вибір неправильної моделі впливає на продуктивність і підтримку.
• Міст у Linux — не магія. Linux-міст — це програмний комутатор. Якщо ви неправильно приєднаєте порт (tap) або помилитеся з фільтрацією VLAN, пакети підуть нікуди з вражаючою тишею.
• Proxmox firewall — станова і багаторівнева. Є рівні Datacenter, Node і VM. Поступлива правило на одному рівні не допоможе, якщо інший рівень блокує першим.
• APIPA (169.254/16) — це «я спробував» від Windows. Це означає, що DHCP не вдався. Це не доказ працездатності NIC; це означає, що Windows вичерпав час очікування оренди.
• UEFI/Secure Boot змінюють прийнятність драйверів. Деякі конфігурації Windows із увімкненим Secure Boot можуть відкидати непідписані або неправильно підписані драйвери, включаючи старі версії VirtIO.

Спочатку точно назвіть симптом

«Немає мережі» — це скарга, а не діагностика. Виберіть найточніший симптом; він визначає найшвидший шлях.

Симптом A: Windows не показує Ethernet-адаптера взагалі

Зазвичай: неправильна модель NIC, відсутній VirtIO драйвер, пристрій відключений або Windows ховає його через «привидні» пристрої.

Симптом B: Адаптер є, але IP 169.254.x.x (APIPA)

Зазвичай: DHCP не доходить до VM, відповіді DHCP не доходять до Windows, або NIC застряг у дивному стані драйвера/офлоадів.

Симптом C: Є IP, але не пінгується шлюз

Зазвичай: невідповідність VLAN, неправильний міст, відкидання правил брандмауера, неправильна підмережа/шлюз або політика на верхньому комутаторі.

Симптом D: Працює недовго, а потім вмирає (або помирає після міграції/перезавантаження)

Зазвичай: конфлікт MAC, дубльований IP, стан брандмауера Proxmox, регресія драйвера Windows після оновлення або проблеми взаємодії офлоадів/черг.

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

Перевірки на хості (Proxmox): мости, tap, firewall, VLAN

Не починайте зсередини Windows. Почніть там, де у вас кращі інструменти: на хості Proxmox. Ви там можете спостерігати реальність.

Завдання 1: Підтвердіть, що NIC VM прикріплений до того мосту, який ви очікуєте

cr0x@server:~$ qm config 100 | grep -E '^net[0-9]+:'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=1,tag=20

Що означає вивід: VM 100 має VirtIO NIC з MAC DE:AD:BE:EF:10:00, прикріплену до vmbr0, з увімкненим Proxmox firewall і тегом VLAN 20.

Рішення: Якщо bridge= неправильний (наприклад, vmbr1 замість vmbr0), виправте конфігурацію VM перед тим, як лізти в Windows. Якщо існує tag=, підтвердіть, що VLAN 20 коректний по всьому шляху.

Завдання 2: Переконайтеся, що міст існує і має очікувані порти

cr0x@server:~$ bridge link show
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 100
5: tap100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 100

Що означає вивід: Фізична NIC eno1 і tap VM tap100i0 обидві приєднані до vmbr0. Це базове підключення.

Рішення: Якщо ви не бачите tap-інтерфейс на правильному мосту, VM не підключена. Перезапустіть VM або перевірте мережеву конфігурацію Proxmox і призначення NIC у VM.

Завдання 3: Переконайтеся, що міст і NIC підняті

cr0x@server:~$ ip -br link show vmbr0 eno1 tap100i0
vmbr0            UP             5a:9a:12:34:56:78 <BROADCAST,MULTICAST,UP,LOWER_UP>
eno1             UP             3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP>
tap100i0         UP             fe:54:00:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>

Що означає вивід: Лінки адміністративно підняті і присутній carrier (LOWER_UP).

Рішення: Якщо vmbr0 DOWN, у вас проблема хост-мережі. Якщо тільки tap DOWN, дивіться стан виконання VM або проблеми процесу QEMU.

Завдання 4: Перевірте конфігурацію мережі Proxmox на очевидні помилки підключення

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.0.2.10/24
        gateway 192.0.2.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

Що означає вивід: vmbr0 — це Linux-міст з портом eno1; хост має IP на мосту, а не на eno1. Це нормально для Proxmox.

Рішення: Якщо IP хоста на фізичній NIC замість мосту, VM не зможуть достукатися до мережі через міст очікуваним шляхом. Виправляйте обережно (краще через вікно технічного обслуговування або консольний доступ).

Завдання 5: Підтвердіть, що tap-інтерфейс існує для цієї VM і відповідає потрібному процесу QEMU

cr0x@server:~$ ps -ef | grep -E 'kvm.*-id 100\b' | head -n 1
root     21488     1 35 10:21 ?        00:14:12 /usr/bin/kvm -id 100 -name WIN-APP01 ...

Що означає вивід: QEMU/KVM запущено для VM 100.

Рішення: Якщо QEMU не запущено, ви дивитесь проблему VM, яка фактично не запущена. Вирішіть проблему завантаження VM спочатку.

Завдання 6: Перевірте, чи хост бачить трафік на tap VM (ARP/DHCP достатньо)

cr0x@server:~$ tcpdump -ni tap100i0 -c 10 -vv
tcpdump: listening on tap100i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:25:11.100001 ARP, Request who-has 192.0.2.1 tell 0.0.0.0, length 46
10:25:11.200002 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:10:00, length 300
10:25:12.200010 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:10:00, length 300

Що означає вивід: VM випромінює ARP і DHCP-запити. Пристрій VirtIO і стек Windows принаймні намагаються працювати.

Рішення: Якщо ви бачите запити, але немає відповідей — фокусуйтеся на мосту/брандмауері/VLAN/верхньому DHCP. Якщо нічого не видно — дивіться всередині Windows (драйвер або адаптер відключено) або перевірте приєднання NIC у Proxmox.

Завдання 7: Просніффте на мосту або фізичній NIC, щоб побачити, чи пакети покидають хост

cr0x@server:~$ tcpdump -ni eno1 -c 10 -vv 'port 67 or port 68 or arp'
tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:25:11.200002 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:10:00, length 300
10:25:11.250123 IP 192.0.2.5.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 310

Що означає вивід: DHCP-запити від VM потрапляють на фізичну NIC, і DHCP-відповіді повертаються на хост.

Рішення: Якщо відповіді присутні на eno1, але Windows все ще має APIPA, шлях повернення від хоста до VM зламаний (брандмауер, фільтрація мосту, невідповідність тегів VLAN або VM не отримує кадри).

Завдання 8: Перевірте статус Proxmox firewall на рівні датацентру/нода/VM

cr0x@server:~$ pve-firewall status
Status: enabled/running

Що означає вивід: Служба Proxmox firewall увімкнена і працює. Це не означає, що вона блокує, але означає, що може блокувати.

Рішення: Якщо ви налагоджуєте продакшн-аутейдж і правила невідомі, тимчасово відключіть firewall на рівні VM для ізоляції (потім увімкніть знову з правильними правилами).

Завдання 9: Швидко перевірте налаштування брандмауера VM

cr0x@server:~$ qm config 100 | grep -E '^net0:'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=1,tag=20

Що означає вивід: firewall=1 означає, що застосовуються правила на рівні VM.

Рішення: Для ізоляції встановіть firewall=0 (тимчасово) і повторно протестуйте DHCP/ping. Якщо це вирішує проблему, ви знаєте, куди вкладати час.

Завдання 10: Перевірте фільтрацію VLAN і членство VLAN на мосту

cr0x@server:~$ bridge vlan show | sed -n '1,120p'
port              vlan-id
eno1              1 PVID Egress Untagged
eno1              20
tap100i0          20 PVID Egress Untagged

Що означає вивід: Tap VM не тегований у VLAN 20 (PVID 20), а uplink eno1 несе VLAN 20. Це відповідає VM, конфігурованій з tag=20, залежно від режиму VLAN на мосту.

Рішення: Якщо VLAN 20 відсутній на uplink, VM застрягне в VLAN-ізоляції. Виправте конфігурацію VLAN мосту або конфігурацію транка на комутаторі.

Завдання 11: Перевірте ebtables/nftables на предмет відкидань (поширено при наявності правил брандмауера)

cr0x@server:~$ nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "tap100i0" oifname "vmbr0" accept
  }
}

Що означає вивід: Політика forward — drop, з конкретним шляхом accept. Якщо ваші правила не дозволяють DHCP (broadcast) належним чином, ви отримаєте APIPA назавжди.

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

Завдання 12: Підтвердіть відсутність проблем із навчанням MAC або дублікатів

cr0x@server:~$ bridge fdb show br vmbr0 | grep -i 'de:ad:be:ef:10:00'
de:ad:be:ef:10:00 dev tap100i0 master vmbr0 permanent

Що означає вивід: Міст знає MAC VM на tap100i0. Це очікувано.

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

Перевірки конфігурації VM: модель NIC, MAC, черги, BIOS/UEFI

Вибирайте модель NIC свідомо

У Proxmox ви можете вибирати модель NIC для кожної VM. Практичні рекомендації:

• VirtIO: найкраща продуктивність і найменші накладні витрати CPU. Потребує драйверів у Windows.
• E1000/E1000e: підходить для «потрібно завантажитися і одразу зв’язатися», але продуктивність може бути посередньою під навантаженням.
• RTL8139: не використовуйте. Існує лиш для лабораторій і навчальних середовищ.

Завдання 13: Переконайтеся, що модель NIC — VirtIO (якщо це ваша ціль)

cr0x@server:~$ qm config 100 | grep -E '^net0:'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=1,tag=20

Що означає вивід: Це VirtIO. Добре. Тепер у Windows має бути NetKVM.

Рішення: Якщо там e1000 і ви прагнете продуктивності, перейдіть на VirtIO після підготовки драйверів (або тимчасово прикріпіть другий NIC для міграції).

Завдання 14: Тимчасово додайте другий NIC для встановлення драйвера

Чистий прийом: додайте E1000 NIC як страховий ліній, встановіть драйвери VirtIO, а потім видаліть E1000. Це знижує панічні маніпуляції з драйверами.

cr0x@server:~$ qm set 100 -net1 e1000,bridge=vmbr0
update VM 100: -net1 e1000,bridge=vmbr0

Що означає вивід: VM тепер має другий NIC, який Windows, ймовірно, розпізнає без додаткових драйверів.

Рішення: Якщо Windows з’являється в мережі через E1000, ви довели, що мережевий шлях працює, а проблема — у драйвері VirtIO. Встановіть NetKVM, потім видаліть E1000.

Multi-queue і offloads: не експериментуйте під час інциденту

VirtIO NIC підтримує кілька черг для пропускної здатності і паралелізму. Чудово при правильному налаштуванні. Також може створити примарну проблему, якщо поєднати це з деякими версіями Windows, старими драйверами та фільтрацією трафіку.

Завдання 15: Перевірте поточну топологію CPU і подумайте про кількість черг NIC

cr0x@server:~$ qm config 100 | grep -E '^(sockets|cores|cpu):'
cores: 8
cpu: x86-64-v2-AES
sockets: 1

Що означає вивід: VM має 8 vCPU. Multi-queue може допомогти, але лише якщо драйвери й навантаження це підтримують.

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

Перевірки в Windows: стан драйвера, приховані адаптери, DHCP, метрики

Тепер заходьте в гостя. Використовуйте консоль Proxmox, якщо RDP не працює (що частіше за все так і є). Якщо Windows не бачить адаптера, жодні благання DHCP не допоможуть.

Завдання 16: Перелік адаптерів — чи бачить Windows щось

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Format-Table -Auto Name,Status,LinkSpeed,MacAddress"
Name            Status LinkSpeed MacAddress
----            ------ --------- ----------
Ethernet        Up     1 Gbps    DE-AD-BE-EF-10-00

Що означає вивід: Windows бачить адаптер, він «Up», і MAC співпадає. Це хороший знак.

Рішення: Якщо адаптерів немає в списку (або тільки «Disconnected» без лінку), переходьте до встановлення драйвера і перевірок у Device Manager.

Завдання 17: Перевірте IP-конфігурацію і чи вдалося DHCP

cr0x@server:~$ ipconfig /all
Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . : Red Hat VirtIO Ethernet Adapter
   Physical Address. . . . . . . . . . : DE-AD-BE-EF-10-00
   DHCP Enabled. . . . . . . . . . : Yes
   Autoconfiguration IPv4 Address. . : 169.254.22.10(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :
   DHCP Server . . . . . . . . . . . :

Що означає вивід: APIPA-адреса. DHCP не завершився. Або запити не виходять, або відповіді не приходять, або DHCP блокується.

Рішення: Зіставте це з tcpdump на хості. Якщо хост бачить DHCP-відповіді, але Windows не отримує оренду — підозрюйте брандмауер/фільтрацію мосту або проблеми з драйвером.

Завдання 18: Примусове оновлення DHCP і спостереження за помилками

cr0x@server:~$ ipconfig /release
Windows IP Configuration

No operation can be performed on Ethernet while it has its media disconnected.

cr0x@server:~$ ipconfig /renew
Windows IP Configuration

An error occurred while renewing interface Ethernet : unable to contact your DHCP server. Request has timed out.

Що означає вивід: Або Windows вважає лінк відключеним («media disconnected»), або DHCP-запити не відповіли.

Рішення: Якщо «media disconnected» — підозрюйте проблеми драйвера/пристрою virtio або приєднання tap/моста в Proxmox. Якщо лише таймаут DHCP — підозрюйте upstream або брандмауер/VLAN.

Завдання 19: Перевірте стан драйвера через PowerShell

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Format-Table -Auto Status,Problem,Class,FriendlyName"
Status Problem Class FriendlyName
------ ------- ----- ------------
OK     0       Net   Red Hat VirtIO Ethernet Adapter

Що означає вивід: Пристрій здоровий з точки зору PnP.

Рішення: Якщо Status — Error або Problem ненульовий, потрібне встановлення/оновлення драйвера або переенумерація пристрою.

Завдання 20: Шукайте приховані/привидні NIC, що можуть забирати конфігурацію

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net -Status Unknown,Error | Format-Table -Auto FriendlyName,Status,Problem"
FriendlyName                         Status   Problem
------------                         ------   -------
Microsoft Kernel Debug Network Adapter Error    28

Що означає вивід: Можуть бути застарілі адаптери або debug-адаптери, які заважають, залежно від середовища.

Рішення: Видаліть застарілі адаптери в Device Manager (показати приховані пристрої), якщо у вас змінилися MAC або повторно створювали NIC.

Завдання 21: Перевірте локальний стек проти зовнішнього пінгом і таблицею маршрутів

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.0.2.1       192.0.2.50     25
        192.0.2.0    255.255.255.0         On-link      192.0.2.50    281
===========================================================================

cr0x@server:~$ ping -n 3 192.0.2.1
Pinging 192.0.2.1 with 32 bytes of data:
Reply from 192.0.2.1: bytes=32 time<1ms TTL=64
Reply from 192.0.2.1: bytes=32 time<1ms TTL=64
Reply from 192.0.2.1: bytes=32 time<1ms TTL=64

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

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

Виправлення драйвера VirtIO: встановлення, оновлення та відновлення

VirtIO на Windows не складний, але нещадний щодо напіввстановлених драйверів, застарілих ISO і невідповідності Secure Boot. Найчистіший підхід: змонтуйте VirtIO driver ISO в Proxmox, правильно встановіть NetKVM і перезавантажте раз.

Підготуйте VirtIO driver ISO (на хості)

Завдання 22: Переконайтеся в наявності ISO і в сховищі

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active       100000000        20000000         80000000       20%
...
cr0x@server:~$ ls -lh /var/lib/vz/template/iso | grep -i virtio
-rw-r--r-- 1 root root  520M Aug  1 09:12 virtio-win.iso

Що означає вивід: Ваш сховок ISO доступний і VirtIO ISO присутній.

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

Прикріпіть ISO до VM (на хості)

Завдання 23: Прикріпіть VirtIO ISO як CD-ROM

cr0x@server:~$ qm set 100 -ide2 local:iso/virtio-win.iso,media=cdrom
update VM 100: -ide2 local:iso/virtio-win.iso,media=cdrom

Що означає вивід: VM має приєднаний driver ISO.

Рішення: Завантажте Windows, потім встановіть/оновіть NetKVM драйвер з змонтованого CD.

Встановіть/оновіть NetKVM всередині Windows

Можна через Device Manager, але в продакшн я віддаю перевагу повторюваним командам. Однак GUI підходить, якщо ви на консолі і час іде.

Завдання 24: Переконайтеся, що VirtIO CD видно і знайдіть netkvm.inf

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Where-Object DriveLetter | Format-Table -Auto DriveLetter,FileSystemLabel"
DriveLetter FileSystemLabel
----------- ---------------
D           virtio-win

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Path D:\NetKVM -Recurse -Filter netkvm.inf | Select-Object -First 3 FullName"
FullName
--------
D:\NetKVM\w10\amd64\netkvm.inf

Що означає вивід: INF драйвера доступний для Windows 10/Server на amd64.

Рішення: Використайте pnputil, щоб додати/встановити драйвер з відповідної директорії для вашої ОС.

Завдання 25: Додайте й встановіть NetKVM драйвер за допомогою pnputil

cr0x@server:~$ pnputil /add-driver D:\NetKVM\w10\amd64\netkvm.inf /install
Microsoft PnP Utility

Driver package added successfully.
Published Name: oem42.inf
Driver package installed on matching devices.

Що означає вивід: Пакунок драйвера додано і встановлено для відповідного обладнання (ваш VirtIO NIC).

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

Завдання 26: Після перезавантаження перевірте опис адаптера як VirtIO і стан лінку

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Format-Table -Auto Name,Status,InterfaceDescription"
Name     Status InterfaceDescription
----     ------ --------------------
Ethernet Up     Red Hat VirtIO Ethernet Adapter

Що означає вивід: NetKVM працює, інтерфейс піднятий.

Рішення: Якщо статус лишається Down/Disconnected, хоча хост бачить трафік, перевірте теги VLAN, Proxmox firewall і розширені налаштування адаптера Windows.

Коли Secure Boot або підпис драйвера блокують вас

Якщо Windows відкидає драйвер (Code 52, проблеми з підписом), у вас є три розумні варіанти:

• Використати новішу збірку VirtIO драйвера, правильно підписану для вашої версії Windows і політики Secure Boot.
• Вимкнути Secure Boot для цієї VM (лише якщо політика дозволяє; багато організацій не дозволяють цього).
• Тимчасово переключити модель NIC на E1000, щоб відновити доступ, а потім планувати керований rollout VirtIO драйверів.

Завдання 27: Перевірте проблеми пристрою, пов’язані з підписом драйвера

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Where-Object Status -ne 'OK' | Format-Table -Auto FriendlyName,Status,Problem"
FriendlyName                         Status Problem
------------                         ------ -------
Red Hat VirtIO Ethernet Adapter       Error  52

Що означає вивід: Problem 52 зазвичай вказує, що Windows не може перевірити підпис драйвера.

Рішення: Оновіть до підписаної версії драйвера, сумісної з вашою ОС, або змініть налаштування Secure Boot згідно з політикою. Не відключайте примусове застосування підписів у продакшні, якщо ви не любите аудити.

Жарт №2: VM без драйвера NIC — як конференція з вимкненим звуком: формально всі підключені, але нічого корисного не відбувається.

Три короткі історії з корпоративного життя (які псують п’ятниці)

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

Команда мігрувала невеликий пул Windows утилітних серверів з застарілого VMware-кластера в Proxmox. План був «простіший простого»: відтворити VM, приєднати диски, використовувати VirtIO скрізь, святкувати. Перший сервер завантажився, сервіси виглядали живими, але моніторинг загорівся: немає метрик, немає RDP, немає патчінгу, немає доменного трафіку.

Припущення було таке: Windows «знайде NIC згодом». Вони звикли до E1000 в інших середовищах і вважали VirtIO просто оптимізацією, а не зміною апаратного забезпечення, що потребує драйвера. Консоль показувала знайому порожнечу: немає адаптерів, немає категорії мережі, а в Device Manager стояв «Ethernet Controller» із жовтим знаком оклику.

Хтось намагався лагодити це перевстановленням мережевих компонентів Windows і скиданням Winsock. Це як полірувати капот, коли двигуна не вистачає. Справжнє вирішення було нудним: змонтувати VirtIO ISO, встановити NetKVM, перезавантажити.

Постмортем теж був нудним, і в цьому і є суть: чек-лист не містив «VirtIO ISO прикріплено» як обов’язковий крок. Команда додала цей пункт. Наступна хвиля міграцій пройшла гладко, і єдиний простій був заслужений.

Міні-історія 2: Оптимізація, що зіграла злий жарт

Інша організація тримала Windows VM з високою пропускною здатністю для трансферів файлів на Proxmox. Хтось прочитав, що VirtIO multi-queue плюс агресивні offload-опції можуть підвищити пропускну здатність. Вони загнули налаштування, збільшили черги і проголосили перемогу на синтетичних тестах.

Потім прийшов реальний трафік. Під навантаженням передачі періодично зависали. Клієнти бачили таймаути. VM мали лінк, IP і чудові-looking ping-и. Команда програла години, бо відмова не була повним простоєм; це була «дивність», найвитратніший режим відмови.

На хості tcpdump показував хвилі перевідправлених пакетів. Внутрішні журнали Windows натякали на скиди драйвера. Нічого не кричало «проблема з offload», бо це рідко робить. Зрештою вони відкотили налаштування offload і повернули черги до дефолту. Проблема зникла.

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

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

Одне підприємство мало правило: кожен шаблон Windows VM містив попередньо підготовлені VirtIO драйвери, навіть якщо початкова модель NIC була E1000. Логіка проста: не хочете виявляти відсутність драйверів під час інциденту.

Вони також вимагали, щоб у кожної VM був документований «break glass NIC»: другий адаптер, який можна тимчасово ввімкнути (або швидко додати), щоб відновити зв’язок. Звучить параноїдально. Насправді — це дешева страховка.

Під час maintenance-події партія VM перезавантажилася, і підмножина піднялася без робочої VirtIO-мережі через регрес драйвера після патчу. Інженер на чергуванні не роздумував довго: переключив ті VM на break glass NIC-модель, відновив доступ, потім оновив VirtIO драйвер до відомо робочої версії.

Ніякого героїчного безсонного ранку, ніякого ескалаційного дзвінка вендору, ніяких випадкових правок реєстру. Просто відпрацьований, документований шлях виходу. Звіт по інциденту був короткий — і це найприємніша річ, яку можна сказати про звіт по інциденту.

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

1) Симптом: Windows показує «Ethernet Controller» з жовтим знаком

Причина: VirtIO NIC представлено, але NetKVM драйвер не встановлено.

Виправлення: Прикріпіть VirtIO ISO, встановіть драйвер через Device Manager або pnputil (Завдання 25), перезавантажте.

2) Симптом: Адаптер є, APIPA 169.254.x.x, немає DHCP-сервера виведеного

Причина: DHCP-трафік блокується або не досягає DHCP-сервера (невідповідність VLAN, брандмауер, неправильний міст).

Виправлення: tcpdump на tap і uplink (Завдання 6–7). Якщо відповіді не повертаються до tap, перевірте Proxmox firewall (Завдання 8–11) і конфіг VLAN (Завдання 10).

3) Симптом: Хост бачить DHCP-відповідь на фізичній NIC, Windows все ще APIPA

Причина: Відповідь не форвардиться до tap (фільтрація мосту, правила брандмауера, невідповідність VLAN).

Виправлення: Перевірте членство VLAN мосту (Завдання 10), правила nftables (Завдання 11) та що tap на правильному мосту (Завдання 2).

4) Симптом: VM має IP, може пінгувати IP моста хоста, але не шлюз

Причина: Невідповідність транку/доступу VLAN на верхньому комутаторі, або теги в Proxmox не співпадають з політикою портів комутатора.

Виправлення: Підтвердіть tag у VM і конфіг VLAN мосту (Завдання 1, 10). Перевірте конфіг порту комутатора (поза Proxmox). Як швидкий тест, зніміть VLAN-tag і поставте VM у нетегований нативний VLAN, якщо політика дозволяє.

5) Симптом: Мережа працює до живої міграції, потім вмирає

Причина: Невідповідність мостів/VLAN/firewall конфігів між нодами; vmbr0 на цільовій ноді не ідентичний.

Виправлення: Порівняйте /etc/network/interfaces і конфіг firewall між нодами. Стандартизовуйте мости і фільтрацію VLAN на всіх нодах. Не робіть з вузлів «сніжинки».

6) Симптом: Випадкові падіння під навантаженням, ping в основному OK

Причина: Взаємодія offload/черг/драйвера або невідповідність MTU на частині шляху.

Виправлення: Поверніть значення до дефолту (черги/офлоади), тестуйте під навантаженням. Переконайтеся в MTU на vmbr, tap, фізичній NIC і upstream. Не використовуйте джамбо, поки весь шлях не перевірено.

7) Симптом: Дві клоновані VM обидві «мають мережу», але одна непостійна

Причина: Дубльований MAC або IP, бійка ARP, захист порту на комутаторі.

Виправлення: Переконайтеся, що MAC у Proxmox унікальні; згенеруйте нові при потребі. Очистьте ARP-кеші upstream якщо потрібно. Використайте Завдання 12, щоб виявити дублювання MAC на мосту.

8) Симптом: Windows каже «Media disconnected», хоча VM запущено

Причина: NIC не приєднано до мосту, tap відсутній/DOWN або драйвер Windows не зв’язується.

Виправлення: Перевірте наявність tap на мосту (Завдання 2), стан інтерфейсів UP (Завдання 3) і PnP-стан Windows (Завдання 19). Розгляньте тимчасове додавання E1000 лайнлайну (Завдання 14).

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

Чек-лист A: Ви створили нову Windows VM і вона без мережі

1. На хості: qm config <vmid> | grep '^net' → підтвердіть міст, тег, firewall.
2. На хості: bridge link show → підтвердіть, що tap приєднаний до потрібного мосту.
3. На хості: tcpdump -ni tapX → підтвердіть наявність будь-якого трафіку.
4. Якщо трафіку немає: в Windows перевірте Device Manager на відсутній NetKVM; змонтуйте VirtIO ISO і встановіть драйвер.
5. Якщо трафік є, але немає відповідей: перевірте VLAN і firewall; просніффте на фізичній NIC, щоб бачити, чи повертаються відповіді.
6. Після встановлення драйвера: перезавантажте; перевірте, що ipconfig /all показує оренду, а не APIPA.

Чек-лист B: Ви конвертували з E1000 на VirtIO і втратили доступ

1. Не панікуйте і не клацайте без дума; додайте другий E1000 NIC (Завдання 14), щоб відновити доступ.
2. Прикріпіть VirtIO ISO (Завдання 23).
3. Встановіть NetKVM через pnputil (Завдання 25).
4. Перезавантажте.
5. Підтвердіть, що VirtIO адаптер піднятий і має правильний IP.
6. Видаліть E1000 після перевірки працездатності сервісів.

Чек-лист C: APIPA-адреса і таймаути DHCP

1. Хост: tcpdump -ni tap... — чи бачите DHCP DISCOVER/REQUEST?
2. Хост: tcpdump -ni eno1 ... — чи бачите DHCP-відповіді, що повертаються?
3. Якщо відповіді не повертаються: upstream DHCP або порт комутатора неправильний.
4. Якщо відповіді повертаються на хост, але не VM: firewall/міст/VLAN фільтрація на хості неправильні.
5. Тимчасово відключіть firewall на VM для ізоляції, потім увімкніть з коректними правилами.
6. Тільки після валідації шляху: розгляньте оновлення драйвера або налаштування offload.

Чек-лист D: Проблеми при міграції в кластері

1. Порівняйте мости між нодами (/etc/network/interfaces), включно з фільтрацією VLAN.
2. Переконайтеся в однаковій політиці firewall між нодами.
3. Підтвердіть консистентність імен uplink NIC (eno1 проти enpXsY).
4. Запустіть ті ж tcpdump-тести на вихідній і цільовій ноді.
5. Стандартизовуйте конфігурацію; не робіть патчі по-нодно, якщо не хочете повторення інцидентів.

FAQ

1) Чи не краще просто використовувати E1000, щоб Windows завжди працював?

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

2) Моя Windows VM має APIPA. Чи це доводить, що VirtIO драйвер встановлено?

Не обов’язково. Це доводить, що Windows має якийсь інтерфейс і спробував DHCP. Ви все одно маєте перевірити, чи цей інтерфейс — справді VirtIO і чи драйвер у доброму стані.

3) Чи може Proxmox firewall зламати DHCP?

Так. DHCP інтенсивно використовує broadcast і може бути заблокований політиками з дефолтом drop або відсутністю правил. Якщо ви бачите DHCP-відповіді на uplink, але не на tap — підозрюйте firewall/фільтрацію мосту.

4) Потрібен QEMU Guest Agent для мережі?

Ні. Guest Agent допомагає з репортингом IP, вимкненням і автоматизацією. Він не змусить NIC працювати. Але він полегшує життя після того, як NIC працює.

5) Чому це працює на одній ноді, але не після міграції?

Тому що ноди кластера дрейфують. Хтось «швидко пофіксив» міст або фільтр VLAN на одній хості. Міграція перемістила VM у іншу реальність. Стандартизуйте мережеві налаштування на всіх нодах.

6) Що робити, якщо увімкнено Secure Boot і NetKVM не завантажується?

Використайте підписану версію VirtIO драйвера, сумісну з вашою збіркою Windows. Якщо політика дозволяє — вимкніть Secure Boot для цієї VM. Інакше тимчасово використайте E1000, поки не підготуєте підписані драйвери.

7) Чи може тегування VLAN в Proxmox конфліктувати з конфігом комутатора?

Постійно. Якщо VM тегнута VLAN 20, а порт комутатора — access VLAN 1, ви отримаєте тишу. Узгодьте тег VM, фільтрацію VLAN мосту і політику порту фізичного комутатора.

8) Як визначити, чи проблема всередині Windows чи в мережі Proxmox?

Просніффте трафік на tap VM. Якщо бачите DHCP/ARP, що йдуть — Windows принаймні випромінює. Якщо бачите відповіді на uplink, але не на tap — це хост-сторона. Якщо на tap нічого немає — це драйвер/стан адаптера в гості або приєднання NIC у Proxmox.

9) Чи безпечно відключати offloads або зменшувати черги для усунення нестабільності?

Це безпечно як діагностика і часто безпечно довгостроково. Після змін вимірюйте ефект. Offloads можуть допомогти, але також можуть впровадити важкодіагностовані поведінки залежно від драйвера і фільтрації.

10) Який найшвидший крок «повернути онлайн»?

Додайте другий NIC E1000, підніміть VM, встановіть VirtIO драйвери, потім видаліть E1000. Це практично, оборотно і не вимагає здогадок.

Висновок: наступні кроки, щоб уникнути повторення

Виправлення Windows VM без мережі на Proxmox зазвичай не містить містики Windows. Це відсутній VirtIO драйвер, невідповідність мосту, політика брандмауера або майже-правильна конфігурація VLAN. Найшвидший шлях завжди однаковий: перевірте конфігурацію VM, спостерігайте трафік на tap, підтвердіть поведінку мосту і uplink, потім виправляйте драйвер гостя тільки після того, як довели робочість мережевого шляху.

Зробіть наступне:

1. Стандартизувати політику NIC для VM: VirtIO за замовчуванням з драйверами, підготовленими у шаблонах.
2. Тримати страховий шлях: документована процедура «додати E1000 lifeline NIC» для аварійних випадків.
3. Зробити мережу кластера однаковою: ті ж мости, фільтрація VLAN і політика firewall на всіх нодах.
4. Операціоналізувати перевірки: крок tcpdump на tap ловить половину відмов за хвилину.