KVM配置虚拟机时网络连接失败，九成出在网桥配置、防火墙规则或虚拟网卡模式上，按顺序排查十分钟内能定位问题。
KVM配置虚拟机时网络连接失败？先分清是哪种“连不上”
很多人在创建虚拟机后发现网络不通,第一反应是重装系统或改配置，结果白折腾，判断故障范围必须先做：虚拟机内部能否ping通网关？外部主机能否访问虚拟机？宿主机自己有没有网络？这些结果直接决定你该往哪个方向查。
先打开虚拟机终端,执行 ip addr 看网卡是否拿到IP，如果IP都没有，说明二层链路有问题，问题多半在虚拟网卡或桥接上，如果有IP但ping不通外网，重点查路由和DNS，如果宿主机访问不了虚拟机，查防火墙和网卡绑定。
常见现象有三种：NAT模式下虚拟机出不去外网；桥接模式下局域网其他机器找不到虚拟机；虚拟机重启后网络失效，每种现象对应的解决方案不同，下面按实操顺序拆解。
检查libvirt默认网络：KVM虚拟机没有网络怎么办
libvirt是KVM最常用的管理工具,它默认提供一个NAT网络 default，很多“没有网络”的情况，其实是这个网络没启动，或者虚拟机的网卡没有连接到它。
登录宿主机,执行：
virsh net-list --all
如果看到 default 状态是 inactive，先启动并设为开机自启：
virsh net-start default virsh net-autostart default
然后查看虚拟机的网卡配置：
virsh dumpxml 虚拟机名称
找到 <interface> 部分，确认 <source network='default'/> 存在，如果是 bridge 且桥接名称写错，也会导致网络不通。
小技巧：如果虚拟机XML里没有网卡，直接编辑XML添加：
<interface type='network'> <source network='default'/> <model type='virtio'/> </interface>
然后执行 virsh define 文件.xml 重新加载。
宿主机上 libvirtd 服务没启动也会导致这种问题，运行
systemctl status libvirtd 检查，若状态异常就 systemctl restart libvirtd，再把虚拟机重启一遍。
虚拟机NAT模式下能拿IP但上不了网？DNS和iptables是主要嫌疑
NAT模式走的是libvirt的虚拟网络,虚拟机从 168.122.x 网段拿IP，这时候如果虚拟机内能ping通网关，但ping不通 5.5.5 这类公网IP，问题通常出在DNS或宿主机IP转发。
先检查虚拟机内DNS配置：
cat /etc/resolv.conf
如果DNS不是 168.122.1 或公共DNS，修改为：
nameserver 192.168.122.1
nameserver 223.5.5.5如果改完还不能解析域名,测试IP连通性，在虚拟机内执行：
ping -c 4 223.5.5.5
能通但 ping www.baidu.com 失败，就是DNS问题，不能通，则需要检查宿主机是否开启了IP转发：
sysctl net.ipv4.ip_forward
输出为 0 时打开转发：
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf sysctl -p
iptables的FORWARD链默认策略为DROP也会拦截流量,查看当前规则：
iptables -L FORWARD -n
如果策略是DROP,添加放行规则：
iptables -I FORWARD -i virbr0 -o eth0 -j ACCEPT iptables -I FORWARD -i eth0 -o virbr0 -j ACCEPT
注意：宿主机如果装了Docker，它的iptables规则经常和libvirt冲突，出现NAT模式下虚拟机突然上不了网，优先排查两者规则顺序。
生产环境推荐桥接模式：KVM虚拟机桥接网络配置方法
NAT模式够用,但如果你想在局域网内直接访问虚拟机IP，或者虚拟机需要对外提供服务，桥接模式才是正解，桥接模式让虚拟机直接占用物理网络中的IP，和宿主机平级。
以CentOS/RHEL系统为例，使用 nmcli 创建桥接最稳妥：
nmcli connection add type bridge ifname br0 con-name br0 nmcli connection modify br0 ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns 223.5.5.5
然后将物理网卡（如eth0）设为桥接端口：
nmcli connection add type ethernet slave-type bridge con-name bridge-port-eth0 ifname eth0 master br0
最后启用br0：
nmcli connection up br0
如果是用传统 /etc/network/interfaces（Debian/Ubuntu），配置如下：
auto br0
iface br0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 223.5.5.5
bridge_ports eth0
bridge_stp off
bridge_fd 0改完重启网络服务,或者 reboot 让桥接生效，然后编辑虚拟机XML，把网卡改为：
<interface type='bridge'> <source bridge='br0'/> <model type='virtio'/> </interface>
坑点提示：在桌面版系统（如Ubuntu Desktop）中，NetworkManager接管网络，手动配置桥接经常失效，建议先停止NetworkManager对物理网卡的管理，再配置br0，否则物理网卡和br0抢IP，虚拟机肯定连不上。
防火墙和SELinux：KVM虚拟机网络连接失败解决步骤里最容易被忽略的一环
桥接配置没问题,虚拟机还是不通，这时候十有八九是宿主机防火墙拦了，KVM的桥接流量默认会经过宿主机的iptables规则，即使同一网段也不例外。
检查并临时关闭firewalld：
systemctl status firewalld systemctl stop firewalld systemctl disable firewalld
如果不想彻底关闭,只放行桥接流量：
firewall-cmd --permanent --zone=trusted --add-interface=br0 firewall-cmd --reload
SELinux也可能限制virbr0的流量,执行：
getenforce
如果结果为 Enforcing，用以下命令先测试：
setenforce 0
确认是SELinux导致后,调整布尔值：
setsebool -P virt_use_network 1
行业共识认为，在KVM宿主机上禁用SELinux比精细配置策略更省心，但生产环境建议根据安全基线决定。
用命令行快速定位网络故障：KVM配置虚拟机网络连不上的排查套路
当上面所有配置都检查过仍无头绪,别猜了，直接抓包看流量走到哪一步断了。
在宿主机上,用 tcpdump 监听桥接接口：
tcpdump -i br0 -n icmp
然后在虚拟机内ping网关,如果宿主机能收到ICMP请求但虚拟机收不到响应，说明是二层通了但路由或防火墙拦截了回包，如果宿主机根本收不到包，问题在虚拟网卡或桥上。
再查看桥接状态下MAC地址表：
brctl show
确认虚拟机对应的vnet接口是否已加入br0,如果vnet0是 no 状态，说明接口没绑定好，需要重建虚拟机网卡。
还有一个常见场景：物理网卡开启了 arp_filter 或 rp_filter，导致桥上ARP学习异常，临时关闭测试：
sysctl -w net.ipv4.conf.all.rp_filter=0 sysctl -w net.ipv4.conf.br0.rp_filter=0
大部分情况下,按照这个顺序排查网络状态、DNS、IP转发、iptables、SELinux、桥接、抓包，KVM虚拟机网络连接失败问题都能在十分钟内定位，别一上来就重装系统，KVM的虚拟网络结构并不复杂，只是每层都有坑。
Q&A：KVM配置虚拟机时网络连接失败相关问题
为什么KVM虚拟机重启后又没有网络？
最常见原因是虚拟机网卡没有在libvirt中配置自动连接,编辑XML时 <interface> 标签内缺少 <link state='up'/>，或者网卡属于临时添加，重启后没有生效，从根本上解决，把网卡配置写进虚拟机XML并重新定义，确保 virsh net-autostart default 已执行，如果是桥接模式，检查br0是否设置开机自启，网络接口在启动时是否按顺序依赖。
KVM虚拟机桥接模式上网速度慢怎么办？
先确认虚拟网卡型号是否为virtio,模拟的e1000和rtl8139性能损耗明显，在虚拟机内用 ethtool -i eth0 查看驱动，若不是virtio，修改XML的 <model type='virtio'/> 并重启虚拟机，同时检查宿主机网卡是否开启了 txqueuelen 和中断合并，这类配置对虚拟化网络吞吐影响较大，据行业经验，virtio驱动比模拟网卡快三到五倍，这是默认推荐方案。