境外网站搭建,市场营销策划咨询,wordpress通知邮件美化,高端科技产品网站建设ESXi里的FreeBSD装bhyve Ubuntu子系统#xff0c;子系统里无法ping通外面#xff0c;除了宿主机#xff0c;其它ip都ping不通。#xff08;另一台FreeBSD物理机同样的bhyve ubuntu子系统#xff0c;网络就是通的#xff0c;但是TrinityCore服务lag延时很大#xff09;
…ESXi里的FreeBSD装bhyve Ubuntu子系统子系统里无法ping通外面除了宿主机其它ip都ping不通。另一台FreeBSD物理机同样的bhyve ubuntu子系统网络就是通的但是TrinityCore服务lag延时很大
比如Ubuntu子系统设为192.168.1.22 宿主系统是192.168.1.250, 网段里还有192.168.1.1 192.168.1.2 192.168.1.5等设备但是除了能ping通1.250,其它都ping不通。
而且ping通1.250延时也要3-5ms速度慢这一点跟以前的一台系统问题一样。
ping 192.168.1.1
from 192.168.1.13 Destination Host Unreachable freebsd bhyve ping from 192.168.1.13 Destination Host Unreachable
尝试解决问题
先比较两台系统的rc.conf文件发现新系统里有一句重复的
kld_listnvidia-modeset vmm if_tuntap if_bridge nmdm kld_listvmm if_tuntap if_bridge nmdm 正好也已经把Nvidia显卡直通给去掉了所以把上面那句注释掉重启系统。
另外发现可以不用pf所以把pf_enableYES也注释掉。
修改后问题照旧。手工关闭pf: service pf onestop ,关闭之后还是不行。 在宿主机上检查发现自己能看到arp表
? (192.168.1.22) at 00:a0:98:25:10:21 on vmx0 expires in 1178 seconds [ethernet] 192.168.1.22就是虚拟子系统的ip 查看/var/log/syslog文件发现很多提示
systemd-resolved Using degraded feature ste TCP instead of UDP for DNS server 192.168.1.1 使用cbsd新创建了一个bhyve虚拟机发现在用光盘安装系统的时候就dhcp拿不到ip事实证明虚拟机网络就是不通的..... 跟另一台系统比较发现uuid一样修改成0自动获取。
改了之后问题未解决。 修改net.link.tap.up_on_open参数
sysctl net.link.tap.up_on_open1
没起作用。 前期碰到过这个问题的但是当时是jail 没有注意bhyve是否正常FreeBSD jail虚拟机突然全都不能上网了无头绪、未解决-CSDN博客 在宿主机使用netstat -rnl4查看网络情况
输出情况
netstat -rnl4 Routing tables
Internet: Destination Gateway Flags Nhop# Mtu Netif Expire default 192.168.1.1 UGS 4 1500 igb0 10.0.0.1 link#2 UH 5 16384 lo0 127.0.0.1 link#2 UH 1 16384 lo0 192.168.1.0/24 link#1 U 2 1500 igb0 192.168.1.5 link#2 UHS 3 16384 lo0 192.168.1.15 link#2 UHS 3 16384 lo0
然后看到这个提示Solved - bhyve host and guest cannot reach out to each other | The FreeBSD Forums I think it makes sense... assuming that the guest is also on 192.168.50.0/24, then the host is routing packets to it out ue0. So youll need to add a static route to the guest IP to go to tap0 (or maybe vm-public would work). 我有点明白了有台服务器之所以能通是因为它还有个192.168.1.15地址做了周转。如果没有这个ip它应该也不通。这也能解释为什么这台系统的网络有点慢因为它绕路了。 但是我把1.12的jail停掉后还是能通.... 查看pf设置
正常机/usr/jail/etc/pf.conf文件
## include NAT rules include /usr/jails/etc/pfnat.conf
# or: # nat-anchor /usr/jails/etc/pfnat.conf ## include RDR rules include /usr/jails/etc/pfrdr.conf 两者一样
pfnat.conf ,正常的
nat on igb0 from 10.0.0.0/8 to ! 10.0.0.0/8 - 192.168.1.5 # // Setup by CBSD NAT nat on igb0 from 172.16.0.0/12 to ! 172.16.0.0/12 - 192.168.1.5 # // Setup by CBSD NAT
不正常的
nat on vmx0 from 10.0.0.0/8 to ! 10.0.0.0/8 - 192.168.1.250 # // Setup by CBSD NAT nat on vmx0 from 172.16.0.0/12 to ! 172.16.0.0/12 - 192.168.1.250 # // Setup by CBSD NAT
可见两者也是一致的况且本次用的桥接也不涉及nat部分
两者cbsd的版本也一样
cbsd --version 14.1.0
查看/etc/rc.conf /boot/loader.conf文件
两台系统也一样 。
发现两台系统一台14.1beta 一台14.0,不会是因为FreeBSD版本不同导致的吧 另外正常机器没有在/etc/rc.conf 设置pf_loadYES而是在/boot/loader.conf文件中设置的
pf_loadYES 查看/usr/jails/jails-system/ub12 目录里的配置
bhyve.conf文件
网卡配置
正常的
nic_args -s 5,virtio-net,tap2,mtu1500,mac00:a0:98:31:84:3b uefi_boot_args-s 1,ahci-cd,/usr/local/cbsd/upgrade/patch/efirefd.fd,ro dsk_args-s 4,virtio-blk,/usr/jails/vm/ub12/dsk1.vhd,sectorsize512/4096
不正常的
nic_args -s 5,virtio-net,tap3,mtu1500,mac00:a0:98:25:10:21 -s 4,virtio-net,tap4,mtu15 00,mac00:a0:98:f7:e5:f5 uefi_boot_args-s 1,ahci-cd,/usr/local/cbsd/upgrade/patch/efirefd.fd,ro dsk_args-s 7,virtio-blk,/usr/jails/jails-data/ub12-data/dsk1.vhd,sectorsize512/4096
不明白为什么这里多出来 -s 4,virtio-net,tap4,mtu15 00,mac00:a0:98:f7:e5:f5 这一段
最后部分正常的
mytap_tap2_membersbridge1
不正常的
mytap_tap3_membersbridge1 mytap_tap4_membersbridge1
问题是正常的有tap1和tap2
tap1: flags8903UP,BROADCAST,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 description: CBSDSYSTEM0 options80000LINKSTATE ether 58:9c:fc:10:ff:89 groups: tap media: Ethernet 1000baseT full-duplex status: no carrier nd6 options29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL tap2: flags1008943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP metric 0 mtu 1500 description: ub12-nic0 options80000LINKSTATE ether 58:9c:fc:10:ff:d9 groups: tap vm-port media: Ethernet 1000baseT full-duplex status: active nd6 options29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL Opened by PID 90163
而不正常的没有tap3和tap4啊这是怎么回事呢
修改将不正常的参照正常的进行修改也就是这两句
nic_args -s 5,virtio-net,tap3,mtu1500,mac00:a0:98:25:10:21
mytap_tap2_membersbridge1
问题照旧 峰回路转看到pf里这一句
# See pf.conf(5) and /usr/share/examples/pf for syntax and examples. # Remember to set gateway_enableYES and/or ipv6_gateway_enableYES # in /etc/rc.conf if packets are to be forwarded between interfaces. 在rc里面加上 手工创建bhyve测试
Chapter 24. Virtualization | FreeBSD Documentation Portal truncate -s 16G guest.img
wget https://mirrors.ustc.edu.cn/freebsd/releases/ISO-IMAGES/14.1/FreeBSD-14.1-RELEASE-amd64-bootonly.iso sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 1024M -t tap0 -d guest.img \-i -I FreeBSD-14.1-RELEASE-amd64-bootonly.iso guestname
结果安装系统的时候网络就是不通的。
完全参考手册创建网络端口
哦哦发现没有创建tap0 而且也没有把tap0和vmx0放入bridge0 中现在准备用tap1口来启动所以命令应该是 sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 1024M -t tap1 -d guest.img \-i -I FreeBSD-14.1-RELEASE-amd64-bootonly.iso guestname
还是不行....
准备看看ESXi是否把网卡设为混杂模式了
设为混杂模式还是不通。设置文档ESXi中设置网卡为混杂模式-CSDN博客 问题总结
在做了大量实验后问题还是没有解决。不过现在已经定位了问题和迂回的解决办法。
问题定位
有一台ESXi服务器里的FreeBSD系统使用Bhyve虚拟Ubuntu子系统以太网走Bridge桥的时候网络不通也就是除了能跟宿主通信跟局域网的其它pc不通大家都是192.168.1.0/24网段的。
同样的系统下如果虚拟子系统走VALE和vether虚拟子接口使用10.0.0.0/8网段NAT出去那么网络就是通的。
也就是bridge不通NAT通。
但是几乎同样的配置另一台FreeBSD物理主机就没有这样的问题Bridge也是通的。不知道是不是ESXi和物理机不同导致的。但是那台物理机的问题也很大它的TrinityCore服务lag延时很大而且时不时会卡一下不知道是不是硬件有问题。
问题解决
ESXi服务器里的FreeBSD系统那个暂时先用走VALE和vether虚拟子接口NAT的方式网络就联通了。TrinityCore服务也相当好没有lag和卡顿。
FreeBSD物理机那个还没定位到问题感觉无从下手。
