Thanks for the reply. I think it was something on my end.
I’ve been running Roon on my Unraid server in a docker container for ages. I have a pretty beefy Windows 11 VM with 16 GB of RAM dedicated to it and it runs off a passed through NVME drive. I’m wondering if there is any benefit to moving my Roonserver install over to Windows or if I should leave it running on Docker?
When you say “move it over to Windows” do you mean move it to the Windows VM inside Unraid?
Don’t forget Roon Inc. says the Roon core should be on the same device as the music files.
Running it on Windows means Roon Inc supports it, and i think would have less problems. I run on a Roon docker (no VM) and it took a while to work out the bugs. But now I am happy with it.
If you have been running in a docker (no VM) for ages, I assume it is working well for you. If so, I would not change to a VM. I think there would be less overhead is you do not use VM. But if you have problems, then I would try the VM, especially if you already have the VM set up and working well.
Yes, I was referring to the Windows VM inside of Unraid. My music library is on the Unraid server although if I move it to Windows I’d have to use SMB as VirtioFS isn’t yet stable on Unraid. I thought I read on here somewhere that Roon runs better on Windows. Regardless SMB shouldn’t be an issue as the traffic routes within the server and the virtual NIC I’m using is 10 gbit so there shouldn’t be any bottleneck when accessing the files.
Do you mean move the music to Windows?
If you put Roon on a VM inside Unraid, maybe you could leave the music files on Unraid with no VM.
If Roon runs good in a docker (no VM), I don’t think you would notice a difference in a VM. I would only do it if you have problems in a docker (no VM).
No I was wondering if it made sense to migrate my Roon install from Docker running under Unraid to a Windows VM also running under Unraid. All of the music files are on my Unraid array in either scenario.
If Roon runs good in a docker (no VM), I don’t think you would notice a difference in a VM. I would only do it if you have problems in a docker (no VM).
Sounds good. Moving my appdata from a SATA SSD cache to an NVME SSD cache made a huge difference especially with ARC so I think I’ll leave things as is. I just knew that the docker is technically unsupported by Roon and while VMs aren’t supported, Windows is supported and it shouldn’t matter from a support perspective if Windows is running on a VM or baremetal.
This is good guidance. Speaking very, very generally, I would not expect software running in a Windows VM on a linux system to outperform similar software running in Docker on the same machine. While Roon runs on Windows, Nucleus devices are linux and that’s obviously at least as first-tier as Windows.
I used to work with a guy who would talk about “sideways innovation”. In other words, work that, at best, takes you sideways and not forwards. That concept seems applicable here. I wouldn’t do it 
Thanks. I guess if the docker container ever breaks it’ll at least be there as an option. I spent $700 on a lifetime sub so I have too much invested in Roon and way to much invested in Unraid to abandon either.
1 Like
That is interesting. Glad you mentioned it.
The investment is quite large, but so far so good. It seems we have a good chance to get many years of usefulness.
Nvme drives are really cheap right now. I picked up a 2 TB Samsung 980 Pro for ~130 or so.
I run a QNAP NAS and I’ve been having a problem with Roon both using the native QNAP app, and also running it in a container using Steef’s image.
My problem is that I get odd dropouts, the core loses connection with players, the client hangs etc. Roon Support have suggested to me that this may be because the Roon core is seeing multiple IP addresses on the host and this might be causing the issue. The multiple addreses it can see are the various other Docker containers running on the same host in their own virtual docker networks.
I’m presuming no-one else on here is experiencing these problems, so I’m taking Roon support’s suggestion with a pinch of salt, but I want to do some testing.
So this might be more of a docker infrastructure question. Is there a way I can isolate my Roon docker container from the other containers on the host so the RoonServer in the container is only aware of it’s own IP? I have the ability to add a second physical network connection to the QNAP as well. Perhaps dedicating that to the container would work. I’m coming up against the limits of my docker knowledge here though, so any ideas would be appreciated.
Cheers
Jamie
I’m running Roon server on docker on a Synology NAS. Initially I was using the host network, but just last week I migrated to a configuration using MacVLANs. I’ve reserved one of my NICs to the Roon server and Roon extension and in doing so, keeping Roon in it’s own VLAN, away for the host and other dockers.
I think that might be exactly what I want to do.
I know how to do this at the switch - could you share your docker compose file so I can see how you did it in the container?
Other than assigning the VLAN as the default on the switch port, I created the MacVLAN for docker using the following command line:
sudo docker network create -d macvlan -o parent=eth5 --subnet=192.168.50.0/24 --gateway=192.168.50.1 --ip-range=192.168.50.16/28 mv_audio
As you can see I opted for a range of addresses to allow Roon extensions running in other dockers to also have an address in the same range. I also ensure that this range of address is not used by the DHCP on my router to assign to other devices. From what I understand, it should also be possible to achieve this with a docker container but I stuck with the command line.
In then referred to the network in the docker compose and manually assigned an ip address to the container:
version: "3.3"
services:
roonserver:
image: steefdebruijn/docker-roonserver:latest
container_name: roonserver
restart: unless-stopped
hostname: roonserver
volumes:
- /volume2/docker/roonserver/app:/app
- /volume2/docker/roonserver/backup:/backup
- /volume2/docker/roonserver/data:/data
- /volume1/music:/music
networks:
macvlan_network:
ipv4_address: 192.168.50.16
environment:
- TZ=Europe/Brussels
networks:
macvlan_network:
name: mv_audio
Finally I defined a static route on the network to ensure that all traffic from the audio macvlan is sent out via the correct NIC.
Credit to @patrick_mccarthy for showing me this setup.
All, to create the macvlan via COMPOSE, you just fake out docker that you are creating a new docker image (that never starts) and build an external network definition in that compose file. (Why docker compose doesnt have the option to just build the network is beyond me) --also, this was not my idea, I got it from “the inter-webs”
here is my compose file to create the network and not have to use SSH (I see pasting below removes the indents - which are paramount for compose - see the image below for correct indenting):
version: ‘3.3’
services:
dummy:
image: alpine
networks:
mvlan_ent20_eth4_lan5:
networks:
mvlan_ent20_eth4_lan5:
name: mvlan_ent20
driver: macvlan
attachable: true
driver_opts:
parent: eth4
ipam:
driver: default
config:
- subnet: 10.10.20.0/24
ip_range: 10.10.20.208/28
gateway: 10.10.20.5
aux_addresses:
root: 10.10.20.208
shim: 10.10.20.209
here are some details:
- I just use a dummy alpine image - it will never run
2.this is the logical name of the network as defined below (mine tells me the ethernet port on my nas) - in the network section, you get to give it a nice friendly NAME
- as Sven has stated, this is all the magic - the full subnet this is on (/24), the range the macvlan will assign out (its like its own mini-dhcp in this range), the gateway, then you can reserve IP addresses in the aux_addresses section - the shim for me is for future use IF I want the host to be able to get into the image… lots on the internet about that - roon and rheos do not need this.
- note the PARENT tag - this is the ethernet port on your NAS you want to dedicate to.
- Sven and I set the network switch’s port to the vlan and do NOT tell the nas that the port is part of a vlan -
LASTLY, without the static routes being defined on the NAS, you will get odd behavior of traffic as docker and synology love to “help” here… - the static routes ensure all traffic flows correctly.
BTW, there is a GREAT side-effect of this setup (both Sven’s SSH and this compose file) - you can SET the IP address of the roon and rheos image in their compose files instead of having the macvlan auto assign…
here is a snippet from my Roon compose file:
- note the networks section and reference to the friendly name, then the IP4_ADDRESS section, lastly the “networks” section is where this compose connects to the external network you created via SSH or my compose (or similar). Now I know roon will always be 210 and rheos is always 211 and my plex is always 212 etc…
1 Like
So you setup a second docker compose with the dummy image to create the network, and then run it before you start roon every time? Or do you just run that once? If you run it every time, how do you deal with the dependency?
The only other thing that I’m not clear about is where you’re getting mvlan_ent20_eth4_lan5 from. Is that just your logical name or something else? Bear in mind that I’m using QNAP and not Synology.
I got it working using the command line method Sven defined above but if I can get this working I might move to this.
The only thing I’m having trouble with is getting the remote control extensions working in RoPieeee. The roon server just doesn’t see them for me to register them. Have you seen that problem?
I think I’ve probably answered my own question here - extension discovery doesn’t work across VLANs. So I moved my RoPieee devices into the new audio VLAN and it’s now working as expected.
The only thing I had to to differently from Sven’s instructions is add an external flag into my docker compose in the network section at the bottom, otherwise it tried to create the network itself when I started it, so mine looks like this
1 Like
looks like you got the answers…
but just for documentation:
- the dummy compose is run only once - never to be used again (unless I want to destroy and re-create the network slightly differently)
- you have to use the external flag so the network is exposed to the other dockers to connect to
- the weird internal name “mvlan_ent20_eth4_lan5” is just my name - you can use whatever you want – this lets me know its on my lan5 which is the 4th nic card in my device (and its a macvlan on my entertainment vlan 20 )