virtual-dsm 评测：把 Synology DSM 装进 Docker，但 KVM 是硬门槛

它解决什么问题，给谁用

virtual-dsm 把 Synology 的 Virtual DSM 封装进 Docker 容器，让你在一台普通的 Linux 服务器上跑出一个完整的 DSM 桌面。Synology DSM 本身是闭源系统，通常只随实体 NAS 发售，但 Synology 官方提供了 Virtual DSM 镜像，供虚拟化平台使用。这个项目做的就是把这个镜像拉下来，用 QEMU 在容器里模拟硬件，然后通过 Web 浏览器访问 DSM 界面。它适合两类人：一是家里已经有一台高性能服务器、不想再花几千块买 NAS 的用户，二是开发或测试人员，需要快速起一个 DSM 实例来验证套件兼容性、写脚本或者做演示。它不解决存储硬件问题，你仍然需要自己准备磁盘空间和备份策略。

工作机制：容器里的 QEMU 虚拟机

从仓库的布局和 README 看，virtual-dsm 的核心思路是在容器内运行 QEMU，把 DSM 作为客户机系统。容器本身只是载体，真正干活的是 KVM 加速的 QEMU 进程。默认配置给虚拟机 2 个 CPU 核心和 2 GB 内存，这些可以通过环境变量调整。磁盘方面，项目会在 `/storage` 目录下创建镜像文件，默认大小 256 GB，支持通过 `DISK_SIZE` 扩容，甚至可以无损扩容已有磁盘。网络支持多种模式：默认是 bridge 模式，容器和宿主机共享 IP，通过端口映射访问；也可以切换到 macvlan 或 macvtap，让 DSM 获得独立 IP，甚至开启 DHCP 模式让 DSM 直接向路由器要地址。这种设计的好处是 DSM 对底层硬件无感，坏处是性能完全取决于 KVM 是否可用，如果宿主机没有 `/dev/kvm`，整个容器就退化成纯软件模拟，速度会慢到没法用。

部署：三条命令起步，但 KVM 是前提

部署方式很直接。用 Docker Compose 的话，创建一个 `docker-compose.yml`，写入 `image: vdsm/virtual-dsm`，设置 `DISK_SIZE: "256G"`，把 `/dev/kvm` 和 `/dev/net/tun` 挂进容器，加上 `NET_ADMIN` 权限，映射 5000 端口，然后 `docker compose up -d`。用 Docker CLI 也差不多，一条 `docker run` 命令就能跑起来。Kubernetes 用户可以直接 `kubectl apply -f https://raw.githubusercontent.com/vdsm/virtual-dsm/refs/heads/master/kubernetes.yml`。但 README 里明确写了一个硬性要求：宿主机必须支持 KVM，而且 Docker Desktop 在 Linux、macOS 和 Windows 10 上都不提供 KVM 访问，所以这些环境直接不支持。Windows 11 用户需要开启嵌套虚拟化，用 Docker Desktop 或 Podman Desktop 才行。这意味着，如果你的服务器是云上的轻量虚拟机，没有嵌套虚拟化，这条路就走不通。

配置灵活性：磁盘、网络、GPU 都能调

这个项目的可调项比一般 Docker 镜像多。磁盘方面，除了 `DISK_SIZE`，还可以加 `DISK2_SIZE` 和 `DISK3_SIZE` 来创建多个附加磁盘，每个磁盘对应一个独立的存储卷。物理磁盘直通也支持，把 `/dev/sdb` 映射到 `/disk1` 即可，但 README 特别提醒，直通的磁盘必须是完全空的，否则 DSM 可能无法格式化成卷。网络方面，macvlan 模式需要手动创建 Docker 网络，指定子网和 IP 范围，然后在 compose 里引用。这里有个坑：macvlan 模式下，宿主机无法直接访问容器 IP，因为 macvlan 设计上不允许宿主机和容器通信，README 建议用第二个 macvlan 做变通。GPU 加速支持 Intel、AMD 和 NVIDIA，通过 `GPU: "Y"` 开启，但 README 明确说目前只支持 Synology Photos 的人脸识别，不支持视频硬件转码。如果你指望用它来跑 Plex 硬解，那会失望。

安装与版本控制：自动下载 .pat 文件

首次启动时，容器会自动下载 DSM 的安装文件，默认安装 7.2 版本。如果你想装旧版，可以通过 `URL` 环境变量指定一个 `.pat` 文件的下载地址。这个机制意味着你需要能访问 Synology 的下载服务器，如果网络受限，安装可能卡住。另外，DSM 安装完成后，首次通过浏览器访问 5000 端口，需要手动设置用户名和密码。整个过程 README 描述得很简单，但实际耗时取决于网络速度和磁盘性能，不是秒开。版本管理方面，项目本身有频繁的 release，比如 v7.65、v7.64、v7.63，间隔大约一周，说明维护活跃。但 DSM 镜像版本和项目版本是两回事，项目版本更新不代表 DSM 版本会跟着升级，你需要自己关注 Synology 的发布。

限制与失败模式：不止是 KVM

最明显的限制是 KVM 依赖，这已经说了。但还有其他几个坑。第一，内存分配默认是静态的，`RAM_SIZE` 设置多少就占多少，虽然支持内存 ballooning 来动态回收，但需要额外开启。第二，磁盘直通要求磁盘为空，这意味着你不能把已有数据的硬盘直接挂上去当存储，必须先备份数据。第三，macvlan 网络的宿主机通信问题，如果你需要从宿主机直接访问 DSM 的文件共享，默认的 bridge 模式反而更合适，但那就没有独立 IP。第四，GPU 加速功能不完整，人脸识别可以，视频转码不行，这限制了它在多媒体场景的实用性。第五，整个项目依赖 QEMU 和 KVM 的稳定性，如果宿主机内核升级导致 KVM 模块变化，容器可能起不来。这些限制意味着 virtual-dsm 适合实验和家庭使用，但作为生产级存储方案，你需要额外做很多验证。

替代方案：Proxmox VE 与原生 DSM

如果你需要跑 Virtual DSM，最直接的替代方案是 Proxmox VE。Proxmox 是一个基于 KVM 的虚拟化平台，可以直接导入 Synology 的 Virtual DSM 镜像，不需要 Docker 这一层。区别在于，virtual-dsm 把 QEMU 封装进容器，让部署和迁移更轻量，适合单机场景；而 Proxmox 是完整的虚拟机管理平台，支持快照、备份、集群，适合多虚拟机管理。另一个替代方案是直接买一台实体 Synology NAS，或者用 DSM 的官方虚拟机镜像在 VMware 或 VirtualBox 里跑，但那需要你手动配置虚拟机硬件，没有这个项目这么自动化。如果你只是想要一个 NAS 系统，不在乎是不是 DSM，那么 OpenMediaVault 或 TrueNAS 的 Docker 镜像更轻量，没有 KVM 依赖，但它们的界面和套件生态和 DSM 完全不同。选择哪个，取决于你是要 DSM 的特定功能（比如 Synology Photos 的人脸识别），还是只要一个能用的 NAS。

维护与许可证：MIT 带来的自由度

项目使用 MIT 许可证，这意味着你可以自由使用、修改甚至商用，只需要保留版权声明。没有 copyleft 约束，如果你想基于它做二次开发，比如定制安装流程或集成到自己的管理平台，法律上没有障碍。维护方面，从最近的 release 频率看，项目更新很勤，v7.65 到 v7.63 间隔不到十天，说明作者在持续跟进 QEMU 和 DSM 的变化。但要注意，DSM 本身是 Synology 的闭源软件，许可证限制依然存在，你不能把 DSM 镜像重新分发。升级路径上，容器镜像更新后，你需要重新拉取镜像并重建容器，但已有的存储数据在 `/storage` 卷里，不会丢失。磁盘扩容通过 `DISK_SIZE` 实现，README 说可以无损扩容，但建议先备份。整体来说，维护成本不高，但你需要自己跟踪 DSM 的安全更新，因为容器不会自动升级 DSM 系统。

编辑结论

virtual-dsm 适合两类人：一是想在现有 Linux 服务器上获得完整 DSM 体验、又不想买实体 NAS 的家庭用户，二是需要快速搭建 DSM 测试环境、用于验证套件兼容性或开发脚本的工程师。不适合的人包括：宿主机没有 KVM 或无法开启嵌套虚拟化的用户，因为 Docker Desktop 在 Linux、macOS 和 Windows 10 上都不提供 KVM 访问，装了也跑不起来；还有对数据安全要求极高的生产环境用户，因为 DSM 本身不是为容器化设计的，磁盘直通和备份策略都需要额外验证。在采用之前，你应当先确认三件事：宿主机 CPU 是否支持虚拟化并已启用 KVM 模块，`/dev/kvm` 是否存在且对容器可见；磁盘空间是否大于 16 GB，因为默认磁盘就是 256 GB；以及你选择的网络模式，如果要用 macvlan，要提前知道宿主机无法直接访问容器 IP 这个限制。最后，如果你只是想要一个网络附加存储，而不是非 DSM 不可，那么 OpenMediaVault 或 TrueNAS 的容器化版本可能更轻量，也少一层 KVM 依赖。

官方来源

1. Official README
2. Project repository
3. Release notes