ARM SBC 运行Win7 X64

2023-08-05 作者：

就现阶段而言，妥妥的行为艺术，猜测如果安装32bit版本会好些？

又翻出来一块压箱底的Rock Pi 4B+，4GB RAM，32GB eMMC。鉴于厂家给的Debian 10 buster跟之前那块Asus TinkerBoard 2S别无二致，基本处于不可用状态，于是这里又一次Armbian Bookworm搞起。

安装libvirt，分配2核（1.8GHz大核）及1GB内存，开始安装Win7 X86_64。

本想运行KVM驱动盘补全所有驱动，无奈随便打开个文件管理器or设备管理器都要以分钟计。花了多半个小时使用msi程序安装KVM驱动，半路报service无法启动（大概率是启动时间过长，被认为启动失败）只好cancel。

其实，除了处理器虚拟效率，还有板子裸奔无散热也是个次要问题。若带上主动散热，让核心不需要频繁降频的话，可用性小幅提升也未可知。

图一乐吧，起码“可能”就是一种良好开端。好像ARM核心的Macbook现在也能支持比较可用的32bit X86 win系统吧？

嗯……可以考虑有空时弄个ARM版Win10来做个虚拟化试试，感觉内存不大够玩的样子。

完整阅读本篇»

路由虚拟化，意义何在？

2023-06-04 作者：

见此题目，心急的路由玩家，可能等不及要说，我要all in one啊。

“主路由还要承担NAS、HA、运行docker，甚至一些通用win/linux虚拟机的脚本工作，我已经按大佬教程在ikuai/openwrt上搞了kvm，挺香，你不搞么？”

非也，我是反向操作，先虚拟化，再跑路由，理由也很简单 –

“首先，专业方案解决专业问题，所以尽管底层都是kvm，我不喜欢用一个路由系统做virtualization host，NAS系统也同理。其次，我要极致灵活性和对特殊需求的支持能力。”

对第二点，我举个简单的例子，我希望ikuai实现以下需求 –

  • 对硬件#1物理口做成单臂路由，vlan id 3为WAN去拨号，vlan id 12为LAN，且开DHCP。
  • 然后把#2物理口加入ikuai WAN2（第二条宽带，或者4G wwan转成有线接入做冗余连接备用）。
  • 再把#3物理口加入LAN，而#3物理口vlan id 22放给二级路由的LLAN。
  • 二级路由的WAN不走物理口，直接走host内部虚拟交换机接在ikuai LAN的下边。

如果路由裸装ikuai系统，我不知道是否方便实现，花点心思或许可以吧。但如果物理机是Proxmox VE，我实际遇到的使用场景应该比如上说的还复杂些，完全不是问题，ikuai完全不需要设置任何vlan，如上需求可以都在pve host的linux vlan和bridge的层面做好，进路由看到的完全是多块virtio独立网卡。

“那么今天你要讲，怎么在pve+ikuai上实现这个需求？这种需求一般人用不上，我为何要了解？”

非也，今天想讲下我在家中遇到一个更有意义的需求，给智能电视（尤其某些第三方APP）限速，且主要针对上传速度。

 

首先，为何要限速？观察下图，黑线两侧，是限速前后状态对比。

我们可以很明确的发现，限速前上传速度是4MBytes/s左右，可以说基本把家宽的上行带宽吃完了，此外我们的RK3399被迅速推高了15℃，温度达到70℃左右，别忘记现在还只是春末夏初。

完整阅读本篇»

M.2转接Intel i210千兆

2023-06-01 作者：

先说句题外话，个人不喜2.5G，一直觉得就是民用市场卷出来的临时产品。反正六类线跑电口万兆没问题，2.5G抑或10G都是贵，买个中间态产品？图便宜就留在千兆方案，不差钱直接万兆完事，2.5G这不上不下，就那么几个网卡方案不升级还断流，厂家重视与否么显而易见，对吧。

为什么要提2.5G，前两天说Tinker Board 2s带了一个key A+E的m.2，一旦做路由，这种wifi卡显见没啥用，可以考虑：

  • 另一块网卡，这样路由就不再单臂，更实至名归一些（板子还是天生12v供电，你不做路由谁做路由？）。
  • 扩SATA。也是好主意，但这板自带16GB emmc跑host和kvm足够，还空一个TF卡槽，需要的话插卡就很方便。再扩SATA就没啥必要了，并且SATA供电也得外接，板上并无接口，鸡肋了。
  • 其他PCIe设备，意思不大。

某宝上转了一圈，其实基于i225V B3（或者RTL 8125）的m.2接口2.5G网卡，居然比i210的千兆还便宜20块，赫然写着新版绝不断流……

犹豫再三我还是入了i210版本，综合考虑了自己对2.5G的不感冒，以及RK3399的转发能力，适合自己才是最好的嘛。即使接单块2.5G网卡，再做2.5G单臂路由的话，还需要2.5G vlan switch，没事咱就别给自己挖坑了。

卡么，看板子糙了点儿，但外观毕竟不能当饭吃。

 

完整阅读本篇»

为RK3399换金属壳降温

2023-06-01 作者：

这个没啥技术含量，就看愿不愿意为这么块小铁皮出90块。板子太冷门，周边没人做，所以商家估计本着开张吃半年的原则，这么个壳子收90，而且隔壁还有140的……我感觉140买x86的瘦客户端洋垃圾几乎能买整机了……

效果也比较明显，在室温影响差异不到1℃的前提下，同样被动散热能多拉下来6℃，只能说没有白花的钱，至于值不值就另说了。

完整阅读本篇»

基于CM4 Sensing双WAN冗余路由

2023-05-12 作者：

把手头能玩的板子全玩了一遍，完全停不下来。基于virt-manager和virsh cli的libvirt方案虽然没有PVE的纯web使用便利，但毕竟ARMv8有完全可用的libvirt支持已经很方便了，还要啥自行车哦。

既然Pi 4B据测已经能够很好的承担虚拟化路由职责，那么基于CM4并集成了4G LTE连接能力的CM4 Sensing就完全有能力实现双路外网的负载均衡+故障切换，对吧？

那即使技术实现上的选择已经很清晰，我们还是列一下目前已知的可能途径：

  • 基于一般Linux发行版使用iptables + connmark + policy-based routing直接手打路由。我曾用一台Debian 11 vm做过实验并且跑通了最基本的双wan负载均衡，想来感兴趣这种原始手工方式的玩家想必不是很多，所以也没有过多记录。且继续往下，在Linux上做这些策略的持久化、多ISP定时监控、故障切换，都有大量的脚本工作；而这方面已有大量成熟方案，我的目的仅仅是通过实验理解原理，目的达到，见好就收。感兴趣的可以通过关键词检索相应文章学习，另外B站的“金枪鱼之夜”的课堂录像（上下两集），可以帮你很好的由浅入深搞懂iptables。
  • 直接按Pi 4B编译/下载OpenWrt固件。如我们之前的mwan3负载均衡测试，功能实现上不应存在潜在问题，但这里显然要开始考虑4G/5G模块的驱动编译，wan口支持wwan的相应库的选择，最终编译结果固件的长期可靠性测试，硬件如果升级（比如4G模块，比如CM4载板）必然重新编译……一圈玩下来可以说是实现产品的精力了。
  • 第三个选择就要轻松的多。完全无需重新编译，把我们已经玩6的armvirt镜像直接扔Sensing里，给vm多加一个虚拟网卡eth2，打完收工。

没理解是吧，没关系，先把上一篇《基于Raspberry Pi 4B单臂路由》复习一下，接下来我们看图说话。

完整阅读本篇»

简单RestAPI获取硬件状态

2023-05-11 作者：

简单来说，我需要一个能从HA上直接浏览家里主路由的CPU温度的首屏，因为RK3399发热比较猛却只有被动散热。有人可能说，加个小风扇难度很大么？呃，具备Netgear R7000（博通方案）在夏天轻松面对75℃服役5年的经验，我觉得国货不妨一战。

所以这个小项目，其实提供了对运行在物理机上几乎任意Linux的cpu温度、磁盘余量、上电时间等参数的rest api获取。写的比较糙快猛，主要满足自己需求，所以莫要预期过高哈。

提供何种接口

随意运行一个http client，比如  curl http://[hostname]:9090/stats/[data_type]

data_type初期支持三种， du, temps, boot_time 分别代表磁盘用量，多个温度，和上电时间。然后就可以返回数据了。

完整阅读本篇»