How Cinder talks to Synology​

The driver works with two kinds of traffic, and it helps to keep them apart in your head:

cinder-volume ──── HTTPS :5001 ────▶ DSM WebAPI      (control: create / delete LUN + target)

compute node  ──── iSCSI  :3260 ───▶ DSM iSCSI target (data: the instance's disk I/O)

Every time you create a volume in OpenStack, cinder-volume logs in to the DSM WebAPI and creates an advanced file LUN plus an iSCSI target inside a DSM volume. When you attach it, the compute node logs in to that target directly, and the LUN shows up as a block device for the instance. Once a volume is attached, cinder-volume is no longer in the data path.

Example environment​

The lab runs as VMs on a single Proxmox host, which is why the numbers below are small. Replace the addressing with your own.

Nodes​

All subnets are /24. Every OpenStack node has five NICs: management, tunnel, storage 1, storage 2, and a fifth NIC for the external network. That fifth NIC has no IP, because Neutron takes it over and turns it into br-ex. The Synology VM has three NICs: management (admin and internet access), storage 1, and storage 2.

The VIP for the OpenStack APIs is 192.168.19.35, held by HAProxy and Keepalived on the controllers.

Networks​

The tunnel and storage networks are internal only, with no gateway.

Each node uses the same last octet on every subnet (for example .36 on controller-01), which makes it easy to tell which node an address belongs to. DSM has an address on both storage networks: 172.16.2.31 and 172.16.3.31.

Step 1: Prepare DSM​

Storage and network​

Everything in this section happens in the DSM web interface. The network comes first, so every service you enable afterwards can be bound to the right NIC.

1. Give DSM a static IP on each storage NIC. Open Control Panel → Network and set 172.16.2.31/24 and 172.16.3.31/24 on the two storage adapters. Leave the gateway empty on both, because these networks only carry storage traffic. Two separate subnets (instead of two addresses in one subnet) keep routing unambiguous and give you two independent iSCSI paths later.

   

2. Create a storage pool and a volume. In Storage Manager, create a pool and then a volume on top of it. Choose Btrfs, because thin-provisioned LUNs and snapshots generally need it. Write down the volume name (for example volume1). That exact name becomes synology_pool_name in the Cinder configuration.

   

3. Create a LUN (optional). In SAN Manager, create a LUN on the new volume. The Synology driver creates and deletes LUNs by itself, so Cinder does not need this step. A manual LUN is still handy to confirm the volume can host LUNs at all, and it is the starting point if you ever use the fallback of one big LUN with LVM on top.

   

4. Create an iSCSI target (optional). Create a target and map the LUN to it. Like the LUN, this is only for testing: you can log in to it with iscsiadm from a node to prove the data path works before Cinder is involved. Later, the targets that Cinder creates have names starting with Cinder-Target-.

   

5. Bind the iSCSI service to the storage NICs. In the iSCSI network binding settings, allow the service to listen on the two storage interfaces only. This makes both portals (172.16.2.31 and 172.16.3.31) visible to initiators, which multipath depends on, and keeps iSCSI off the management network.

   

6. Enable the NFS service. Block storage is not the only thing worth sharing. OpenStack's image service (Glance) stores images as plain files by default, so each controller only sees the images it received itself. An NFS share that every controller mounts fixes that. In Control Panel → File Services → NFS, enable the service and set the maximum protocol to NFSv4.1, which needs only port 2049.

   

7. Create a shared folder. In Control Panel → Shared Folder, create a folder named glance on the volume from step 2. Its path on DSM is /volume1/glance, and that is what the controllers will mount. The recycle bin and encryption can stay off for an image store.

   

8. Grant permissions. Give Read/Write on the shared folder to the accounts that will touch the files, in my case the guest and ops users. Then add an NFS permission rule for the storage subnet (172.16.2.0/24) with Read/Write. Set squash to No mapping, otherwise chown from the controllers is silently remapped and Glance can hit permission errors.

   

9. Bind NFS to the storage network. Restrict the NFS service to the storage interface, the same way as for iSCSI. NFS is then only reachable from the storage subnet, not from the management network, and the DSM firewall only needs to allow port 2049 from the controllers.

   

The service account​

The driver logs in non-interactively with a username and password, so the account it uses cannot have two-factor authentication. In my lab I did not create a dedicated Cinder user. I reused ops, the first account I created on DSM, because I already mapped its permissions for the shared folders and did not want to repeat that work for a second account.

1. Control Panel → User & Group: add ops to the administrators group. The driver needs admin rights to create LUNs and targets. Without this, volume creation fails.
2. Control Panel → Security → Account → Two-factor authentication: make sure enforcement does not cover ops. If enforcement is set to all users or to the administrators group, scope it to a specific group and keep ops out of it.
3. Use ops as synology_username in cinder-volume.conf.

Because of that, lock the account down at the network level. In Control Panel → Security → Firewall, allow:

• port 5001 only from the OpenStack nodes on Storage 1,
• port 3260 only from the OpenStack nodes on both storage subnets,
• and deny everything else.

Also use a long random password for ops, and keep cinder-volume.conf at chmod 600 and out of git.

Test from a controller​

Run these from the node that will host cinder-volume, because that is the exact path Cinder will use.

# iSCSI portals on both paths
nc -zv 172.16.2.31 3260
nc -zv 172.16.3.31 3260

# WebAPI login: the response must contain "success":true
read -rsp "DSM password: " P; echo
curl -sk https://172.16.2.31:5001/webapi/auth.cgi \
  --data-urlencode "api=SYNO.API.Auth" \
  --data-urlencode "version=6" \
  --data-urlencode "method=login" \
  --data-urlencode "account=ops" \
  --data-urlencode "passwd=$P" \
  --data-urlencode "format=sid"

If the login fails with a 403 or 404-style error, 2FA is probably still being enforced for that account.

Step 2: Prepare the OpenStack nodes​

Hostname mapping (deployer only)​

Kolla Ansible connects to the nodes by the names in the inventory, so the deployment host must be able to resolve them. Add the management IPs of all OpenStack nodes to /etc/hosts on the deployer:

sudo tee -a /etc/hosts <<'EOF'

# OpenStack VIP
192.168.19.35   openstack-vip kolla-vip

# OpenStack controllers
192.168.19.36   dev-openstack-controller-01 controller-01
192.168.19.37   dev-openstack-controller-02 controller-02
192.168.19.38   dev-openstack-controller-03 controller-03

# OpenStack computes
192.168.19.41   dev-openstack-compute-01 compute-01
192.168.19.42   dev-openstack-compute-02 compute-02
EOF

A few notes:

• The inventory always uses the full hostname (dev-openstack-controller-01). The short aliases (controller-01) are only for typing ssh by hand.
• Each node's own hostname must match the name in the inventory (hostnamectl on the node), because RabbitMQ and Galera use it.

Check that every name resolves and that you can reach each node over SSH:

for h in dev-openstack-controller-0{1,2,3} dev-openstack-compute-0{1,2}; do
  getent hosts $h || echo "$h: NOT RESOLVED"
done

for h in dev-openstack-controller-0{1,2,3} dev-openstack-compute-0{1,2}; do
  ssh -o BatchMode=yes -o ConnectTimeout=5 $h hostname || echo "$h: SSH FAILED"
done

Each node should print its own full hostname. If one prints SSH FAILED, fix the SSH key or user first, because Kolla Ansible needs passwordless SSH to every node.

Do this on the target nodes before kolla-ansible bootstrap-servers. The deployment host does not need any of it.

Time sync (all nodes)​

Galera, RabbitMQ, and Keystone tokens are sensitive to clock drift between nodes, so every node needs working time sync. I run chrony on the host and turn off Kolla's own chrony container so the two do not fight over NTP:

sudo apt install -y chrony
sudo systemctl enable --now chrony
sudo timedatectl set-timezone Asia/Jakarta
chronyc tracking

Disable the host multipathd and iscsid (all nodes)​

Kolla runs iscsid and multipathd as containers on compute nodes and on the cinder-volume node. If the host's own iscsid, open-iscsi, or multipathd are also running, they fight with the containers. Disable them on every node before the first deploy:

sudo systemctl disable --now multipathd.service multipathd.socket
sudo systemctl disable --now iscsid.service iscsid.socket open-iscsi.service

I disable them on all nodes, not just the ones that run the containers today, so that moving cinder-volume to another node later does not bring the conflict back.

Also make sure each node has an IP on both storage subnets, with no gateway.

Mount the Glance NFS share (controllers only)​

Do this only after the DSM side is ready (NFS service, glance shared folder, NFS permission for 172.16.2.0/24, and port 2049 open in the DSM firewall). Run it on all three controllers.

sudo apt install -y nfs-common
sudo mkdir -p /mnt/glance

Make the mount permanent in /etc/fstab:

172.16.2.31:/volume1/glance  /mnt/glance  nfs4  vers=4.1,_netdev,nofail,x-systemd.automount  0  0

sudo systemctl daemon-reload
sudo mount -a
sudo chmod 755 -R /mnt/glance/
df -h /mnt/glance

Test that the share is really shared: write from one controller and read from the others.

echo ok | sudo tee /mnt/glance/test.txt   # controller-01
cat /mnt/glance/test.txt                  # controller-02 and 03
sudo rm /mnt/glance/test.txt

Step 3: Deploy with Kolla Ansible​

Run everything in this step on the deployment host.

Install Kolla Ansible​

sudo apt update
sudo apt install -y git python3-dev libffi-dev gcc libssl-dev python3-venv

python3 -m venv openstack
source openstack/bin/activate
pip install -U pip

# 2025.1 needs ansible-core 2.16 to 2.17 (check the exact range in the 2025.1 Quick Start)
pip install 'ansible-core>=2.16,<2.18'
pip install git+https://opendev.org/openstack/kolla-ansible@stable/2025.1

sudo mkdir -p /etc/kolla
sudo chown $USER:$USER /etc/kolla
cp -r $VIRTUAL_ENV/share/kolla-ansible/etc_examples/kolla/* /etc/kolla
cp $VIRTUAL_ENV/share/kolla-ansible/ansible/inventory/multinode .

kolla-ansible install-deps

Inventory​

Edit the multinode file you just copied. The groups I use:

[control]
dev-openstack-controller-01
dev-openstack-controller-02
dev-openstack-controller-03

[network]
dev-openstack-controller-01
dev-openstack-controller-02
dev-openstack-controller-03

[compute]
dev-openstack-compute-01
dev-openstack-compute-02

[monitoring]
dev-openstack-controller-01

[storage]
dev-openstack-controller-01

cinder-volume runs on the hosts in [storage]. Because the Synology driver cannot run active/active, that group gets exactly one node. Do not leave it empty: without a node there, cinder-volume is never deployed, even though the backend is not a local disk. Moving it to another node is covered in the failover section below.

Check that Ansible can reach every node before going further:

ansible -i ./multinode all -m ping

Passwords​

kolla-genpwd

This fills /etc/kolla/passwords.yml. Keep that file out of git.

globals.yml​

kolla_base_distro: "ubuntu"

kolla_internal_vip_address: "192.168.19.35"

neutron_plugin_agent: "ovn"
network_interface: "eth0"          # (management)
tunnel_interface: "eth1"           # (internal)
storage_interface: "eth2"          # (storage)
neutron_external_interface: "ens22" # (external)

enable_haproxy: "yes"
enable_keepalived: "yes"
keepalived_virtual_router_id: "51"

enable_cinder: "yes"
enable_horizon: "yes"

enable_iscsid: "yes"
enable_multipathd: "yes"
glance_file_datadir_volume: "/mnt/glance"
enable_cinder_backend_iscsi: "yes"
skip_cinder_backend_check: "yes"
enable_cinder_backup: "no"

The Cinder backend​

Create /etc/kolla/config/cinder/cinder-volume.conf on the deployment host. Kolla copies it to the cinder-volume node.

[DEFAULT]
enabled_backends = synology

[synology]
# Fixed logical host name, so volumes are not tied to one node.
# Set it BEFORE creating the first volume.
backend_host = cinder-synology
volume_backend_name = synology
volume_driver = cinder.volume.drivers.synology.synology_iscsi.SynoISCSIDriver
target_protocol = iscsi

# Path 1: WebAPI and the main iSCSI portal
target_ip_address = 172.16.2.31
# Path 2: second iSCSI portal
target_secondary_ip_addresses = 172.16.3.31

synology_admin_port = 5001
driver_use_ssl = True
# DSM uses a self-signed certificate out of the box
synology_ssl_verify = False
driver_ssl_cert_verify = False

synology_username = <username>
synology_password = <password>
synology_pool_name = volume1

use_multipath_for_image_xfer = True

# Cache images in the backend to speed up "create volume from image"
image_volume_cache_enabled = True
image_volume_cache_max_size_gb = 100
image_volume_cache_max_count = 20

A few notes:

• target_ip_address takes only one IP and is also used for the WebAPI calls. The second iSCSI portal goes in target_secondary_ip_addresses. Either way, verify that both sessions really form (see the multipath check later in this post).
• driver_ssl_cert_verify = False is fine for a lab. In production, install a proper certificate on DSM and leave verification on.
• The image-volume cache only becomes active after you set cinder_internal_tenant_project_id and cinder_internal_tenant_user_id, which need Keystone to be running first. Until then it does nothing, so it is safe to leave in.
• The password sits in this file in plain text. Set chmod 600, keep it out of git, and consider ansible-vault for the file.

Step 4: Deploy​

kolla-ansible bootstrap-servers -i ./multinode
kolla-ansible prechecks -i ./multinode
kolla-ansible deploy -i ./multinode

If OpenStack is already running, apply the backend with a reconfigure instead:

kolla-ansible reconfigure -i ./multinode --tags cinder

Step 5: Create a volume type and test one volume​

First, check that the cinder-volume service for the Synology backend is up:

openstack volume service list
# cinder-volume ... synology ... up

Create a volume type that points to the backend, then create a 10 GB test volume:

openstack volume type create fast
openstack volume type set fast --property volume_backend_name=synology

openstack volume create --size 10 --type fast test-vol
openstack volume list
openstack volume show test-vol -c status -c os-vol-host-attr:host

The status should become available. In DSM, SAN Manager should now show a new LUN and a target whose name starts with Cinder-Target-.

If the status goes to error, look at the Cinder log on the cinder-volume node:

sudo docker logs cinder_volume

Login failures, 2FA problems, and API-version differences on DSM 7 all show up there.

Step 6: Prepare OpenStack​

Everything in this step runs with the admin credentials loaded (source /etc/kolla/admin-openrc.sh).

Security group​

A minimal group that allows SSH, HTTP, and ping from anywhere. Outbound traffic is allowed by the default egress rules that every new group gets.

openstack security group create minimum --description "ssh, http, icmp inbound; all outbound"

openstack security group rule create --ingress --protocol tcp --dst-port 22 --remote-ip 0.0.0.0/0 minimum
openstack security group rule create --ingress --protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0 minimum
openstack security group rule create --ingress --protocol icmp --remote-ip 0.0.0.0/0 minimum

Images​

Download a few cloud images and upload them to Glance. With the NFS setup from Step 2, the uploaded files end up on the DSM share.

mkdir -p ~/images && cd ~/images

wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img
wget https://dl.rockylinux.org/pub/rocky/9/images/x86_64/Rocky-9-GenericCloud-Base.latest.x86_64.qcow2

openstack image create ubuntu-24.04 \
  --file noble-server-cloudimg-amd64.img \
  --disk-format qcow2 --container-format bare --public \
  --property os_distro=ubuntu --property os_version=24.04

openstack image create ubuntu-22.04 \
  --file jammy-server-cloudimg-amd64.img \
  --disk-format qcow2 --container-format bare --public \
  --property os_distro=ubuntu --property os_version=22.04

openstack image create rocky-9 \
  --file Rocky-9-GenericCloud-Base.latest.x86_64.qcow2 \
  --disk-format qcow2 --container-format bare --public \
  --property os_distro=rocky --property os_version=9

Flavors​

openstack flavor create --vcpus 2 --ram 4096 --disk 20 --public c2r4d20
openstack flavor create --vcpus 1 --ram 2048 --disk 10 --public c1r2d10

Networks​

An external network for floating IPs, a tenant network for instances, and a router between them.

# external network + subnet (flat, on the external NIC)
openstack network create ext-net \
  --external --provider-network-type flat --provider-physical-network physnet1

openstack subnet create ext-sub \
  --network ext-net --subnet-range 192.168.19.0/24 \
  --gateway 192.168.19.1 --no-dhcp \
  --allocation-pool start=192.168.19.51,end=192.168.19.71

# tenant network + subnet
openstack network create lab-ops-net

openstack subnet create lab-ops-sub \
  --network lab-ops-net --subnet-range 10.10.10.0/24 \
  --gateway 10.10.10.1

# router: gateway to ext-net, interface to lab-ops-sub
openstack router create ops-router
openstack router set ops-router --external-gateway ext-net
openstack router add subnet ops-router lab-ops-sub

Keypair​

Create a keypair and save the private key on the deployer:

openstack keypair create --private-key ~/.ssh/labops labops
chmod 600 ~/.ssh/labops

Step 7: Boot an instance from a volume​

By default, a Nova instance's root disk is ephemeral and stored on the compute node, not on Synology. To really put the disk on Synology, boot from a volume.

Boot the instance​

Create the root volume from the image on the fast type first, so it is guaranteed to land on the Synology backend, then boot from it:

openstack volume create --size 20 --type fast --image ubuntu-24.04 --bootable vol-root-ops-lab-ubuntu24

openstack server create --flavor c2r4d20 \
  --volume vol-root-ops-lab-ubuntu24 \
  --network lab-ops-net \
  --security-group minimum \
  --key-name labops \
  ins-ops-lab-ubuntu24

Wait until the volume is available before booting, and until the server is ACTIVE before the next step:

openstack volume show vol-root-ops-lab-ubuntu24 -c status
openstack server show ins-ops-lab-ubuntu24 -c status -c addresses

Floating IP and login​

The instance only has an address on lab-ops-net (10.10.10.0/24). Give it a floating IP from ext-net to reach it from your LAN:

openstack floating ip create ext-net
openstack server add floating ip ins-ops-lab-ubuntu24 <floating-ip>

ssh -i ~/.ssh/labops ubuntu@<floating-ip>

Extra data volume​

openstack volume create --size 10 --type fast vol-data01-ops-lab-ubuntu24
openstack server add volume ins-ops-lab-ubuntu24 vol-data01-ops-lab-ubuntu24

Inside the guest, lsblk should show the 20 GB root disk and the 10 GB data disk.

Step 8: Verify the two iSCSI paths​

On the compute node that runs the instance:

sudo docker exec iscsid iscsiadm -m session
# expect two sessions: 172.16.2.31:3260 and 172.16.3.31:3260

sudo docker exec multipathd multipath -ll
# expect one device with two paths, both active/ready

Because the config only knows one target_ip_address, the second session depends on iSCSI discovery: the initiator asks the first portal which portals exist, and DSM advertises both, provided the target listens on both NICs. I treat this as something to verify, not assume. If you only see one session, check that the target is not bound to a single interface, and that port 3260 is open on the second subnet.

Then test the failover. Take one storage interface down on the compute node and keep writing to the volume inside the guest:

sudo ip link set <storage-nic-1> down
sudo docker exec multipathd multipath -ll   # one path failed, one active
sudo ip link set <storage-nic-1> up

I/O in the guest should keep working, possibly after a short stall while multipath switches paths. If the guest freezes instead, the second session most likely never formed. Repeat with the second NIC. By default DM-multipath uses a failover policy (one active path, one standby). Set path_grouping_policy multibus in multipath.conf if you want both paths in use at the same time.

What happens when something fails​

Moving cinder-volume to another node​

Cinder-volume runs as a single active instance (active/passive). Without a DLM and a driver that supports active/active, running several instances against the same backend_host is not formally safe, so failover is manual and the RTO depends on the operator.

Prerequisites (set up once)

1. Use a fixed logical host name in the backend section before creating the first volume, so volumes are not tied to a node name:

[synology]
backend_host = cinder-synology

If volumes already exist under a node-specific host name, check their current host (openstack volume show <id> -c os-vol-host-attr:host, admin only) and move them once:

sudo docker exec cinder_api cinder-manage volume update_host \
  --currenthost <old-node>@synology#<pool> \
  --newhost cinder-synology@synology#<pool>

2. Every candidate node must reach both iSCSI portals (172.16.2.31, 172.16.3.31) over the storage interface and the Synology DSM API (port 5001).

Failover procedure

1. Make sure the old node is really stopped or isolated. Two cinder-volume instances running at the same time is unsafe.
2. In the inventory, remove the old node from [storage] and add the new one.
3. Refresh facts, then deploy only to the new node:

kolla-ansible gather-facts -i ./multinode
kolla-ansible deploy -i ./multinode --tags cinder,iscsi --limit <new-node>

If gather-facts fails because the dead node is unreachable, temporarily remove it from the inventory or limit the facts to the remaining hosts. 4. Verify:

openstack volume service list      # cinder-synology@synology must be up
openstack volume create --size 1 failover-test

5. Volumes stuck in creating, attaching or deleting from before the failure are not recovered automatically. Reset them and retry:

openstack volume set --state available <id>   # or: cinder reset-state

When the old node returns

Deploy does not stop containers on hosts outside [storage]. Before bringing the node back online (or immediately after, if it auto-starts), remove the stale container so it does not run next to the new one:

sudo docker rm -f cinder_volume

Scope of the failure

Only the control path for volumes (create, attach, detach, delete) is interrupted. Running instances keep their I/O because the data path goes directly from the compute node to the Synology over multipath iSCSI.

If the Synology driver does not work​

The driver is the part most likely to give trouble on newer DSM versions. If it does, there is a fallback that keeps the same hardware: create one big LUN manually in DSM, log in to both portals from the cinder node with iscsiadm, let multipath merge them into one device, build an LVM volume group named cinder-volumes on it, and use Kolla's regular LVM backend (enable_cinder_backend_lvm and enable_cinder_backend_iscsi). Cinder then slices volumes inside LVM, and DSM is just a big disk. You lose Synology's native snapshots and clones, but it is the most predictable path.

Troubleshooting​

Wrap up​

Cinder plus a Synology box is a pleasant way to learn the full block-storage flow: WebAPI calls to create LUNs, iSCSI logins from compute nodes, multipath on two paths, and boot-from-volume. It is not a high-availability storage design, because DSM and the single cinder-volume node are both single points of failure. Treat it as a lab and learning setup, and when you need real storage HA, move to Ceph.

What is Xpenology?​

DSM (DiskStation Manager) is the operating system that ships with Synology NAS devices. It gives you a clean web interface for storage management, file sharing (SMB, NFS), user and permission management, backups, containers, and a large catalog of packages.

Normally DSM only boots on a real Synology box. Xpenology is not an operating system by itself. It is the name of the community effort that makes DSM boot on hardware Synology never made: a desktop PC, a spare server, or a virtual machine.

For a homelab this is attractive. You are not limited to the CPU, RAM, disk bays, and network ports of a specific Synology model. You can reuse whatever you already have, or simply try DSM inside a VM without buying anything.

How does it work?​

DSM expects to find a Synology device underneath it: a known model name, a serial number, specific hardware. A generic PC or VM does not look like that, so a small piece of software called a loader sits in front of DSM.

The loader boots first, presents the identity and settings DSM wants to see, and then hands control to the DSM kernel. The boot flow looks roughly like this:

BIOS / UEFI
     │
     ▼
  Loader  (small boot disk)
     │
     ▼
    DSM   (installed on the data disks)
     │
     ▼
 NAS services (SMB, NFS, iSCSI, apps ...)

This also explains the disk layout you will see later in the VM: the loader lives on its own tiny disk, and DSM is installed onto separate data disks.

What is Arc Loader?​

There are a few different loaders in the Xpenology world. Arc Loader (by AuxXxilium) is the one used in this post, and it is popular because it takes most of the manual work out of the process:

• It is menu driven. You choose a model, a DSM version, and some options, and Arc builds the loader for you. No hand-editing config files.
• It downloads the DSM installation file for you during the build.
• It generates the serial number and MAC addresses that DSM will use.
• It ships as a ready-to-use disk image, which is easy to import into Proxmox.
• It has a built-in web terminal on port 7080, so you can drive the menu from a browser instead of the Proxmox console.

Before you start​

Xpenology is a great way to learn and to build a homelab NAS, but there are a few things worth knowing up front.

• RAID and redundancy are not a backup. If a file is deleted by mistake, every disk in the array agrees that it is gone. Keep a separate backup of anything important.
• Be careful with updates. A DSM update that is fine on a real Synology can fail on Xpenology. Take a Proxmox snapshot or backup before every DSM update, and turn off automatic updates.
• A virtual disk is not redundancy. A single VM disk on a single Proxmox node is exactly one copy of your data.

Requirements​

• A Proxmox VE host with internet access
• A network bridge with internet access (this post uses vmbr0)
• A storage target for VM disks (this post uses local-lvm; use whatever you have)
• A DHCP server on the network, or be ready to set a static IP in DSM afterwards
• Suggested VM resources: 2 vCPU, 4 GB RAM, and as much data disk as you like

Step 1: Download the Arc image​

On the Proxmox host, download the latest Arc release from the project's GitHub releases page (github.com/AuxXxilium/arc). The asset is a zip file with a single .img inside.

cd /tmp
wget <URL of the arc-<version>.img.zip asset from the releases page>
unzip arc-*.img.zip
ls -lh arc-*.img

If unzip is missing, install it with apt install -y unzip.

Step 2: Create the VM​

I use two shell variables so the commands can be copy-pasted. Change them to fit your host.

VMID=100
STORAGE=local-lvm

Create the VM without any disks. The loader image is imported as a disk in the next step.

qm create $VMID \
  --name xpenology-dsm \
  --ostype l26 \
  --machine q35 \
  --cpu host \
  --sockets 1 --cores 2 \
  --memory 4096 --balloon 0 \
  --net0 virtio,bridge=vmbr0

A few notes on those options:

• --cpu host passes the real CPU features to the guest. DSM and some of its packages can be picky about CPU flags, and host avoids most surprises.
• --balloon 0 turns off memory ballooning. A NAS operating system does not like having its memory taken away behind its back.
• VirtIO is fine for the NIC in most cases. If Arc does not detect it later, switch to e1000: qm set $VMID --net0 e1000,bridge=vmbr0.

Step 3: Import the loader and add a data disk​

Import the Arc image and attach it as SATA0:

qm importdisk $VMID /tmp/arc-<version>.img $STORAGE
qm set $VMID --sata0 $STORAGE:vm-$VMID-disk-0

Now add the data disk as SATA1. The number after the colon is the size in GB:

qm set $VMID --sata1 $STORAGE:50

Finally, make the loader disk the boot device:

qm set $VMID --boot order=sata0

Check the result:

qm config $VMID

You should see sata0 (the loader), sata1 (the data disk), net0, and boot: order=sata0.

Step 4: Boot and build the loader​

Start the VM and open its console in the Proxmox web UI:

qm start $VMID

Arc shows a text menu and prints the IP address the VM received, along with the address of its web terminal:

http://<vm-ip>:7080

You can continue in the Proxmox console, but the web terminal is nicer to work with. Menu labels differ a little between Arc versions, but the flow is always the same:

1. Choose a model. Pick one from the list Arc offers. The model decides things like the maximum number of disks and which CPU features are required, so read the notes Arc shows.
2. Choose a DSM version. Pick a DSM 7.x release.
3. Review the options. Arc generates a serial number and MAC address for the VM. Write them down. If you ever recreate the VM, reuse the same values so DSM recognizes it as the same device.
4. Pick addons if you want any. Skipping them is fine for a first install.
5. Build the loader. Arc downloads the DSM file from Synology, so the VM needs internet access for this step.
6. Boot the loader. Arc restarts into the DSM installer.

Step 5: Install DSM​

After the loader boots, the VM looks like a brand new, uninstalled Synology device. From your laptop:

• open http://<vm-ip>:5000, or
• open find.synology.com from a machine on the same network.

Then:

1. Click Install. DSM installs itself onto the data disk and the VM reboots once or twice.
2. Create your admin account.
3. Finish the setup wizard. You can skip the Synology account and QuickConnect options.

When the DSM desktop appears, you are done. From here you can create a storage pool and volume, set up shared folders, and install packages like on any other Synology.

Step 6: Autostart and snapshots​

Make the VM start together with the Proxmox host:

qm set $VMID --onboot 1

And before touching anything risky, such as a DSM update or a loader rebuild, take a snapshot:

qm snapshot $VMID before-update

To roll back if something goes wrong: qm rollback $VMID before-update.

Troubleshooting​

Wrap up​

Xpenology lets you run DSM on hardware that Synology never intended, and Arc Loader makes the process mostly point and click. For a Proxmox VM it comes down to this: import the Arc image as SATA0, add a data disk as SATA1, build the loader from the Arc menu, and run the normal DSM installer. Just keep in mind that it is an unsupported setup, so snapshot before updates and keep real backups of anything you care about.

Introduction​

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Main Content​

Praesent euismod, nunc vel consectetur interdum, nisl nisi aliquam nunc, eget aliquam nisl nisi eu nunc. Sed euismod, nunc vel consectetur interdum, nisl nisi aliquam nunc, eget aliquam nisl nisi eu nunc.

Introduction​

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Main Content​

Praesent euismod, nunc vel consectetur interdum, nisl nisi aliquam nunc, eget aliquam nisl nisi eu nunc. Sed euismod, nunc vel consectetur interdum, nisl nisi aliquam nunc, eget aliquam nisl nisi eu nunc.

I. Create a new blog post​

Simply add Markdown files (or folders) to the blog directory.

Regular blog authors can be added to authors.yml.

The blog post date can be extracted from filenames, such as:

• 2019-05-30-welcome.md
• 2019-05-30-welcome/index.md

A blog post folder can be convenient to co-locate blog post images:

The blog supports tags as well!

And if you don't want a blog: just delete this directory, and use blog: false in your Docusaurus config.

Use a <!-- truncate --> comment to limit blog post size in the list view.

1. Create a new blog post​

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet