Короткий ответ
Сеть гостя — это net0 в qm config 101 (мост vmbr0, MAC, модель, firewall=, tag=), состояние Linux bridge на pve1, затем стек внутри VM. Не удаляйте NIC в GUI «создать заново» первым шагом: сменится MAC, DHCP/резервы/лицензии поедут. Сначала bridge link, ip link, ping с гостя и с хоста, правила PVE Firewall.
Если нет сети у самого хоста, это не эта статья — неправильный bridge.
Симптомы и как отличить
Типичная картина:
- гость 169.254/нет IP/нет шлюза;
- с хоста
pingв IP гостя не идёт, в LAN идёт; - после migrate сеть пропала;
- firewall в GUI на VM включён, policy DROP.
Отличия:
| Что видно | Куда |
|---|---|
| Все VM на vmbr0 мертвы, хост тоже | Linux Bridge |
| IP есть в другой VLAN, native нет | VLAN |
| Сеть есть, очень медленно | VM медленно |
| VM не стартует | Старт VM |
Возможные причины
net0не на том bridge (vmbr1вместоvmbr0).- VLAN tag в PVE не совпадает с портом коммутатора.
firewall=1+ пустые/DROP правила на VM или datacenter.- Гость без драйвера virtio (старый Windows), NIC «с восклицанием».
- MAC фильтр на коммутаторе, duplicate MAC после клона без
qm. - В госте неверный IP/маршрут/Windows firewall.
Диагностика
pveversion
qm status 101
qm config 101 | grep -E 'net|boot'
ip -br link
bridge link
cat /etc/network/interfacesОжидание: net0: virtio=AA:BB:...,bridge=vmbr0. Есть tap-интерфейс для 101 в bridge link.
tcpdump -ni vmbr0 ether host AA:BB:CC:DD:EE:FF -c 20
# MAC из net0Нет кадров при ping из гостя — не дошло до bridge (модель/линк/qemu). Кадры есть, ответа нет — VLAN/коммутатор/IP.
Firewall PVE:
cat /etc/pve/firewall/101.fw
# и datacenter.cfg firewallРешение
Сценарий A. Не тот bridge или NIC отключён
В GUI Hardware: Bridge vmbr0, не disconnected. Примените. В госте проверьте, что линк Up.
Сценарий B. Нет драйвера virtio
Временно e1000/e1000e для установки драйвера virtio, затем верните virtio. Не оставляйте e1000 «потому что заработало», если нужен нормальный PPS.
Сценарий C. PVE Firewall
Для теста точечно отключите firewall на net0 (firewall=0) или добавьте ACCEPT ICMP/нужные порты. Не глушите firewall датацентра навсегда. Если без флага firewall сеть появилась — допишите правила, флаг верните.
Сценарий D. VLAN
Сверьте tag= с транком. Подробности — VLAN не проходит.
Сценарий E. Клон и MAC
После clone PVE обычно выдаёт новый MAC. Если клонировали вне PVE — смените MAC в net0, обновите DHCP reservation. Duplicate MAC = флап на коммутаторе.
Сценарий F. Гостевой стек
Статический IP, шлюз, DNS. Windows: профиль сети Public vs Domain. UFW в Linux-госте. Это не чинится сменой vmbr0.
ARP, FDB и firewall datapath
Если кадры с MAC net0 видны на vmbr0, но не на физическом slave — мост не forwarding (stp/hairpin/e1000 offload реже). Если видны на uplink, нет ответа — L3/ACL за гипервизором.
bridge fdb show | grep -i aa:
ip neigh
iptables-save | grep -i 101 || true
nft list ruleset 2>/dev/null | grep -i 101 || true
cat /etc/pve/firewall/cluster.fw | headPVE Firewall в kernel (nft/iptables) фильтрует после tap. firewall=1 на NIC включает VM-специфичные правила из 101.fw. Пустой файл с policy DROP режет всё, включая DHCP. Для теста ICMP разрешите явно, не «disable datacenter firewall».
Клон VM без смены MAC: коммутатор уже привязал MAC к другому порту (того узла, где была исходная VM). Тогда «сеть не работает» только после migrate. Смотрите MAC unique.
IPv6 SLAAC vs выключенный RA на VLAN — отдельная ловушка: IPv4 жив, админ смотрит AAAA. Фиксируйте, какой стек должен работать у 101.
Как проверить, что проблема устранена
Из гостя: ping шлюза, DNS, целевой сервис. С другой машины LAN — ping IP 101. На хосте bridge fdb | grep MAC. qm config 101 стабилен. После ребута VM и после migrate (если используете) сеть сохраняется. Firewall, если нужен, снова включён с явными правилами.
Проверьте qm config 101 на rate= и queues= у net0. Жёсткий rate-limit, забытый после теста, имитирует «сеть не работает» для крупных сессий и оставляет ping живым. Снимите лимит после измерения, не оставляйте 1 Мбайт/с на файловом сервере. Для Windows-гостя отдельно: метрика интерфейса и «неопознанная сеть» режут профили firewall внутри VM — это не vmbr0.
Если не помогло
- Только TCP не ходит, ICMP да: ACL выше, не bridge.
- PXE нет, OS сеть есть: boot order/iPXE, не virtio-net в ОС.
- SPICE/VNC есть, сети нет: консоль не использует
net0. - После смены MTU на vmbr0: симметрия с коммутатором.
- Open vSwitch вместо linux bridge: смотрите ovs-vsctl, не
bridge linkкак единственный инструмент.
Профилактика
- Шаблоны только virtio + cloud-init с правильной сетью.
- Документировать, какой VLAN на каком
tag. - Не клонировать qcow файлами мимо
qm clone. - Мониторинг ping гостей с отдельного зонда.
- Firewall с явным management, не «default deny без ICMP» вслепую.
FAQ
Сколько NIC можно повесить на одну VM?
Несколько net0/net1 на разные bridge. Не плодите NIC вместо VLAN, если политика — теги на одном vmbr0.
model=virtio vs virtio-net-pci?
В qm config достаточно virtio=MAC. Не выдумывайте сторонние модели.
Нужен ли link_down=1?
Это административно выключенный линк. Если кто-то оставил после работ — сеть «не работает».
Хост пингует гостя, другие машины нет?
Promisc/filtering, изоляция порта, Wi-Fi AP isolation на тестовом стенде, или firewall только «не с хоста».
Можно ли дать VM тот же IP, что у pve1?
Нет. Конфликт с management vmbr0.
Стоит ли включить firewall=0 навсегда, если так заработало?
Нет. Это проверка слоя. Верните firewall=1 и опишите ACCEPT для нужных портов и ICMP в 101.fw. Иначе следующий Harden-проход «включит firewall» и сеть снова умрёт без документации правил.