本帖最后由 r-MT 于 2021-7-11 15:57 编辑
由于个人原因不在折腾qnap了，补丁已经取消分享了，大家还在不停的刷楼，真不好意思了。还是谈谈我当时的思路和方法，让有能力的人继续接上
一。几个关键文件
/share/CACHEDEV1_DATA/.qpkg/QKVM/qvsd.sh 启动脚本
/share/CACHEDEV1_DATA/.qpkg/QKVM/ qnap的虚拟机安装目录，启动后生成/QVS/软连接目录
/share/CACHEDEV1_DATA/.qpkg/.QKVM/db/qvs.db 虚拟机数据库
/share/CACHEDEV1_DATA/.qpkg/.QKVM/conf/qvs.conf 启动配置文件
/share/CACHEDEV1_DATA/.qpkg/QKVM/usr/etc/libvirt/qemu/*********.xml 虚拟机xml配置文件
vms/models/pci.pyc 该文件里面对pci设备是否可以直通 做了限制
qvs/qvs/define/nas_model.pyc 该文件允许相应机型以及pcie slot插槽是否可以直通
qvs/controllers/constants.pyc 该文件对sata设备做了定义判定0x0106设备为sata，后面就要走蓝光光驱直通流程
qvs/vms/limits.pyc 虚拟机的一些限制文件 比如可以直通的gpu设备限定为2个 sata设备限定几个 自己按需修改，非必要
/usr/share/misc/pci.ids
/lib64/udev/hwdb.d/20-pci-vendor-model.hwdb
这2个文件 不在pci.ids数据库设备 名称能准确的在虚拟机直通界面 显示 非必要
二。2种思路和方法。
2.1
通过/share/CACHEDEV1_DATA/.qpkg/QKVM/qvsd.sh这个启动脚本，
发现里面有熟悉的PYTHON=$QPKG_ROOT/usr/bin/python libvirtd等等
然后在/QVS/usr/bin/可以找到比如pythony和vrish等等命令
那么不出意外猜想 qnap的虚拟机应该就是qemu kvm
简单加载一下环境变量 用virsh+xml启动一下 已经生成的虚拟机A，成功。
通过/sbin/lspci获得需要直通pcie设备的信息
手动编辑一下该虚拟机A的xml文件 添加进去
再次用virsh+xml启动虚拟机A 已经可以在虚拟机A里面看到和使用该pcie设备了
然后通过qnap的虚拟机来启动 改虚拟机A，启动后发现 直通的设备不见了，猜想是qnap校验了不合规的配置
然后找到/share/CACHEDEV1_DATA/.qpkg/.QKVM/db/qvs.db 虚拟机数据库文件
下载个SQLite Expert Professional，然后对qvs.db修正，把刚才添加进xml文件的信息 手动添加进db数据库，
然后再用qnap的虚拟机来启动，成功
此方法的缺点很多 很多需要手动添加，同时不能以后qnap的虚拟机里面修改该虚拟机的任何配置 否则修改就会进行合规性检查。
但是这方法 可以进行比如/dev/sdb的这种直通，具体自己百度吧，我测试过 完全没有问题
2.2
既然qnap使用pythony写的，花了点时间简单学习了下python，同时理了下思路，应该是qnap的ui进行了限制
然后反编译一下 整个/QVS/qvs/目录，花点时间读一下代码，得到大概限制如下
qnap的虚拟机启动过程中本机机型进行判定主要通过nas_model.pyc，同时nas_model.pyc还有允许直通的pcie slot信息，会和/etc/model.conf其中的pcie slot配置进行匹配，然后通过pci.pyc这个文件来判断该设备类型是否允许直通。sata设备只允许直通qnap的蓝光光驱等等。
知道了qnap虚拟机大概流程，
修改文件1
/vms/models/pci.py找到类似这样
def _is_allowed_device_type(self):
if is_qts_gateway_model():
if any([
# self.is_storage_controller, #删除或者注释掉 磁盘控制器不允许直通
self.is_bridge_controller]):
return False
elif not self._in_register_sub_classes:
return False #修正为return True 不在注册类的不允许直通
return True
等等 每个版本也许不一样 位置也许不一样，限制的设备位置类型也许改了，原理是一样的 他不允许的 你让他允许 返回TRUE或者FALSE等等 自行修改吧
修改文件2
qvs/qvs/define/nas_model.py
比如TS-886修改成如下
'TS-886': {'pci_slots': [{'id': '0000:00:01.0', 'name': 'PCIe 1'},{'id': '0000:00:03.0', 'name': 'PCIe 2'}, {'id': '0000:00:03.1', 'name': 'PCIe 3'},{'id': '0000:00:03.2', 'name': 'PCIe 4'},{'id': '0000:00:03.3', 'name': 'PCIe 5'},{'id': '0000:00:02.2', 'name': 'PCIe 6'}]
这样就是允许设定6条pcie插槽直通 这里全是16进制 不需要转换 具体看我以前写的文档
默认这里的条数要小于等于/etc/model.conf里面的pcie插槽数 而且会进行匹配校验
修改文件3 qvs/controllers/constants.py CLASS_SATA_CONTROLLER = '0x0106'此行修正为 CLASS_SATA_CONTROLLER = '0x0107' 这样就能sata设备的直通了
原理，qnap的虚拟机系统把sata设备只认可为蓝光设备，并允许其直通，所以一旦检测为sata设备 直接走蓝光直通流程。中间有很多很多的校验，如果在qnap虚拟机里面设定0107也就是软盘的代码设定为sata，那么虚拟机就会把0106的stat设备还是认为是0x01磁盘设备CLASS_MASS_STORAGE_CONTROLLER大类进行直通，并不影响其性能
其实正常应该去跟踪对sata判定后的走蓝光光驱直通的流程，我发现后面有很多判定，偷点懒，直接改了类型.
修改文件4 pci.ids 20-pci-vendor-model.hwdb自行修改美化一下 直通设备名称，非必要 limits.py文件按需自行修正
最后的一些注意要点 直通sata设备，/etc/model.conf必须写上对应的pcie solt，，qnap的磁盘管理UI就会接管，虚拟机直通sata的时候就会对该pcie设备进行unbind，造成qnap的磁盘管理报警，警告磁盘丢失，如果不写上对应的pcie slot，qnap的虚拟机软件直通sata(很多地方要去读取model.conf的solt)校验失败 以前通过启动脚本 在启动过程直接unbind sata，其实可以在启动的时候 model不写上sata的pcie slot，启动完成后 在启动qvs虚拟机的时候 通过脚本 对model.conf和model.ini文件进行对比，自动补上对应的solt。
威联通Virtualization Station虚拟机工作站补丁，
解锁了带pcie插槽X53B X53D相关机型的 pcie设备直通
解锁了网卡 sata转接卡等pcie设备直通
安装Virtualization Station,关闭Virtualization Station
上传补丁包到qnap，解压
找到对应的pcie插槽，修改补丁包中的modle.ini文件，运行./patchkvm -hq
再打开Virtualization Station软件，虚拟机列表 右下角 PCie
具体看补丁包中的说明新版补丁去除了版本限制，以及部分机型限制
PS：qnap的内核支持iommu的分组了X53B X53D机型需要在grub加上pcie_acs_override=downstream如下
linux /boot/bzImage root=/dev/ram0 rw pcie_acs_override=downstream
X72 X82等无需添加了
|
淘帖
云币50
贡献47
活跃2494
精华
