kroese

This is not possible because the stock VirtualDSM kernel has no virtiofs module (like Xpenology has). Yes.. See https://github.com/vdsm/virtual-dsm#how-do-i-add-multiple-disks You cannot expose SATA controllers. You can either just bind a folder, where a virtual disk image (data.img) will be created, or passthrough a whole block device (not recommended). See https://github.com/vdsm/virtual-dsm#how-do-i-change-the-location-of-the-virtual-disk You cannot expose a NIC. But like @JuanjOD already explained, you can create a macvlan network. See https://github.com/vdsm/virtual-dsm#how-do-i-assign-an-individual-ip-address-to-the-container Yes it is always safe to upgrade. Because this container uses a completely stock (unmodified) version of DSM, which means that upgrades can never break the system. With XPenology that is different, because it modifies a lot of things (bootloader, kernel modules, etc). Also this update should fix the problem with notifications that you had (see https://github.com/vdsm/virtual-dsm/issues/313#issuecomment-1788824213 ). For all other people: I wont be replying here anymore. Because almost every question was already answered in the FAQ. If you have any issue, it should be reported to https://github.com/vdsm/virtual-dsm/issues and not here.

That is because you use the "-rm" flag which means: remove. But your questions are all about general Docker use, they have nothing to do with my container.

You can use the -e flag so add "-e CPU_CORES=3 -e ALLOCATE=N" to the docker run command.

I have only experience with macvlan under Linux, im not sure if its completely supported under Windows. So it might be easier to just keep it in bridge mode. When you said that other computers could not see the Virtual DSM, did you mean they cannot connect to port 5000 of your Windows machine? Maybe you need to open those ports in the Windows Firewall for them to be able to reach that port. Because if you can connect to that port from your local machine but not from other places, the only logical explanation would be that a firewall blocks access to it.

@hendry It's not possible to mount a physical drive because the container runs a completely stock (unmodified) image of Virtual DSM. So it does not contain any of the required kernel drivers like virtiofs or 9p, because Synology does not include them. And I prefer to keep it that way, otherwise it will experience the same problems as Xpenology (broken system after installing updates, etc).

Its explained here: https://github.com/kroese/virtual-dsm/issues/266 how to do it.

No, the second "networks" needs to be seperated from "services", so like this: services: dsm: container_name: dsm image: kroese/virtual-dsm:latest environment: CPU_CORES: "2" DISK_SIZE: "256G" ALLOCATE: "N" RAM_SIZE: "2048M" networks: vdsm: ipv4_address: 192.168.X.XX devices: - /dev/kvm - /dev/vhost-net cap_add: - NET_ADMIN ports: - 5000:5000 volumes: - /home/user/dsm/storage:/storage restart: on-failure stop_grace_period: 1m networks: vdsm: external: true

According to their website they use KVM for all their VPS'es. And they do support nested virtualization. So you should be able to use KVM on that VPS.

If you set DEBUG the container will skip the check for KVM yes. But it will run very slowly because there is no hardware acceleration, so it's not recommended. What device do you have that it does not support KVM? Because almost every device can support it.

I agree that its a bit pointless to use Proxmox for this container. But many people do it, so I think the reason is that they already have a machine in their house dedicated to Proxmox VE. If they want to run the docker container on that machine, their only option is too install it inside a Proxmox VM. The reason why they don't install Xpenology on that machine may be that my container has a completely unmodified version of DSM (so no bootloaders, kernel modules, etc.). So the chance something breaks when updating DSM to newer versions is a lot smaller. But you are right that the primary advantage for this container is that it does not need something like Proxmox.

I have no experience with Proxmox, so I cannot provide you the exact steps. Maybe another Proxmox user here can write them down.

You must set the Docker environment variables HOST_SERIAL, GUEST_SERIAL and VM_NET_MAC for that. The last two you can find by creating an instance of VirtualDSM in VMM temporarily. And the first one is the SN of your NAS. If you use the correct values then logging into your Synology account becomes possible.

Yes, i'm running Windows 11. Maybe that is the difference why WSL2 has KVM support by default.

I think this could be the solution! But I never applied those settings myself? Maybe the installation of Docker for Desktop did them automaticly for me.

For me KVM works fine on Windows with Docker for Desktop and WSL2. And we both have exactly the same CPU model. So why yours doesnt support virtualization and mine does, is a mystery. The only logical explanation was if you disabled it in the BIOS, but you checked that already. So something must be wrong with the Win11 settings. Best is to follow Orphee's advice and check if it works on a Linux LiveCD.

You can specify the URL to any PAT file you like as a docker environment variabele, see the FAQ.

@apriliars3 That cpu supports KVM, because I have the same one and here it works. Maybe you have virtualization disabled in the BIOS?

@Orphée You can change CPU_CORES and RAM_SIZE as docker environment variabeles.

That error was already fixed today, you should pull the latest version.

@loganm20 In that case leave out the KVM part (since MacOS doesnt have it), so the line becomes: docker run --rm -it --name dsm -p 5000:5000 -p 5001:5001 --cap-add NET_ADMIN kroese/virtual-dsm:latest

@apriliars3 I don't think that would be legal, so I never tried.

@apriliars3 WSL2 should have higher performance, less overhead and less RAM usage than running a full VM like VirtualBox or VMware. It's just the Linux kernel running via Hyper-V and not a complete OS. But the impost important thing is that it supports KVM acceleration for this docker container, which those others do not. So I am sure it will run much better via Docker Desktop/WSL2 than via Proxmox/VirtualBox/VMWare. They are made for different things.

@apriliars3 I made a new version that is compatible with Windows 11 (and MacOS). That means you don't need to use Proxmox anymore. To run it you install Docker Desktop for Windows, and make sure it uses the WSL2 subsystem (I think its the default in Win11). Then go to command prompt (or Powershell) and type: docker run --rm -it --name dsm -p 5000:5000 -p 5001:5001 --cap-add NET_ADMIN --device="/dev/kvm:/dev/kvm" kroese/virtual-dsm:latest @loganm20 I think this new version (v1.79) will also work in MacOS, because I removed the need for the TUN interface that caused your error last time. So please try it out. I think you must execute the above line (same as the one for Windows) in the Terminal application, because the Docker application does not allow to specify this NET_ADMIN flag from the GUI. I'm very positive it will work now, fingers crossed!

@apriliars3 Yes you can upgrade to 7.2. You can also do a clean install of 7.2 from scratch by adding this to your docker compose file: environment: URL: "https://global.synologydownload.com/download/DSM/beta/7.2/64216/DSM_VirtualDSM_64216.pat" You can also modify the disk size in this compose file by changing: environment: DISK_SIZE: "16G" I created a FAQ for answers like this on https://github.com/kroese/virtual-dsm (bottom of the page).

No, the issue is that it cannot find the /dev/net/tun path specified in the compose file. I think on MacOS it needs to be changed to /dev/tun0 or /dev/tun1 or something like that, but I have no clue how you can find the right name.