How I Moved My Synology DS920+ VM to an External SSD (And Survived to Tell the Tale)

A journey of SSH commands, coffee-fueled debugging, and one surprisingly cooperative USB drive

The Backstory: Why Bother?

Picture this: It’s 11 PM. I’m staring at my Synology DS920+, its four drive bays humming softly like a contented cat. But there’s a problem—my beloved Ubuntu VM is gasping for storage space, trapped on the NAS’s internal volume. I could shuffle drives, but that feels like performing open-heart surgery on my data hoard. Then I spot it: a lonely USB 3.0 port.

“What if…,” I mutter, eyeing a Samsung SSD 970 EVO Plus gathering dust on my desk.

Thus began my quest to liberate the VM onto external storage. Spoiler: It worked. But oh, the journey.

Act I: The Great vdisk Hunt

The “Where the Heck Is My VM?” Phase

Synology’s Virtual Machine Manager (VMM) hides VM files like a squirrel burying nuts. Initial attempts to locate the vdisk image via File Station failed spectacularly.

First Mistake: Assuming Synology plays nice with SSH newbies.
Second Mistake: Thinking @iSCSI and @ISCI were interchangeable (spoiler: they’re not).

After 47 cups of tea and a find / -name "vdisk*" command that felt like it scanned every atom in the universe, I struck gold:

1/volume1/@iSCSI/LUN/VDISK_BLUN/.../vdisk.img

Key Insight: Synology stores VM files in system directories invisible to mortals (and File Station). Root privileges or GTFO.

Act II: The Network Interface Tango

When Tap Dancing Meets TAP Interface

Moving the VM was only half the battle. My DS920+ has two NICs, and I wanted the VM wired directly to the second interface (ovs_eth1).

The Comedy of Errors:

1. Created a TAP interface (tap0)
2. Forgot to add it to the OVS bridge
3. Panicked when ping google.com returned “Network is unreachable”
4. Discovered ovs-vsctl is picky about bridge names

The “Aha!” Moment:

1ovs-vsctl add-port ovs_eth1 tap0  # "ovs_eth1" ≠ "eth1" ≠ "OVS_ETH1"

Act III: QEMU’s Revenge

File Descriptors, vhostfd, and Why Computers Hate Us

The original QEMU command looked like it was generated by a robot having a seizure:

1-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=31

What Broke:

• fd=30: A mystical file descriptor that vanished like my motivation at 2 AM
• vhost=on: The “go fast” button that only worked after sacrificing a USB cable to the IT gods

The Fix: Simplify, simplify, simplify:

1-netdev tap,id=hostnet0,ifname=tap0,vhost=on

The Final Script: A Symphony of SSH

After three sleepless nights and a brief existential crisis, here’s the startup script that made everything work:

 1#!/bin/sh
 2ip tuntap add tap0 mode tap
 3ip link set tap0 up
 4ovs-vsctl add-port ovs_eth1 tap0
 5#sleep 120
 6cd /volumeUSB1/usbshare/ds2
 7/usr/local/bin/qemu-system-x86_64 \
 8  -name guest=74f68c8a-bbd0-4356-ad2c-88599d708056,debug-threads=on \
 9  -vnc 127.0.0.1:0 \
10  -m 8496 \
11  -mem-prealloc \
12  -smp 4,sockets=1,dies=1,cores=4,threads=1 \
13  -machine pc-q35-6.0,accel=kvm,usb=off,dump-guest-core=off \
14  -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \
15  -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
16  -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
17  -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
18  -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
19  -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
20  -device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \
21  -device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 \
22  -device pcie-root-port,port=0x18,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x3 \
23  -device pcie-root-port,port=0x19,chassis=10,id=pci.10,bus=pcie.0,addr=0x3.0x1 \
24  -device pcie-root-port,port=0x1a,chassis=11,id=pci.11,bus=pcie.0,addr=0x3.0x2 \
25  -device pcie-root-port,port=0x1b,chassis=12,id=pci.12,bus=pcie.0,addr=0x3.0x3 \
26  -device pcie-root-port,port=0x1c,chassis=13,id=pci.13,bus=pcie.0,addr=0x3.0x4 \
27  -device pcie-root-port,port=0x1d,chassis=14,id=pci.14,bus=pcie.0,addr=0x3.0x5 \
28  -device pcie-root-port,port=0x1e,chassis=15,id=pci.15,bus=pcie.0,addr=0x3.0x6 \
29  -device pcie-root-port,port=0x1f,chassis=16,id=pci.16,bus=pcie.0,addr=0x3.0x7 \
30  -device pcie-root-port,port=0x20,chassis=17,id=pci.17,bus=pcie.0,multifunction=on,addr=0x4 \
31  -device pcie-root-port,port=0x21,chassis=18,id=pci.18,bus=pcie.0,addr=0x4.0x1 \
32  -device pcie-root-port,port=0x22,chassis=19,id=pci.19,bus=pcie.0,addr=0x4.0x2 \
33  -device pcie-root-port,port=0x23,chassis=20,id=pci.20,bus=pcie.0,addr=0x4.0x3 \
34  -device pcie-root-port,port=0x24,chassis=21,id=pci.21,bus=pcie.0,addr=0x4.0x4 \
35  -device pcie-root-port,port=0x25,chassis=22,id=pci.22,bus=pcie.0,addr=0x4.0x5 \
36  -device pcie-root-port,port=0x26,chassis=23,id=pci.23,bus=pcie.0,addr=0x4.0x6 \
37  -device pcie-root-port,port=0x27,chassis=24,id=pci.24,bus=pcie.0,addr=0x4.0x7 \
38  -device pcie-root-port,port=0x28,chassis=25,id=pci.25,bus=pcie.0,addr=0x5 \
39  -device pcie-pci-bridge,id=pci.26,bus=pci.1,addr=0x0 \
40  -device piix3-usb-uhci,id=usb,bus=pci.26,addr=0x1 \
41  -device nec-usb-xhci,id=usb1,bus=pci.3,addr=0x0 \
42  -device virtio-serial-pci,id=virtio-serial0,bus=pci.4,addr=0x0 \
43  -drive file=vdisk.img,format=raw \
44  -device virtio-net-pci,host_mtu=1500,netdev=hostnet0,id=net0,mac=02:11:32:2d:fd:33,bus=pci.2,addr=0x0 \
45  -netdev tap,id=hostnet0,ifname=tap0,vhost=on,script=no,downscript=no \

Lessons Learned (So You Don’t Have To)

1. SSD Formatting Matters: EXT4 > BTRFS for external VM storage
2. OVS Bridges Are Fussy: ovs_eth1 ≠ eth1—case sensitivity kills
3. QEMU Hates Typos: driver=file vs driver:file is the difference between victory and despair
4. VNC Passwords Are Optional (But Regret Isn’t)

Epilogue: Why This Works

By moving the VM to an external SSD:

• ✅ Freed up 60GB on my primary volume
• ✅ Reduced RAID array wear
• ✅ Gained bragging rights at nerdy dinner parties

The script leverages Synology’s hidden KVM powers while bypassing VMM’s limitations. The TAP/OVS combo ensures the VM taps directly into the second NIC, avoiding internal network congestion.

Final Thought: This project felt like teaching a NAS to swallow a USB drive and cough up a VM. But hey—it works! Now if you’ll excuse me, I have a date with a backup script and a very large coffee. ☕

— Written at 3 AM, fueled by questionable life choices and a Synology’s gentle hum.