Proxmox «tap device already exists»: як усунути мережеві конфлікти при запуску VM

Що насправді означає ця помилка (і чого вона не означає)

У Proxmox (PVE) ВМ зазвичай запускає pve-qemu-kvm (QEMU), який створює віртуальний NIC
і підключає його до Linux‑мосту (наприклад, vmbr0) через tap‑інтерфейс.
Tap‑інтерфейс — це мережевий пристрій в ядрі, що представляє собою шар‑2 кінцеву точку. QEMU відкриває /dev/net/tun,
запитує в ядрі ім’я tap (зазвичай tap<vmid>i<n>),
а потім Proxmox додає цей інтерфейс до моста.

Помилка «tap device already exists» зазвичай означає одне з наступного:

• Існує застарілий tap‑інтерфейс в неймспейсі ядра, що залишився після попереднього інстансу QEMU,
  який аварійно завершився, або після напівзавершеного перезавантаження мережі.
• Відбувся колізійний VM ID (менш поширено, але реальне явище при клонуванні або некоректных конфігах), через що Proxmox намагається
  повторно використати те ж ім’я tap для двох різних запусків.
• Запущений процес QEMU все ще володіє tap і Proxmox намагається виконати другий старт або форсований старт.
• Провалилося підключення мосту (iptables/nftables hooks, Open vSwitch, порядок reload в ifupdown2), що залишає tap‑и в дивних станах.

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

Парафраз думки Werner Vogels: «Якщо ви побудували — ви керуєте», тобто зворотний зв’язок від експлуатації — частина інженерії, а не післядум.

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

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

1) Підтвердити, що це дійсно колізія імені tap

• Перегляньте лог завдання запуску ВМ і скопіюйте точне ім’я tap, що згадується (tap100i0 тощо).
• Негайно перелічте інтерфейси та пошукайте цей tap.

2) Визначити, чи володіє ним процес QEMU

• Пошукайте запущений процес kvm/qemu-system для відповідного VMID.
• За потреби перевірте дескриптори файлів до /dev/net/tun.

3) Перевірити членство в мосту та стан лінку

• Чи прив’язаний tap до vmbr0?
• Чи піднятий vmbr0? Чи присутній фізичний NIC хоста? Чи узгоджені налаштування VLAN‑aware?

4) Прийняти рішення: чистити лише tap або виправляти життєвий цикл

• Якщо QEMU помер і tap застарілий: видаліть tap і повторіть запуск ВМ.
• Якщо QEMU живий: зупиніть ВМ коректно; якщо вона зависла — завершіть процес QEMU і потім видаліть tap.
• Якщо тригером став reload мережі/автоматизація: припиніть бездумні перезавантаження мережі, особливо на хостах з активними ВМ.

Жарт №1: Помилка «tap device already exists» — це вічно ввічливий Linux, що каже: «Я не злий, я просто розчарований, що ви не прибрали за собою».

Як працюють tap‑пристрої в Proxmox/QEMU (достатньо, щоб бути небезпечним)

QEMU підключає NIC ВМ до хоста кількома поширеними способами:

• TAP + Linux bridge (найпоширеніше в PVE): створюється tap‑інтерфейс; привʼязується до vmbrX.
• TAP + Open vSwitch: схожа ідея, інший шар перемикання та інструментарій.
• veth‑пари / SDN (в деяких конфігураціях): інші імена, інші режими відмов, схожі симптоми.

У класичному PVE ім’я tap‑інтерфейсу детерміноване. Proxmox використовує схему іменування на кшталт:
tap<VMID>i<N>. Отже VM 100, інтерфейс 0 стає tap100i0.
Детермінізм корисний, поки ним не користуватись: якщо tap100i0 існує, новий запуск не зможе його створити.

Здоровий життєвий цикл виглядає так:

1. Proxmox запускає QEMU для VMID.
2. QEMU запитує в ядрі tap‑інтерфейс.
3. Скрипти PVE додають його до моста, застосовують правила фаєрвола, фільтри VLAN, MTU тощо.
4. ВМ працює; tap передає Ethernet‑фрейми.
5. ВМ зупиняється; QEMU закриває tap; зазвичай ядро автоматично видаляє інтерфейс.

Коли ламається — зазвичай крок 5 не завершився. QEMU аварійно впав, отримав SIGKILL, мережа перезавантажувалася в середині операції
або щось зовнішнє (автоматизація, моніторинг, надто енергійний інженер) переграло послідовність teardown.

Якщо ви використовуєте PVE firewall, є більше рухомих частин: пер‑ВМ мости (fwbr*),
фаєрвол‑tap‑пристрої (fwln*, fwpr* залежно від епохи) і застосування правил. Помилки можуть згадувати
tap‑пристрої, але справжня проблема — відмова hook‑а фаєрвола, що лишає часткову підключеність.

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

• Факт 1: TAP/TUN‑пристрої походять з ранньої віртуалізації мереж у Linux; TUN — шар‑3 (IP), TAP — шар‑2 (Ethernet).
• Факт 2: Інтерфейс /dev/net/tun — це межа драйвера в ядрі, яка зробила user‑space мережування практичним задовго до популярності контейнерів.
• Факт 3: QEMU спершу використовував user‑mode networking для зручності; TAP дав кращу продуктивність і реалістичність для продакшн‑навантажень.
• Факт 4: Linux‑мости з’явилися раніше за сучасні SDN‑модні слова; вони нудні в найкращому сенсі — просте переадресування і передбачувана поведінка.
• Факт 5: Детерміноване іменування Proxmox (tap<vmid>i<n>) — це свідомий компроміс: простіше діагностикувати, але вища ймовірність колізій при некоректному очищенні.
• Факт 6: ifupdown2 з’явився через те, що класичний ifupdown мав труднощі з порядком залежностей; він кращий, але reload‑и все ще можуть бути руйнівними при неправильному використанні.
• Факт 7: Open vSwitch набув популярності, бо давав програмований софт‑свіч роками раніше, ніж ядро‑міст отримав подібні можливості для багатьох випадків.
• Факт 8: Фаєрвол Proxmox інтегрується на рівні хоста; він створює додаткові віртуальні пристрої для застосування правил на рівні ВМ, щоб самі гості цього не знали.

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

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

Task 1: Get the exact error and tap name from the VM start log

cr0x@server:~$ qm start 100
kvm: tap100i0: Device or resource busy
TASK ERROR: start failed: command '/usr/bin/kvm -id 100 ...' failed: exit code 1

Значення: Ядро відмовило у створенні/підключенні tap‑інтерфейсу. Ім’я tap100i0 — ваш первинний ключ.
Рішення: Не перезавантажуйте. Подивіться, хто володіє tap100i0.

Task 2: Check whether the tap interface exists right now

cr0x@server:~$ ip -d link show tap100i0
26: tap100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 6a:4b:3c:de:11:90 brd ff:ff:ff:ff:ff:ff promiscuity 1 minmtu 68 maxmtu 65535
    tun type tap pi off vnet_hdr on persist off

Значення: Tap існує. Він може бути застарілим або належати ще працюючому QEMU.
Рішення: Перед видаленням перевірте процес VM і членство в мосту.

Task 3: Check if the VM is actually running (sometimes it is)

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

Значення: Proxmox вважає її зупиненою. Це не гарантує, що QEMU помер.
Рішення: Пошукайте процеси QEMU, що посилаються на VMID 100.

Task 4: Find QEMU process for the VMID

cr0x@server:~$ pgrep -a -f "qemu.*-id 100"
21477 /usr/bin/kvm -id 100 -name vm100 -m 8192 -smp 4 ...

Значення: QEMU ще живий. Ваш tap не застарілий; він у використанні.
Рішення: Зупиніть ВМ коректно (або вбийте застряглий процес), замість того щоб видаляти інтерфейс під ним.

Task 5: Attempt a clean stop; then confirm process exit

cr0x@server:~$ qm stop 100 --timeout 60
stopping vm: 100

cr0x@server:~$ pgrep -a -f "qemu.*-id 100" || echo "no qemu process"
no qemu process

Значення: Чисте завершення вдалося.
Рішення: Перевірте, чи tap автоматично зник; якщо ні — маєте залишкову підкладку.

Task 6: If QEMU is gone but tap remains, confirm it’s not enslaved and delete it

cr0x@server:~$ bridge link show dev tap100i0
26: tap100i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0

Значення: Він ще прикріплений до vmbr0.
Рішення: Спочатку видаліть його з мосту, потім видаліть інтерфейс. Інакше можна залишити неконсистентний стан мосту.

cr0x@server:~$ ip link set dev tap100i0 nomaster
cr0x@server:~$ ip link delete tap100i0

Значення: Tap видалено.
Рішення: Повторіть запуск ВМ; якщо помилка повториться, дослідіть, чому taps не прибираються при зупинці/аварії.

Task 7: If QEMU is stuck and won’t stop, kill the right process (safely)

cr0x@server:~$ qm stop 100 --timeout 10
stopping vm: 100
TASK ERROR: timeout waiting on systemd

cr0x@server:~$ pgrep -a -f "qemu.*-id 100"
21477 /usr/bin/kvm -id 100 -name vm100 -m 8192 ...

cr0x@server:~$ kill -TERM 21477
cr0x@server:~$ sleep 3
cr0x@server:~$ kill -KILL 21477

Значення: ВМ застрягла; ви примусово завершили QEMU.
Рішення: Тепер приберіть залишкові tap‑и або фаєрвол‑мости і перевірте консистентність зберігання, якщо ВМ була під навантаженням.

Task 8: List all taps; spot a pattern (mass leakage)

cr0x@server:~$ ip -o link show | awk -F': ' '{print $2}' | grep -E '^tap[0-9]+i[0-9]+$' | head
tap100i0
tap104i0
tap104i1
tap205i0

Значення: Ви бачите існуючі tap‑пристрої. Якщо бачите taps для «зупинених» ВМ — шлях очищення зламаний.
Рішення: Корелюйте tap‑и зі станом ВМ перед масовим видаленням.

Task 9: Map a tap to a VM config (confirm NIC index)

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 net0 має бути на vmbr0, VLAN‑тег 20, фаєрвол увімкнений.
Рішення: Якщо tap існує, але ВМ зупинена — зосередьтеся на шляхах зупинки/фаєрвола, а не на базових налаштуваннях мосту.

Task 10: Check the bridge is healthy and has the right ports

cr0x@server:~$ bridge -d link show master vmbr0 | head -n 15
2: eno1 state UP priority 32 cost 100 hairpin off guard off root_block off fastleave off learning on flood on mcast_flood on
26: tap100i0 state UP priority 32 cost 2 hairpin off guard off root_block off fastleave off learning on flood on mcast_flood on

Значення: Міст бачить фізичний NIC і tap (коли він присутній).
Рішення: Якщо eno1 відсутній або вниз, ваша проблема може бути спричинена некоректним reload мережі, а не очищенням tap.

Task 11: Check ifupdown2 / networking reload history (the usual suspect)

cr0x@server:~$ journalctl -u ifupdown2-pre -u ifupdown2 -u networking --since "2 hours ago" | tail -n 25
Dec 26 09:12:03 server ifupdown2[18210]: info: executing /usr/share/ifupdown2/sbin/ifreload -a
Dec 26 09:12:04 server ifupdown2[18210]: warning: vmbr0: port tap100i0 does not exist
Dec 26 09:12:06 server ifupdown2[18210]: error: vmbr0: bridge reload failed: Device or resource busy

Значення: Відбувся reload; він наткнувся на tap‑пристрої посеред операції.
Рішення: Не робіть глобальних ifreload -a під час робочих годин на хостах‑гіпервайзерах. Використовуйте цілеспрямовані зміни та вікна обслуговування.

Task 12: Check for a lock file or failed task holding state

cr0x@server:~$ ls -l /var/lock/qemu-server/ | head
-rw-r----- 1 root www-data 0 Dec 26 09:10 lock-100.conf

Значення: Існує лок файлу для VM 100. Він може бути легітимним (операція триває) або застарілим (аварійне завдання).
Рішення: Перевірте, чи виконується якась операція qm. Не видаляйте локи навмання, якщо не впевнені, що нічого не активне.

Task 13: Confirm no active qm operations for that VM

cr0x@server:~$ pgrep -a -f "qm (start|stop|migrate|clone|restore) 100" || echo "no active qm operation"
no active qm operation

Значення: Очевидних операцій qm не знайдено.
Рішення: Якщо Proxmox відмовляє в діях через лок, дослідіть логи завдання; розгляньте очищення локу лише після перевірки, що QEMU зупинений і операції зі сховищем не виконуються.

Task 14: Find who’s holding /dev/net/tun (advanced but decisive)

cr0x@server:~$ lsof -n /dev/net/tun | head -n 10
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
kvm     21477 root   19u   CHR  10,200      0t0  102 /dev/net/tun

Значення: PID 21477 володіє tun/tap. Якщо ВМ мала бути зупинена, ви знайшли свого привида.
Рішення: Виправте життєвий цикл процесу (чисте завершення, kill, дослідження причин зависання) перед мережевими маніпуляціями.

Task 15: If Proxmox firewall is enabled, check for leftover fw bridges

cr0x@server:~$ ip -o link show | awk -F': ' '{print $2}' | grep -E '^(fwbr|fwln|fwpr)[0-9]+'
fwbr100i0
fwln100i0
fwpr100p0

Значення: Існують пристрої, пов’язані з фаєрволом для VM 100.
Рішення: Якщо ВМ зупинена, але ці пристрої лишилися, шлях teardown‑а фаєрвола не працює — часто через перервані операції або помилки при застосуванні правил.

Task 16: Validate VLAN-aware bridge config vs VM tag usage

cr0x@server:~$ grep -nE '^(auto|iface|bridge-vlan-aware|bridge-vids|bridge-ports|mtu)' /etc/network/interfaces
12:auto vmbr0
13:iface vmbr0 inet static
17:    bridge-ports eno1
18:    bridge-stp off
19:    bridge-fd 0
20:    bridge-vlan-aware yes
21:    bridge-vids 2-4094
22:    mtu 1500

Значення: Увімкнено VLAN‑aware міст і дозволені теги 2–4094.
Рішення: Якщо bridge-vlan-aware вимкнений або bridge-vids виключає VLAN‑тег ВМ, старти можуть падати дивним чином (включно з частковим створенням пристроїв).

Жарт №2: Перезавантаження мережі на гіпервізорах — це як «швидкі правки» в схемі бази даних: швидко, поки ви не зіткнулися з реальністю.

Шаблони виправлень, які дійсно працюють

Pattern A: Stale tap after crash → delete it, then investigate the crash path

Якщо QEMU помер, а tap лишився — видаляти tap допустимо. Але на цьому не зупиняйтесь.
Застарілі пристрої свідчать, що щось перервало нормальний teardown. Знайдіть це «щось», інакше воно повториться в найгірший момент змін.

Типові винуватці:

• OOM‑кіл хоста, що вбиває QEMU
• Ручний kill -9 під час паніки
• Перезавантаження мережі під час подій життєвого циклу ВМ
• Відмови hook‑ів фаєрвола, що лишають часткові пристрої

Pattern B: “Stopped” VM but QEMU still running → fix state mismatch

Якщо qm status показує stopped, але QEMU ще працює, у вас розбіжність між management‑plane і data‑plane.
Це може статися після невдалої міграції, застряглої зупинки або перезапуску демона управління в невірний час.

Зробіть так:

1. Підтвердьте PID QEMU для цього VMID.
2. Спробуйте коректну зупинку.
3. Якщо не вдається, завершіть процес і приберіть залишкові пристрої.
4. Потім з’ясуйте, чому він завис: затримки сховища, блокування бекапу, помилка ядра або проблемні драйвери в гості.

Pattern C: Bridge reloads are causing tap collisions → stop reloading “everything”

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

Що робити натомість:

• Вносьте цілеспрямовані зміни: оновіть один блок bridge, застосуйте одну зміну інтерфейсу, перевірте, і лише потім продовжуйте.
• Плануйте reload мережі в вікно обслуговування з планом відкату.
• Якщо потрібно змінювати live — мігруйте ВМ з хоста спочатку. Так, це займає більше часу, але уникнете драми.

Pattern D: Proxmox firewall devices linger → treat firewall as a first-class dependency

Коли фаєрвол увімкнений для ВМ (firewall=1 в конфігу ВМ), PVE вставляє додаткові віртуальні пристрої і правила.
Якщо застосування правил не вдалось (несумісність backend‑ів nftables/iptables, пошкоджений набір правил, проблеми з модулем ядра), ви можете отримати пристрої, що існують, але не підключені правильно.

Практична позиція: якщо ви використовуєте PVE firewall, тестуйте reload‑и та оновлення фаєрвола так само ретельно, як оновлення сховища. Це частина dataplane.

Pattern E: Open vSwitch environments → use OVS tools, not bridge tools

Якщо ваш Proxmox‑хост використовує OVS, команди для Linux‑моста можуть вводити в оману. Tap може існувати, але бути підключеним (або ні) через OVS.
Підтвердіть стек: vmbr0 як Linux‑міст і vmbr0 як OVS‑міст — різні речі з однаковою назвою.

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

1) Симптом: старт ВМ падає миттєво; tap‑пристрій існує; ВМ «зупинена»

Корінна причина: Застарілий tap‑інтерфейс, що залишився після крашу/kill/reload.

Виправлення: Підтвердьте, що жоден процес QEMU його не використовує; видаліть з мосту; видаліть tap; повторіть старт. Потім розберіться, чому QEMU помер або teardown не відбувся.

2) Симптом: ВМ показує «зупинена», але ви бачите процес QEMU

Корінна причина: Розбіжність станів після провального stop/migrate; завдання управління впало; демон управління перезапустився під час операції.

Виправлення: Коректно зупиніть або завершіть PID QEMU; приберіть залишкові tap‑и; перевірте логи завдань і історію міграцій перед повторною автоматизацією.

3) Симптом: Помилки з’являються одразу після запуску ifreload/ifupdown2

Корінна причина: Reload мережі перетинається з створенням tap/зміною портів мосту; міст зайнятий; часткова реконфігурація.

Виправлення: Уникайте глобальних reload‑ів на активних гіпервізорах. Якщо вже зламалось: зупиніть уражені ВМ (або мігруйте), стабілізуйте конфіг мережі, потім перезапустіть ВМ.

4) Симптом: Tap існує, але не прикріплений до очікуваного мосту

Корінна причина: Помилка hook‑скрипта при enslaving tap; plumbing фаєрвола не спрацював; неправильна назва мосту в конфігу ВМ.

Виправлення: Перевірте, чи в qm config вказаний міст збігається з мостами хоста. Перевірте наявність фаєрвол‑пристроїв. Видаліть застарілі пристрої і повторіть старт після виправлення конфігурації.

5) Симптом: Тільки ВМ з увімкненим фаєрволом не стартують

Корінна причина: Проблеми бекенду PVE firewall (несумісність nftables/iptables), биті правила або залишкові фаєрвол‑мости.

Виправлення: Перевірте сервіс фаєрвола і правила; приберіть залишкові fwbr*/fwln* пристрої для зупинених ВМ; перезапустіть сервіси фаєрвола обережно.

6) Симптом: Трапляється під навантаженням; «Device or resource busy»

Корінна причина: Тиск ресурсів хоста, повільне сховище, що викликає зависання stop/start послідовностей, або баги ядра/драйверів, що уповільнюють очищення.

Виправлення: Перевірте тиск пам’яті хоста, затримки I/O і чергу завдань. Усуньте корінну проблему перш ніж ганятися за «застарілими tap‑ами» без кінця.

7) Симптом: Дві ВМ або клони борються за одне й те ж ім’я tap

Корінна причина: Дублювання VMID між нодами, неправильні ручні правки або робочий процес відновлення/клонування, що створив конфліктні ID на одному хості.

Виправлення: Забезпечте унікальні VMID на хості; виправте конфіги; не копіюйте вручну файли конфігурації без коригування ID і пов’язаного стану.

Три корпоративні міні‑історії (бо в реальності є сюжет)

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

Середня компанія мала Proxmox‑кластер, що хостив внутрішні build‑агенти і кілька «тимчасових» сервісів, що стали постійними.
В одну п’ятницю вночі ВМ відмовилася стартувати з помилкою tap‑already‑exists. Інженер on‑call побачив tap в ip link
і припустив, що його безпечно видалити, бо qm status показував «stopped».

Видалення спрацювало — частково. ВМ стартувала, але мережа стала флапати. За кілька хвилин інший сервіс на тому ж хості впав.
Вони виявили ще працюючий процес QEMU для тієї «зупиненої» ВМ. Proxmox втратив про нього слід після невдалого stop під час попереднього вікна бекапу.
Tap не був застарілим; він був живим і передавав трафік.

Видалення tap під активним QEMU змусило мережу QEMU поводитись невизначено. Деякі гостьові системи продовжували відправляти кадри в нікуди,
інші перепідключилися після спроб. Схоже було на проблему зі свічем, бо симптоми були розподілені й дивні.

Фактичне виправлення було нудним: знайти stray PID QEMU, зупинити його коректно (або термінувати), прибрати залишкові інтерфейси, потім запустити ВМ.
Вони додали правило в runbook: ніколи не довіряти лише qm status при проблемах з tap — завжди підтверджуйте PID QEMU.

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

Інша організація вирішила, що їхні Proxmox‑ноди занадто довго застосовують мережеві зміни під час деплоїв. Хтось додав «оптимізацію»:
крок pipeline, що запускав ifreload -a на кожному гіпервізорі після оновлення спільного шаблону /etc/network/interfaces.
Ідея була проста: «Конфіг мережі консистентний; reload не порушить».

Насправді у них були активні ВМ із tap‑інтерфейсами, що постійно зʼявлялися і зникали через CI‑навантаження.
Глобальний reload іноді запускався саме тоді, коли ВМ стартувала або зупинялася. Більшість разів усе працювало.
Інколи — ні, і саме ці інциденти запам’ятовували люди.

Режим відмови був підступний: старт ВМ створював tap, а reload намагався приміряти порти мосту і фільтри VLAN посеред створення.
Ви отримували колізії tap, помилки bridge busy і залишкові фаєрвол‑пристрої. Гіпервізор не «впав», але опинився в напівзламаному стані.

Вони відкочували зміну pipeline і ввели політику: мережеві зміни вимагають евакуації (live‑міграції ВМ з хоста), потім застосування змін і повернення.
Повільніше? Так. Але «оптимізація» торгувала надійністю за зручність без повідомлення.

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

Фінансова команда керувала Proxmox з суворим change‑control. Їхня процедура проста: для кожного хоста — міграція ВМ, зміни, післячек, що включав перевірку залишкових tap і фаєрвол‑пристроїв.

Одного дня нода пережила транзитну затримку зі сховищем. Декілька ВМ перестали відповідати, і один процес QEMU аварійно впав.
Коли команда намагалася перезапустити ВМ, вони натрапили на помилку tap‑already‑exists. Нічого дивного.

Те, що врятувало їх, — процеси вже включали: перевірити PID QEMU, підтвердити існування tap, видаляти лише коли він без власника і перевірити здоров’я мосту.
Вони відновили сервіс швидко, не впливаючи на інші ВМ. Постінцидентний звіт був чистим, оскільки чеклісти фіксували таймстемпи і виводи.

Урок не в «бути обережним». Він у тому, що повторювані механіки перемагають героїзм. Їхня нудьга була перевагою, а не вада.

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

Чекліст 1: Одна ВМ не стартує (tap already exists)

1. Отримайте ім’я tap з невдалого старту (tap<vmid>i<n>).
2. Підтвердіть існування tap: ip link show tapX.
3. Перевірте, чи запущений QEMU для цього VMID: pgrep -a -f "qemu.*-id <vmid>".
4. Якщо QEMU працює: зупиніть ВМ коректно (qm stop). Якщо застрягла — завершіть PID QEMU.
5. Якщо QEMU не працює: видаліть tap з будь‑якого мосту (ip link set dev tapX nomaster).
6. Видаліть tap: ip link delete tapX.
7. Якщо фаєрвол увімкнений: перевірте і приберіть залишкові fwbr*/fwln* пристрої для цього VMID.
8. Повторіть: qm start <vmid>.
9. Після відновлення: перегляньте логи навколо моменту, коли це сталося (reload мережі, OOM, краш).

Чекліст 2: Багато ВМ падають (системна проблема)

1. Припиніть вносити зміни. Особливо перезавантаження мережі.
2. Перевірте навантаження хоста і тиск пам’яті; якщо OOM вбиває QEMU — tap‑и будуть текти і рестарти будуть трястися.
3. Перевірте логи ifupdown2/networking на спроби reload і помилки.
4. Валідуйте стан мостів: присутній фізичний NIC, міст піднятий, налаштування VLAN послідовні.
5. Виберіть одну ВМ і пройдіть чекліст для одиночної ВМ, щоб підтвердити метод очищення.
6. Тільки потім розгляньте масове очищення (і лише для tap‑ів, що належать зупиненим ВМ без PID QEMU).

Чекліст 3: Запобігти повторенню (що змінити в операціях)

1. Забороніть «перезавантажувати мережу на всіх нодах» як стандартний крок автоматизації.
2. Зробіть перевірку «QEMU PID vs qm status» частиною стандартного дебагу.
3. Обережно оновлюйте бекенди фаєрвола; тестуйте створення/видалення фаєрвол‑пристроїв.
4. Моніторте наявність залишкових tap‑пристроїв для зупинених ВМ; надсилайте алерти до того, як це стане інцидентом.
5. Документуйте безпечну процедуру очищення і вимагайте її під час реагування на інциденти.

FAQ

1) Чи безпечно видаляти tap‑інтерфейс вручну?

Так — якщо жоден запуск QEMU його не використовує. Підтвердіть за допомогою pgrep і/або lsof /dev/net/tun.
Якщо QEMU активний, видалення tap може творчо зламати мережу запущеної ВМ.

2) Чому Proxmox повторно використовує те саме ім’я tap щоразу?

Детерміноване іменування відображає tap на VMID і індекс NIC, що спрощує діагностику і plumbing фаєрвола.
Компроміс — колізії при невдалому очищенні.

3) Чому це відбувається після операцій клонування або відновлення?

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

4) Чи робить увімкнений фаєрвол Proxmox ситуацію гіршою?

Він додає рухомі частини. Більше пристроїв, більше hook‑ів, більше шансів лишити залишки при перерваній операції.
Це не означає «не користуйтесь фаєрволом». Це означає — тестуйте і працюйте з ним цілеспрямовано.

5) Я видалив tap, але помилка повернулась одразу — чому?

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

6) Чи можна просто перезавантажити хост, щоб виправити це?

Перезавантаження очищає пристрої ядра і процеси, отже так, часто «працює».
Але це також зупиняє всі ВМ на хості і приховує корінну причину. Використовуйте як останній засіб, а не першу реакцію.

7) Як зрозуміти, чи ifupdown2 reload — тригер?

Шукайте кореляцію в journalctl для сервісів ifupdown2/networking і помилок про reload мосту, зайняті пристрої або відсутні порти tap.
Якщо кластер помилок з’являється відразу після reload‑ів — ви знайшли тригер.

8) Чи пов’язано це з MTU або налаштуванням VLAN?

Іноді. Неправильні MTU/VLAN зазвичай викликають проблеми з доступністю, але під час старту вони можуть спричиняти помилки hook‑скриптів,
залишаючи частково створені пристрої. Перевірте відповідність налаштувань bridge VLAN‑aware і тегів ВМ.

9) А контейнери (LXC) — чи використовують вони tap‑пристрої?

LXC зазвичай використовує veth‑пари, а не tap‑и, тому точна помилка «tap already exists» більше характерна для ВМ/QEMU.
Але операційна тема однакова: залишкові віртуальні інтерфейси після перерваних lifecycle‑подій.

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

«Tap device already exists» — це не містична карма Proxmox. Це проблема життєвого циклу ресурсів з іменем.
Усунути її можна системно: ідентифікуйте tap, знайдіть процес‑власник, безпечно приберіть і потім усуньте тригер.

Наступні кроки, що дають миттєвий ефект:

• Прийміть план швидкої діагностики: ім’я tap → PID QEMU → членство в мосту → очищення.
• Перестаньте робити глобальні reload‑и мережі на активних гіпервізорах. Евакуюйте або плануйте.
• Додайте легкий аудит: алерт на tap‑и, що належать зупиненим ВМ (це ранній дим).
• Якщо фаєрвол задіяний — ставтесь до нього як до dataplane‑коду: зміни потребують тестування і плану відкату.

Вам не потрібна удача. Вам потрібно менше невідомих.