ROCK on a virtual machine?

The benefit of ROCK is that it is, by definition, “optimized for Roon.” The disadvantage is that ROCK monopolizes the machine that it’s installed on.

If one wished to have ROCK while playing music but still maintain the “general purpose computer functions” when NOT listening to music…

Would it be feasible to use a virtual machine for ROCK installation? VM-Ware Fusion and other software can create virtual machines where the user can install a myriad of alternate operating systems that can be allowed direct hardware access with minimal (or no) interaction with the virtualization layer.

Just a thought…

1 Like

@Glenn_Young, I’ve move your post to the #tinkering category since you are more likely to have a reply from someone who has tried this here.

1 Like

Yes. I’ve used VM-Ware EXSI before with good performance returns.

1 Like

Instead of running a VM with ROCK, why not just run Roon core? That should use fewer resources on the host machine.


The benefit of ROCK is mainly that it uses all hardware resources for Roon. Putting it into a VM more than negates this. You are probably better off running Roon Server directly on the general-purpose OS instead of running the general-purpose OS anyway to run the VM software and on top of that wasting resources on the virtualization.


Hi @Suedkiez -

I suspected as much. Even though a virtual machine CAN access the host machine’s hardware, the virtualization layer is still there.

Also, ROCK is likely to access some hardware functions that may not be supported by virtualization.

And finally, ROCK is customized to function properly in a NUC environment, and to the best of my knowledge, there are no “virtual NUCs.”

There is always some CPU hit, and in any case you can’t escape the RAM being split

1 Like

True - Fortunstely, my NUC came with a 1TB SSD and lots of RAM. I should be OKb with room to spare for ROCK.

We’re I running on a general purpose machine, the Roon core would have to share resources with the host OS.


I successfully ran VM-Ware EXSI with VMs for Rock, Win 10, Ubuntu Desktop 22.04 and as a file server. My machine is only a Dell Optiplex 7040 with 32gb Ram. Whilst not a power house it worked fine t a certain degree. VM-Ware EXSI didn’t use a lot of resources either.

1 Like

I have two lifetime Roon accounts. One account is on my Intel Mac using VMware-nized ROCK and the other account is on my i9 server using KVM/QEMU-nized ROCK. Subjectively my brain thought this way SQ is better than my old NUC10 direct-installed ROCK.


I’ve run ROCK on ESXi, Virtual Box, and my current hypervisor Proxmox.

It works a treat! Initial install can be a little tricky but once it’s installed it upgrades and functions just like any other ROCK install. note! I have a direct, hardware passthrough, attached USB drive for my music storage. This is recommended.

Not really. I have a fairly beefy “server” I built a few years back. I can “tune” the VM, in software, to use only the resources ROCK needs from that server based on my usage / library. Overtime, if needed, I can also increase those resources if my usage / library changes. By resources I mean CPU cores and memory. A true hypervisor isn’t a general purpose OS. Yes, you can run virtualization on top of, say, an Ubuntu install but running a true, purpose built, hypervisor is a bit different. Hypervisors are very thin. All modern Intel processors (Xeon for sure) support direct hardware access to the VMs. The additional demand the hypervisor is putting on the system is really just the management interface. VMs can be built in a way the hypervisor itself isn’t in the path of the VM while the VM is running.

Anyway… I like VMs and I like running ROCK in a VM. I started with Roon some 4 years ago and have spent a total sum of $0 to run the Core (as ROCK). It works for me.

Not yet. ROCK is fairly bare bones. It needs network, RAM, CPU, and storage. As long as Roon keeps supporting the generic network cards and storage interfaces we’ll be good.

It is optimized for this in a few ways. The biggest issue, I see, with running ROCK on generic hardware is thermals. If it’s not a NuC then ROCK may not know what to do with temps and fans and CPU throttling. Running in a VM on a Hypervisor allows the Hypervisor to manage those things.

Another bit of unsolicited advice… If you’re already running a Hypervisor and have familiarity with such things then ROCK in a VM should be perfect. If this is your first dive into Hypervisors I wouldn’t make ROCK your first VM.


No matter how “beefy” a server is or how transparent the hypervisor is, running an app in a VM will always use more resources than running that same app directly on the physical host. All the CPU and memory the VM uses translate into CPU and memory usage on the host, plus some overhead. There are two reasons one might want to run core in a VM:

  1. Roon core doesn’t run on the host OS, or
  2. You want to limit the amount of memory and/or CPU the core is using.

#1 doesn’t seem to be the case, and unless core hogs host resources, #2 doesn’t seem desirable to me.

1 Like

I was talking about running ROCK in VM on a general-purpose OS on a NUC, because the OP had based it on “ROCK monopolizes the machine that I’d installed on”. Obviously, it’s a completely different thing to run it on a beefy server in a VM, but then the “ROCK monopolizes the machine” would never come into play to begin with.

On a beefier machine, I still think the VM overhead is wasted compared to running Roon Server directly, but maybe convenience trumps this.


I think the point of view is wrong: If you have an already running server with active VMs it makes totally sense to bring ROCK there :wink: ROCK doesn’t need that CPU power (which is anyhow adjustable in the hypervisor) as well as memory is not really a problem. So in this case the usage of a dedicated NUC is waste …


My point is that it’s a waste to run ROCK in a VM when you can run Roon core directly on the VM host. It’s not about using a dedicated physical NUC.

This prevents you from constraining the resources ROCK uses and it will use all the memory it can find.

I thought the idea is to “optimize” Roon, not constrain it. Anyway, I think Roon uses as much memory as it needs, depending on the size of the library and DSP. In my case, all Roon processes use about 800MB combined while playing in one zone. The machine has 8GB of RAM and total memory utilization is about 60%.

I for myself run ROCK within Proxmox and couldn’t be happier with it.
There is for all ROCK installations the caveat that you need an physical keyboard passed through the VM to be able to press 1 and enter once, after that they keyboard can be removed again.
Also since ROCK 1.0 build 254 you can install it with UEFI and some virtual network adapter other then Intel E1000.
If ROCK would need more ressources like cores or RAM i just can shut down the VM give it more and start it again, so there is no real ressource overhead with virtualisation, except the host using ZFS in my case, which reserves some RAM.
I also virtualized HQPlayer Embedded within the same host, which is streaming via network to an RoPieee XL.
If someone tells me i would need to run it bare metal to have optimal performance, i would just show them the CPU and RAM usage graphs of my VMs with Roon DSP and HQPlayer DSD512 upsampling active, while barely getting over 10-15% cpu usage while having only 4 cores assigned each.

My personal advice would be, virtualize it and probably have also enough ressources left, to host other services on the same machine!


Hi Forsaked, it would be really great to read how you managed to get ROCK running on Proxmox; even after your help suggesting to change the boot order the installation still stalls after selecting the USB drive. And altough it works perfectly well on a 22.04 VM I’d rather have a dedicated ROCK VM without the Ubuntu server overhead. Thanks!