V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  kyonn  ›  全部回复第 6 页 / 共 18 页
回复总数  360
1 ... 2  3  4  5  6  7  8  9  10  11 ... 18  
2025 年 3 月 16 日
回复了 kyonn 创建的主题 程序员 关于 remoteapp 的问题
@coldle 我用户的 windows server 应该是 win10 版本的内核。那有空我装个 11 的试试。
2025 年 3 月 16 日
回复了 kyonn 创建的主题 程序员 关于 remoteapp 的问题
@coldle 感谢。问题 1 其实还能忍受,大不了单独开个 windows 桌面放微信。问题 2 确实很难受,没有规避方案。
2025 年 3 月 16 日
回复了 kyonn 创建的主题 程序员 咨询下消息推送框架的问题
@janus77 那有靠谱的办法判断一个 app 集成了哪些推送吗
2025 年 3 月 16 日
回复了 yihy8023 创建的主题 NAS PCIE 拆分后的 SR-IOV 问题
这是之前搞 I350 SRIOV 时的记录, 供你参考. 我的建议是没啥特殊需求, 老老实实用网桥转发就行了, SRIOV 依赖特殊网卡和宿主机的 PCIE 桥, 维护起来太麻烦(尤其是迁移机器时, 还要挑平台), 而且还有跟宿主机网桥之间的互通问题, 那么些效率提升不值当, 除非是专门的虚拟机集群.



### sr-iov 理论基础

- [SR-IOV——在私有云环境中的应用与实践_weixin_30265103 的博客-CSDN 博客]( https://blog.csdn.net/weixin_30265103/article/details/99916338)
- [Why using Single Root I/O Virtualization (SR-IOV) can help improve I/O performance and Reduce Costs]( https://www.design-reuse.com/articles/32998/single-root-i-o-virtualization.html)

### iommu group 分组查看

```BASH
#!/bin/bash
for d in $(find /sys/kernel/iommu_groups/ -type l | sort -n -k5 -t/); do
n=${d#*/iommu_groups/*}; n=${n%%/*}
printf 'IOMMU Group %s ' "$n"
lspci -nns "${d##*/}"
done;
```



### PCI 设备直通

1. BIOS 开启 vt-d.

2. linux 内核开启 iommu 和 passthrough.

```BASH
# 编辑 grub 文件, 添加内核启动参数.
# bios 没有 sr-iov 功能时必须添加 pci=assign-busses pci=realloc, 强制要求内核重新分配 PCI 空间
# 否则在启用 VF 时会出现 write error: Cannot allocate memory 报错
sudo vi /etc/default/grub
GRUB_CMDLINE_LINUX="intel_iommu=on iommu=pt pci=assign-busses pci=realloc"

# 根据新 grub 文件重新生成 initrd.img
sudo update-grub

sudo reboot
```

3. 检查 iommu 分组, 确保 i350 4 个网卡处于不同分组.

```BASH
#!/bin/bash
# 查看 iommu 分组

for d in $(find /sys/kernel/iommu_groups/ -type l | sort -n -k5 -t/); do
n=${d#*/iommu_groups/*}; n=${n%%/*}
printf 'IOMMU Group %s ' "$n"
lspci -nns "${d##*/}"
done;
```

4. 如果 4 个网卡处于同一分组, 查看网卡 upstream 的 PCIE 桥的能力, 它可能没有 acs 能力.

```BASH
# 假如 01:00.0 是其中一个 i350 网卡, 查看其 PCIE 能力, 会打印 Capabilities: [1d0 v1] Access Control Services
sudo lspci -vvv -s 01:00.0 | grep "Access Control"

# 假如 00:01.0 是 i350 upstream 的 PCIE 桥, 查看其 PCIE 能力, 不会打印任何内容
# 因为大部分 intel PCIE bridge 不支持 ACS, 这时候需要打 ACS override patch
# ACS 补丁没有进入 linux 内核 upstream, 原因参考
# [LKML: Alex Williamson: Re: [PATCH] pci: Enable overrides for missing ACS capabilities]
# ( https://lkml.org/lkml/2013/6/18/738)
sudo lspci -vvv -s 00:01.0 | grep "Access Control"
```

5. 打 ACS 补丁需要修改 grub 和 kernel.

- 标准内核不支持 ACS 补丁, 需要自己重新编译内核并安装. Debian OS 参考 `debian/内核编译.md` .
- 部分非标准 Linux 发行版可能已经打上 ACS 补丁, 比如 Proxmox, OMV.
- 内核代码支持 ACS 功能后增加 grub pcie_acs_override 参数, 参考下面.

```BASH
# 继续修改 grub, 增加 pcie_acs_override 参数
# pcie_acs_override 参数有几种写法:
# 写法 1: pcie_acs_override=id:[vendor/device IDs]
# 写法 2: pcie_acs_override=downstream,multifunction
# 第 2 种写法会强行将所有 downstream 和 mutilfunction PCIE 分组, 建议使用第 1 种写法只对目标 PCIE 设备分组
# 下面的命令中增加了 pcie_acs_override=id:8086:1901 参数, 8086:1901 是 i350 upstream 的 PCIE bridge 的 id
sudo vi /etc/default/grub
GRUB_CMDLINE_LINUX="intel_iommu=on iommu=pt pci=assign-busses pci=realloc pcie_acs_override=id:8086:1901"

# 根据新 grub 文件重新生成 initrd.img
sudo update-grub

# 重启
sudo reboot
```

6. 验证 i350 VF 功能是否可用, **建议用第一种方法**.

- 第一种方法: 针对 4 个 i350 网卡单独设置 VF 数量.

```bash
# 查看一个网卡最多支持的 VF 数量
cat /sys/class/net/enp1s0f0/device/sriov_totalvfs

# enp1s0f0 是要设置的 i350 网卡设备名, 重启丢失. 其他 3 个 i350 网卡设置方法相同
echo 7 > /sys/class/net/enp1s0f0/device/sriov_numvfs

# 下面两个命令应该能看到新增加的 VF 网卡
# 因为此时还未屏蔽 VF 网卡驱动 igbvf, ip a 命令能直接看到加载驱动后的 VF 网卡
# 如果后续屏蔽了主机的 igbvf 驱动, 则只有 ip l 命令能看到没加载驱动的 VF 网卡信息
ip a
ip l
```

- 第二种方法: 支持直接设置 igb 驱动加载参数, 让 4 个 i350 网卡全部启用 N 个 VFs.

```BASH
# 如果不知道 i350 驱动名字, 可以通过下面命令查看
ethtool -i enp1s0f0 | grep ^driver

# 设置 igb 驱动启用加载参数, 需要重新生成 initrd, 重启永久生效
echo "options igb max_vfs=7" >>/etc/modprobe.d/igb.conf
sudo depmod -ae
sudo update-initramfs -u
sudo reboot

# 卸载驱动重新加载, VF 个数设置为 7, 重启丢失
modprobe -r igb
modprobe igb max_vfs=7
```

7. 为了让单独针对 i350 4 个网卡的 VF 设置永久生效, 又有两种办法.

- 第一种办法: 使用 systemd service 开机自动调用 echo 命令.
创建 SR-IOV 配置脚本并**添加可执行权限**: `sudo vi /usr/local/bin/cfg_sriov.sh`.

```BASH
#!/bin/bash

echo 1 > /sys/class/net/enp1s0f0/device/sriov_numvfs
echo 1 > /sys/class/net/enp1s0f1/device/sriov_numvfs
echo 4 > /sys/class/net/enp1s0f2/device/sriov_numvfs
echo 7 > /sys/class/net/enp1s0f3/device/sriov_numvfs

echo "config igb vf function ok ..."
```

将配置脚本加入 systemd 启动: `sudo systemctl edit --force --full sriov` .

```BASH
[Unit]
Description=config VF for sr-iov
After=networking.service NetworkManager.service
Before=libvirtd.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/cfg_sriov.sh

[Install]
WantedBy=multi-user.target
```

启动服务.

```BASH
sudo chmod +x /usr/local/bin/cfg_sriov.sh
sudo systemctl daemon-reload
sudo systemctl enable sriov
sudo systemctl start sriov
ip l
```

- 第二种办法: 使用 udev 规则. **注意!!!! 暂时还未成功, 下面的规则针对所有 igb 驱动网卡, 没有指定某个网口.**

为每个 i350 网卡增加 udev 规则: `sudo vim /etc/udev/rules.d/70-sriov-net.rules` .

```BASH
ACTION=="add", SUBSYSTEM=="net", ENV{ID_NET_DRIVER}=="igb", ATTR{device/sriov_numvfs}="7"
```

设置 udev 规则立即生效.

```BASH
# 可能需要插拔网线, 实在不行就重启设备
sudo udevadm control --reload-rules && sudo udevadm trigger
```

8. 通过前面的步骤 VF 网卡设备已生成. 在分配 VF 给 VM 使用前还需要屏蔽宿主机的 VF 网卡驱动, 否则 VF 设备会被宿主机占用.

```BASH
# 新增驱动加载文件 sriov-blacklist.conf, 屏蔽 VF 网卡驱动 igbvf
# 可以发现 VF 网卡驱动名字一般是开启 SR-IOV 功能之前的网卡驱动名加上"vf"
# 比如 x710 万兆网卡驱动名是 i40e, 对应 VF 网卡驱动名是 i40evf
sudo vi /lib/modprobe.d/sriov-blacklist.conf
blacklist igbvf

sudo reboot

# 重启后 ip a 命令已不再能看到 VF 网卡, 因为驱动没有加载
# ip l 命令还能看到每个 PF 下有若干 VF 设备, mac 地址可能都是 FF 或 0
ip a
ip l
```

9.
2025 年 3 月 16 日
回复了 kyonn 创建的主题 程序员 有没有开源靠谱的青龙平替选择?
@512357301 这个是自动化平台吧,还有 nodered ,感觉不是专门用来做定时任务的,生态方面也以生产力和智能家居为主。
2025 年 3 月 16 日
回复了 kyonn 创建的主题 程序员 有没有开源靠谱的青龙平替选择?
@ztmzzz https://v2ex.com/t/1019544
而且 github issue 里出现过有人提出资源消耗异常,作者直接关闭 issue 的情况。
2025 年 3 月 15 日
回复了 kyonn 创建的主题 程序员 求助个透明网关问题
@yinmin 我把之前在主机上添加的路由规则删了, 去主路由上加了你说的规则, 不起作用, 还是不通.
2025 年 3 月 15 日
回复了 kyonn 创建的主题 程序员 求助个透明网关问题
@yinmin 不太行, 主路由上之前已经有了条 mangle rule, 把目标是 7.0.0.0/8 的路由标记, 转发给一个新的路由表处理. 这个路由表再转发给 透明网关.
2025 年 3 月 15 日
回复了 kyonn 创建的主题 程序员 有没有开源靠谱的青龙平替选择?
@psllll 有点原始. 关键是没啥生态, 不好维护.
2025 年 3 月 12 日
回复了 kyonn 创建的主题 程序员 有没有便利的认证和解锁集成方案(windows hello)?
@w568w 这个是把支持 PAM 的应用接入谷歌两步验证把, 虽然做了集中, 但是每次还是要输密码把, ldap 也是类似道理. 有办法让鉴权这个事本身透过 指纹或摄像头 自动完成吗?

记得微软的验证可以自动发送个 请求 到个人账户的 2FA APP 上, 指纹批准就算通过了, 想找的是类似这样的方案, 能把所有设备都接入这种.
2025 年 3 月 9 日
回复了 kyonn 创建的主题 程序员 求助个透明网关问题
@yinmin 好的, 多谢.
2025 年 3 月 9 日
回复了 kyonn 创建的主题 程序员 求助个透明网关问题
@yinmin 有些难以取舍. 还有别的方法吗?

方法一多加了一层 NAT, 性能倒是其次, 关键是 透明网关 上的统计信息无法再看到实际的源 ip 了.
方案二每台机器都要配置, 最早还开了 dchp option121 直接下发 7.0.0.0/8 的静态路由给所有客户端, 后来发现米家的中枢网关会被这条下发的静态路由规则搞死, 上不了网, 因此就把 option 121 关掉了.
2025 年 3 月 9 日
回复了 kyonn 创建的主题 程序员 求助个透明网关问题
宿主机上还有其他虚拟机, 这些虚拟机的容器内 到 7.0.0.11 是可达的, 抓包发现路径也跟前面的一样, 响应报文不会经过路由器网关. 也就是说, 报文的去程和回程也是不同的, 但是可达.
2025 年 3 月 9 日
回复了 kyonn 创建的主题 程序员 求助个透明网关问题
宿主机直接加一条静态路由 : route add -net 7.0.0.0 netmask 255.0.0.0 gw 192.168.10.5 可以解决问题.

想知道比较正确的做法应该是怎样的?
2025 年 3 月 9 日
回复了 kyonn 创建的主题 程序员 求助个透明网关问题
问题原因应该是 透明网关发现 icmp 的源 ip 是宿主机 bridge0 网卡, 所以目的 mac 就直接用 bridge0 网卡的, 而不是回复给路由器网关.
2025 年 3 月 7 日
回复了 kyonn 创建的主题 宽带症候群 求推荐个简单可靠的透明网关部署方案.
最终还是写 iptables 规则了事
2025 年 3 月 6 日
回复了 kyonn 创建的主题 宽带症候群 求推荐个简单可靠的透明网关部署方案.
@badgv 要这么说也很有道理... 之前之所以不考虑直接在宿主机上配 iptables 主要是考虑到 宿主机上起了 docker, 本身 iptables 规则已经被搞得乱七八糟了, 再手动加规则, 感觉不好维护, 也不知道会不会被 docker 的操作自动清除规则, 或者规则冲突之类的.
2025 年 3 月 6 日
回复了 kyonn 创建的主题 宽带症候群 求推荐个简单可靠的透明网关部署方案.
@badgv 怎么说?
2025 年 3 月 6 日
回复了 kyonn 创建的主题 宽带症候群 求推荐个简单可靠的透明网关部署方案.
感觉需要的是一个更简单的三层交换机功能的容器.
2025 年 3 月 6 日
回复了 kyonn 创建的主题 宽带症候群 求推荐个简单可靠的透明网关部署方案.
@badgv 感觉用 openwrt 好像还是复杂, 做不到开箱即用, 容器启动后还要登录网页或 ssh 配置转发规则?
1 ... 2  3  4  5  6  7  8  9  10  11 ... 18  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   4030 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 30ms · UTC 09:43 · PVG 17:43 · LAX 01:43 · JFK 04:43
♥ Do have faith in what you're doing.