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.