cooldaddy

搞定了。

学习了 linux tc 来做限速，本来受限于开了 flow offloading 发现 iptables 条目失去作用无法限速（又不愿关闭 flow offloading 降低性能实现限速）
后来想到，既然路由是虚拟化，在物理机层面没有 flow offloading 没问题吧
但物理机和虚拟机完全是桥接，二层通信，iptables 又无法标记流量了

结果早上爬起来学习了一下 ebtables ，就从二层标记流量
终于成功用 tc 限速了，qdisc 开在物理机进 owrt 虚拟机的 vnet0 上，nice ！

回头找时间写篇东西记录一下

我试了一下，无论使用 iptables 按 pkts 限速，或者复杂一点用 tc 做流量整形，都可以把上传速度降下来
但相应的，换台的等待时间也变长了，如果上传限的太狠，就直接卡顿了
不限就没任何问题，换台也秒换

@dann73580 谢谢解答。我也觉得，给对等就可以了。

@weid HA （ Home Assistant ）会自动发现 owrt 路由器并且帮你监控这些数据，至于 cpu 温度，没找到合适的 restful 服务，所以自己快速写了一个简单的 http://fisherworks.cn/?p=3832

@swxk521 明白，看来应该加个限速，只要上下基本对等，或者上传稍高 50%~100%是可以接受的。毕竟既然受惠同时也应该付出，别过分就好。

@mengdodo 我说我万年没人看的 blog 咋跑来流量了……

512M 即使不带 swap 都能跑容器吧
只是容器内服务别太吃内存就好

为免不知我在说啥，贴个链接 http://fisherworks.cn/?p=3726

Debian 维护周期不大满意，否则几乎是最佳选择
所以现在 Rocky8 和 Ubuntu20.04 （干掉 snap ）都在用，反正不装桌面不会把 snap 带回来
目前对这俩都没啥意见

一些非关键的老服务在搞 Ubuntu 22.04 下的 lxd ，然后依据服务对老库的依赖程度用 lxd 跑 centos7 、Ubuntu18 、Ubuntu20 等

之所以用 lxd ，主要不像 docker 外挂存储，这玩意跟虚拟机更像，更笨更手动

而为了避免 lxd 引入 snap ，我是参照 lxd 官网文档自行编译的 lxd ，可以跑在 Ubuntu22.04 ，也可以跑在 64 位 RasPi-OS 。最可笑的是在 arm PiOS 上装了自编译 lxd 后，又装了 Debian 11 lxc+xfce 做了一套不影响 host OS 的 ESP32 开发环境。
等于是在树莓派里的 lxc 跑 deb buster 带桌面来开发 ESP32 ，毕竟谁也不愿一台笔记本一直 RS232 连着单片机，开个会出个门要拔回来还要插
小小的两台连在一起就很有爱… 好像偏题了。

总之不管啥 host OS ，lxd 是个不起眼的冷门好东西。我不光本地环境搞了 lxd ，ecs 上也用它。