ROCK on VIRTUALBOX virtual machine

Core Machine (Operating system/System info/Roon build number)

Host machine is desktop with WINDOWS 10 PRO with Intel i9 and 32Go of RAM

ROCK guest is as follow:

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Using bridge network invirtual machine

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Chromecast ULTRA and AUDIO

Description Of Issue

I was previously running the Roon Core on my i9 based desktop on Windows 10.

I read about @Lorrain_VIVRAY testing ROCK on vitual machine using VMWARE PRO and I thought I would give it a try because I believe ROON is developping better functionality and stability for their own hardware set up.

I tried first with HyperV but there was an issue with USB passthrough (using PLOP boot manager to install ROCK from usb stick); then I tried VMWARE PLAYER free but it start by default on SCSI hard drive which is not compatible with ROCK; I could install on second virtual SATA HDD but could’nt find how to change easely the boot sequence to boot from the SATA HDD instead; so finally I decided to use VIRTUALBOX; there I could install completly ROCK, but I could not access DATA from the Windows HOST explorer to install the ffmpeg codecs; so I created an Unbuntu virtual machine from which finally I could access the ROCK data folders.

Whatever ffmpeg file I copied in the Codecs folder and reboot the ROCK, the web GUI was still showing in red “missing codecs”.

FLAC files played fine but MP3 not.

When trying to access from the Windows 10 Host I tried ping ROCK and enabled SMB share V1 without success to access \ROCK\

Since, running ROCK this way is not officially supported, I moved your question to the Tinkering section where someone might be able to answer.

nope. No SQ difference at all. In fact, having run Roon many different ways, I prefer and use Windows 10 Enterprise LTSC as my OS of choice.

Hi @mentalfloss, did you try ROCK as virtual machine directly?

Proxmox looks attractive but I would only move if I could implement ROCK directly, not Roon Core in Linux.

I was able to make it run in Virtualbox and copy the ffmpeg file in the codecs data folder, but the instance is still stating missing codecs. Otherwise working flawlessly with flac and streaming Qobuz. I still have some mp3 in my library so would be willing to resolve the issue.

I get the feeling that Roon is making ROCK very efficient because of Nucleus and I am not sure how much this is reflected in Roon Core for Linux…

I had open a ticket in Support but it was moved to Tinkering by a moderator, because this way of applying ROCK is not supported by ROON. Here it is:

Dear all,

I have resolved my issue and now my VM machine is fully functional with Codecs working.

I am copying the ffmpeg file from a Linux VM to ROCK VM and previously was connected as anonymous to the SMB share. Althougth the file was looking like copied, ROCK did not took it in account.

This time I connected to the SMB ROCK share using my Windows Host account details. I have copied the ffmpeg file and this time ROCK took it in account and I am all OK with all codecs installed!

No, I chose to run Roon core on Ubuntu 18.04 server in a Linux container as it shares resources in the host so is lighter on resources in the host vs running a full VM (and I have a bunch of other containers). But I’m keen to have a tinker with ROCK. I might try it in Proxmox and report back.

EDIT: Actually, now I look at it, installing ROCK this way sounds like a distinctly bad idea. It is very much optimised around installation on an Intel NUC, and trying to make it work on a VM seems like a short road to a whole lot of unnecessary pain. The standard Core works perfectly well on Linux in a container or VM.

1 Like

Hi @mentalfloss,

Thanks for this. Just to confirm that ROCK is working perfectly well in Virtualbox VM in my system. For instance I made the latest OS upgrade without any problem.

The ROCK VM should be even more optimized in ressources than Linux + Roon Core VM, as I understand it. My ROCK VM is using the host network card in bridge mode. The library drive (4To) is a shared drive from the host. The same for back up locations.

I did set up another virtual drive attached to the ROCK in case I would want using the ripper feature but for the moment I don’t have time for this to test and would probably stick using DBPoweramp in the Host desktop anyway.

Cool. But I’m not sure what you gain doing that way as it will require a full VM rather than a container. A full VM has to exclusively own its resources e.g. RAM. And I’ve learned the hard way that using software not as designed punishes you later.

Standard Roon core on a basic Ubuntu server (no GUI) is light on resources and performs perfectly well. And it won’t make a jot of difference to sound quality. So it seems to me that installing ROCK on an unsupported platform is just asking for pain for no gain… that said, I fully appreciate the desire to tinker… :slight_smile:

Also, now I think about it I’m not sure running the standard core on a hypervisor is supported either! So who am I to talk. :slight_smile: But I still think it is less likely to cause you heartache installing the standard core (which is designed for a generic linux platform) on a virtual machine than installing ROCK on a VM which is specifically tailored to an Intel NUC.

I’ve been running ROCK on ESXi (free) for a year without issue. I have a 1U server with 32GB and plenty of cores for all my VMs. Containers are great but would add significant complexity to my environment (as example, I use the virtual network layer in ESXi to attach virtual NICs to VLANs for isolation). I don’t mind dedicating resources to ROCK instead of “sharing”. That’s obviously a different philosophy but it works for me. The other nice thing is that I never worry about upgrades within the ROCK path. There is no concept of a “node” which needs to be maintained. ROCK takes care of itself. If I was managing a ton of microservices I’d certainly transition to a container architecture but honestly I just don’t have that much to maintain at home. In my current set-up I can upgrade and reboot every “Linux install” on my server and ROCK is never interrupted. That cannot be done with containers unless you’ve got multiple nodes and the containers can be fronted by a LB (which ROON cannot). While I love the enthusiasm I see for loading Roon as a container… it just won’t work in all environments. For that reason loading ROCK in a VM makes a lot more sense if you’re not wanting to drop another bit of hardware into the environment. And, on top of all that, the money I saved by not buying a NuC went directly into a lifetime sub and I’ve got 99% of the NuC benefit (with faster cores).

One other bit I wanted to mention. “Sharing” of resource in ROCK I don’t recommend. I don’t have a routine for listening nor do I always listen to the same zones. Some of my zones I use upsampling. Some of files need DSD (multi-channel) -> PCM (2-ch) conversion. Additionally, there are others in my house who use Roon. Without routine this means I may be listening at the same time I’m hammering another VM or multiple VMs. I get consistent, predictable, performance from ROCK regardless of what my other VMs are doing as I’ve dedicated resources to ROCK. I can drive all my other VMs into the ground and I never hear from a family member that “somethings wrong with Roon”. That’s a priority for me and has worked consistently over the year. Again, a different philosophy to how to run Core.

Anywhoo… just wanted to throw an alternative “why” out there.

Great post. Interesting that it is so stable - clearly ROCK is not that fussy about not being on a NUC which was my main concern.

I take your point re not having Roon impacted by other services. That hasn’t been an issue I’ve struck. The only likely culprit in my environment would be the container running Plex if it were busy transcoding something - but in our house it is unheard of that Plex and Roon would be used concurrently.

Yes I do have 2 nodes in my environment so can avoid downtime - but TBH I don’t bother migrating Roon or other services when doing maintainance unless it’s something major. I can put up with the occasional complaint from my users (one of whom is 10, the other 6 :slight_smile:)

ROCK on Proxmox is still something I might have a play with. But currently it’s mainly a case of if it ain’t broke don’t fix it.