The safest answer to this unanswered source thread is: do not make the existing OMV Btrfs mirror the first thing you experiment on. Keep OpenMediaVault online, install ZimaOS on the separate system you want to evaluate, connect the OMV shares as LAN Storage, and copy data in phases. That preserves the old NAS as both a working service and a rollback path while you test ZimaOS apps, shares and backups.
The CPU question is also easier when split by layer. VT-x is the key hardware-virtualization feature for ordinary x86 VMs. VT-d/IOMMU is mainly relevant when you want to pass physical PCIe devices directly into a guest. Docker apps do not require VT-d. A 2011-era i5-2310 can therefore still run containers and may run ordinary VMs, but passthrough and overall VM performance are separate limits.
Docker Apps Do Not Require VT-d
ZimaOS App Store applications run as Docker containers. They share the host kernel and do not need hardware device passthrough just to start.
The old i5 may be slow for heavier apps, but lack of VT-d does not mean “no apps.” RAM, storage speed and application CPU load matter more for normal containers.
VT-x Can Support Ordinary VMs
Current ZimaOS VM planning guidance separates basic KVM/QEMU virtualization from PCIe/GPU passthrough. Ordinary Linux/Windows guests need a working virtualization path and enough host CPU/RAM.
Use the current ZimaOS VM hardware guide.
VT-d Is Mainly a Passthrough Boundary
If a guest must directly control a PCIe GPU, HBA, NIC or similar device, IOMMU/VT-d becomes important. USB passthrough can also depend on how the host exposes USB controllers/devices and which ZVM interface is used.
Do not conflate “VM boots” with “every physical device can be assigned to the VM.”
Do Not Assume ZimaOS Will Adopt an Existing OMV Btrfs Mirror In-Place
The source user had a two-disk Btrfs mirror created and managed by OMV. Current ZimaOS storage documentation focuses on creating/managing ZimaOS storage spaces through its own Storage workflow. It does not provide a general promise that arbitrary pre-existing OMV Btrfs RAID layouts can be imported non-destructively.
If those 16 TB drives contain the only copy of important data, leave them under OMV until the data is independently backed up or copied.
The Current Official Migration Path Is Network Copy
Current IceWhale guidance for moving from another NAS is to keep the old NAS online, expose its shares, add it in ZimaOS Files as LAN Storage, then copy data to the new ZimaOS storage.
Use the current move-from-another-NAS strategy. The same SMB migration concept applies to OMV shares.
A Faster Ryzen ZimaOS Box Can Use OMV as Network Storage
The source alternative—run apps/VMs on the Ryzen 9 box while OMV continues serving the 16 TB disks—is a sensible low-risk transition. ZimaOS can mount network storage through Files, while the old NAS remains the storage authority.
The practical ceiling will be the 1GbE link on the OMV box: roughly gigabit-class network throughput, regardless of the Ryzen box's 2.5GbE NIC.
USB JBOD Is an Option, but It Changes the Failure Model
Current ZimaOS supports USB drives as standalone storage and in supported storage workflows. Moving the HDDs into a USB enclosure gives ZimaOS direct ownership, but the enclosure/USB bridge becomes part of the storage path.
For critical always-on RAID, evaluate SMART passthrough, stable device enumeration, power delivery, cooling and bridge behavior before moving production disks.
A Safer Migration Order
- back up the OMV data;
- install ZimaOS on separate hardware/storage;
- test apps and one representative VM;
- mount OMV as LAN Storage;
- copy a subset and verify permissions/checksums;
- build the final ZimaOS storage separately;
- copy the remaining data;
- keep OMV intact until restores and backups are verified.
OMV to ZimaOS FAQ
Does no VT-d mean no Docker apps?
No. Docker apps do not require VT-d.
Does no VT-d mean no ordinary VMs?
Not necessarily. VT-x can support ordinary hardware-accelerated VMs; VT-d is primarily an advanced device-passthrough requirement.
Should I let ZimaOS recreate the old OMV RAID before copying data?
Not if it contains the only copy. Keep the old NAS intact and migrate over the network first.
