Running Xpenology on Proxmox or ESXi: Pros & Cons

Synology

Running Xpenology directly on physical hardware is not the only way to bring Synology DSM into a homelab. Advanced users can instead run Xpenology as a virtual machine under a hypervisor such as Proxmox VE or VMware ESXi.

This architecture can be particularly attractive when one physical server needs to perform several roles. Instead of dedicating the entire machine to DSM, the hypervisor remains in control while Xpenology operates alongside Linux servers, Windows virtual machines, containers, home automation, and other workloads.

Current Arc documentation lists VMware ESXi and QEMU/KVM-based platforms such as Proxmox among its supported hypervisor environments. However, virtualization introduces another infrastructure layer that must be designed correctly, especially around storage.

Why Virtualize Xpenology?

A bare-metal Xpenology server effectively dedicates the machine to DSM.

Virtualization changes that relationship:

Physical Server → Hypervisor → Xpenology VM → DSM

The same host could simultaneously run:

Xpenology/DSM
Windows Server
Linux VMs
Docker or LXC workloads
Home Assistant
Development environments
Monitoring tools
Other lab services

For users who already operate Proxmox or ESXi, creating a separate physical NAS solely to access DSM features may therefore seem unnecessary.

Advantage: Better Hardware Utilization

Virtualization can make powerful server hardware considerably more useful.

Imagine a server with:

12-core processor
64 GB RAM
Multiple NVMe drives
Eight HDDs
10GbE networking

DSM may not need all those CPU and memory resources. With Proxmox or ESXi, you can assign Xpenology only what it requires and make the remaining resources available to other virtual machines. Arc currently specifies at least 6 GB of memory for both native and VM installations, although the appropriate allocation depends on the applications and workloads being run.

Advantage: Easier Resource Allocation

A hypervisor provides another management layer around DSM.

Administrators can decide how many CPU cores and how much RAM the Xpenology VM receives rather than giving DSM unrestricted access to the entire host.

This is useful when the physical server supports several workloads.

For example:

Xpenology: 4–8 vCPUs + 16 GB RAM

Windows VM: 4 vCPUs + 16 GB RAM

Linux services: Remaining resources

The exact allocation should be based on actual utilization rather than an arbitrary formula.

Proxmox vs ESXi for Xpenology

Both platforms can work, but they appeal to somewhat different homelab environments.

Current Arc documentation lists Proxmox 8 as stable, while noting potential issues with some Linux-based systems under Proxmox 9. VMware ESXi versions 7, 8, and 9 are listed as supported environments.

Storage Is the Most Important Design Decision

CPU and RAM configuration is relatively straightforward.

Storage is where virtualized Xpenology becomes more complicated.

You need to decide whether DSM will see:

Virtual disks created by the hypervisor, or
Physical storage hardware passed through to the VM.

These approaches have very different implications.

Option 1: Virtual Disks

The simplest architecture is to create virtual disks in Proxmox or ESXi and present those disks to DSM.

This is convenient because the hypervisor retains control of the underlying physical storage.

However, DSM is no longer interacting directly with the physical disks.

That creates additional abstraction:

Physical disk → Hypervisor storage → Virtual disk → DSM

For experimentation, testing, or noncritical workloads, this can be convenient.

For a serious NAS, many experienced users prefer DSM to have more direct visibility into the physical storage devices.

Option 2: Pass Through the Storage Controller

Another approach is PCIe passthrough.

Instead of allowing the hypervisor to manage individual NAS drives, an entire compatible HBA or SATA controller can be assigned directly to the Xpenology VM.

The architecture becomes closer to:

Physical drives → Passed-through controller → DSM

This allows DSM to interact more directly with the disks.

Proxmox’s documentation confirms that PCIe passthrough requires appropriate CPU support for Intel VT-d or AMD-d/IOMMU.

This approach is particularly attractive when DSM is expected to manage RAID/SHR, SMART monitoring, drive health, and storage pools itself.

Controller Compatibility Still Matters

Passing a controller through does not automatically make it compatible with DSM.

Current Arc documentation explains that storage-controller support varies according to the DSM platform selected. Device Tree models have different SATA/HBA/SCSI limitations than non-DT platforms, and not every driver is available. Arc also warns that SMART information may be inaccurate with certain HBA, hardware RAID, and SCSI configurations. Choose the controller and DSM platform together rather than buying an HBA first and hoping the loader solves everything later.

Avoid Unnecessary Hardware RAID Layers

If DSM is expected to manage its own storage pools, placing hardware RAID underneath DSM can complicate the architecture. DSM generally benefits from seeing individual drives. A cleaner design may therefore use an HBA exposing disks individually rather than presenting one large hardware RAID virtual disk.

This makes the responsibility clearer:

Hypervisor manages computing resources.

DSM manages NAS storage.

Mixing several RAID and virtualization layers can make troubleshooting considerably harder.

Disk Mapping Requires Careful Planning

Virtual Xpenology installations also need consistent disk mapping.

Arc’s current VM guidance recommends attaching the loader disk at SATA and assigning data drives to subsequent SATA or supported SCSI positions. For VM environments using SATA controllers, its port-mapping documentation recommends consecutive ports wherever possible.

This matters because DSM expects disks to appear in a predictable structure.

Randomly changing controllers, virtual disk addresses, or drive mappings after building the storage pool can create unnecessary problems.

Networking Is Another Major Advantage

Virtualization provides considerable networking flexibility. A Proxmox or ESXi host may have several physical NICs while exposing virtual network adapters to individual VMs.

This makes it possible to separate:

NAS traffic
Management traffic
VM traffic
Backup traffic
Storage networks
Internet-facing services

For high-performance storage, a physical 10GbE adapter can also be dedicated or passed through where the hardware and architecture support it.

The correct approach depends on whether maximum performance or virtual-network flexibility is more important.

GPU Passthrough Can Help Media Servers

Some Xpenology users want DSM primarily for Plex, Jellyfin, or related media workloads.

Virtualization can complicate hardware transcoding because DSM does not automatically control the host’s integrated GPU. GPU or iGPU passthrough may therefore be required.

Arc provides specific guidance for Intel i915 passthrough in VM environments, including IOMMU-related configuration. GPU passthrough can work well, but it adds another dependency that needs to survive hypervisor, loader, DSM, kernel, and driver updates. For a simple media server, bare metal may sometimes be easier.

Virtualization Adds Another Failure Layer

This is the largest disadvantage.

A bare-metal Xpenology installation already depends on:

Hardware + Loader + DSM

Virtualization adds:

Hardware + Hypervisor + Virtual hardware/passthrough + Loader + DSM

Now an update to Proxmox, ESXi, Arc, DSM, or a device-passthrough configuration can potentially affect the NAS.

That does not necessarily make virtualized Xpenology unreliable, but it increases the knowledge required to maintain it.

Hypervisor Snapshots Are Not NAS Backups

One particularly dangerous mistake is assuming that VM snapshots eliminate the need to back up DSM data. A VM snapshot may help with certain configuration or software changes, but it should not replace independent backups of important NAS data. Storage pools containing terabytes of business or personal information need a real data protection strategy.

Consider separate:

DSM configuration protection
File backups
Snapshots inside DSM
Offsite backups
Hypervisor configuration backups

Each protects against different failure scenarios.

Think About the Boot Dependency

When DSM is virtualized, the NAS cannot start until the hypervisor itself is operating. That matters after power failures and maintenance.

Your startup chain becomes:

Physical host boots → Proxmox/ESXi starts → Xpenology VM starts → Arc loads → DSM starts → Storage becomes available

If other VMs depend on storage hosted by DSM, startup ordering becomes important. Avoid circular dependencies where the hypervisor needs storage from DSM before the DSM VM can start.

Proxmox Is Attractive for Homelabs

Proxmox is particularly appealing when the server will run many unrelated workloads.

It combines KVM virtual machines, containers, networking, storage management, backups, clustering capabilities, and a web interface. For Xpenology users, the ability to dedicate a storage controller to DSM while keeping the rest of the machine available for VMs creates an efficient homelab architecture. But resources need to be sized for the complete host, not just DSM. Proxmox itself requires memory, and technologies such as ZFS or Ceph can increase host memory requirements substantially.

ESXi Remains a Viable Xpenology Platform

VMware users can also run Xpenology under ESXi.

Arc’s current guidance includes VMware-specific settings, including recommended guest OS selections and configuration considerations for LSI Logic SAS. It also notes that promiscuous mode may need to be accepted for certain DSM virtualization, container, or Docker use cases.

For someone already experienced with VMware infrastructure, there may be little reason to introduce another hypervisor solely for Xpenology.

The best platform is often the one you already understand and can recover confidently.

When Virtualized Xpenology Makes Sense

Running Xpenology as a VM is most attractive when:

You already operate Proxmox or ESXi.
One server needs to support several workloads.
You understand PCIe passthrough and IOMMU.
You can dedicate storage hardware appropriately.
You want DSM without dedicating an entire physical server.
You are comfortable troubleshooting multiple infrastructure layers.

For an advanced homelab, this can provide an impressive combination of flexibility and DSM functionality.

When Bare Metal Is Better

Bare metal remains attractive when simplicity is the priority. If the machine exists solely to function as a NAS, installing a hypervisor underneath DSM may add complexity without providing much benefit. Bare metal eliminates one management layer and can simplify direct disk, NIC, and GPU access. Neither architecture is universally superior. The deciding question is whether you actually need the other capabilities the hypervisor provides.

When Genuine Synology Hardware Is the Better Choice

Virtualized Xpenology offers tremendous flexibility, but that flexibility comes with administrative responsibility.

For a home lab, experimentation, or learning environment, managing hypervisor passthrough, loader compatibility, and DSM updates may be perfectly acceptable. Business-critical storage is different. When a company depends on DSM for file services, Microsoft 365 backups, virtual machines, surveillance, or disaster recovery, the time spent diagnosing whether a failure originated in ESXi, Proxmox, passthrough, Arc, DSM, or the physical hardware can outweigh the savings of DIY infrastructure. Design reliable DSM architectures with expert Synology consulting.

Official Synology hardware provides a much clearer support and lifecycle path.

About Epis Technology

Epis Technology helps businesses design supported Synology and virtualization environments around real operational requirements. Services include Synology consultation and deployment, large storage architecture, virtualization, business backups, Microsoft 365 and Google Workspace protection, high-speed networking, storage migration, cybersecurity, disaster recovery, and ongoing Synology support. For organizations considering whether DSM should run on dedicated Synology hardware or alongside virtual infrastructure, Epis Technology can help design an architecture that balances performance, scalability, recoverability, and long-term support.