问题描述：
部署PVE后， 想着在上面部署多个不同VLAN的VM （类似于VMwarere ESXi），但有人反馈无法使用VLAN，只能配置部署PVE时使用的网段。
问题分析：
- 在PVE的主机节点网络配置中，默认有一个vmbr0的网桥（还是这么古老的概念），也就是一个虚拟机的交换机。部署PVE时配置的IP就在这个网桥上。 具体信息如下：
从目前看到的现象是：无论是否勾选VLAN感知，在物理交换机一侧必须配置access 接口，不能配置trunk，否则，PVE将会无法连接。
- 物理交换机配置trunk，仍能访问PVE主机的说明
PVE主机在创建网络时，有一个linux vlan的选项，创建时，vlan后面跟的数字就是vlan 号，比如：
这里是将绑在vmbr0上的pve地址删掉后，在这个vlan8上配置了pve主机地址，注意vlan原始设备要绑定到vmbr0的同一个网卡。
这时，vmbr0网桥上的配置如下：
然后将配置应用下：
这时，需要调整物理交换机的端口配置，改为使用trunk，允许 8 100两个vlan。
这个时候，就可以正常访问PVE的主机地址192.168.8.228的8006端口了。
2. 物理交换机配置trunk，PVE VM的使用不同vlan
在pve vm的网络配置选项中，只能选择桥接设备，不能选择配置的vlan，比如已经配置的vlan8 , 但可以选择vlan标签，不过配置后，貌似vm不能正常访问网络。
比较诡异的地方是：在交换机上能够解析到vm的ip和mac，但vm和交换机两侧均无法ping通对方。
更加奇怪的是，通过在pve主机上抓包，可以看到vm的arp解析请求已经通过广播发出，并且对端也回应了arp请求，返回了mac。
3. 最终解决方案及思路
无意中将上面配置的vlan100 删除，结果配置了vlan100 的vm 就可以正常工作了。梳理下思路：
（1）首先，要将PVE的管理IP配置正确。
很多人尝试不能成功，就在于一直将管理IP配置在了vmbr0 网桥上，这种情况下，物理交换机必须配置成access接口而不是trunk，否则将永远无法成功连接PVE。
（2）pve上的linux vlan是做什么用的？
PVE上配置的linux vlan实际上是在虚拟网桥基础上配置了一个三层接口，这个三层IP地址实际上是分配给PVE主机使用的，而不是分配给VM使用的。理解这一点非常重要，因为如果按照正常的网络逻辑，既然是交换机的三层接口，那vm配置对应的vlan就应该能够访问这个三层接口，而实际上这个永远不可行，并且此时vm也无法访问外部的物理网络。
仔细查看前面的截图即可发现这一点，vm配置vlan100的tag后，无论是虚拟的三层接口（在vlan100上），还是外部物理交换机上属于vlan100的三层接口，都无法ping通，而抓包可以看到arp请求信息和返回信息都已经成功出现，说明arp请求正常，对端IP也正常回应了arp请求，但到了PVE主机就不走了，说明恰恰是PVE主机拦截了arp请求的返回数据给vm。而在删除linux vlan100的配置后，vm就可以正常访问物理交换机上配置的vlan100的三层IP了。这些都在说明是PVE系统故意如此做的，那PVE为什么要这么做呢？
进一步探讨下，这个linux vlan 是给PVE主机分配的，是用于PVE管理使用的。 从管理角度看，好像是系统设计者是想通过这种方式，有意识地将管理VLAN和VM使用的VLAN分离开来。 如果配置了这个linux vlan，那么VM就不能正常使用这个VLAN了，唯一不足是系统没有提示，带来的结果就是VM可以配置到这个VLAN，但网络不会正常工作。
理解了这一点，那么PVE的多VLAN配置就相当简单了：
首先要将管理IP从vmbr0上剥离开，在新增的linux vlan上配置管理IP。
其次，vmbr0 配置vlan 感知，并配置允许的VLAN 号，应用配置。
在物理交换机上的相应端口配置trunk和允许vlan通过。
第四，在VM上配置网络设备到特定VLAN ,只需要注意不要使用管理IP所在的VLAN即可。
