Proposal about Proxmox VE Compatibility for cnMaestro On-Premise

[micampo]

---

Proposal about Proxmox VE Compatibility for cnMaestro On-Premise

Context

Cambium Networks currently distributes cnMaestro On-Premise as an .OVA image, which works correctly on VirtualBox and VMware environments.
However, in Proxmox VE (KVM/QEMU) —a widely used platform for enterprise and ISP deployments— the .OVA file presents compatibility, stability, and startup issues that prevent cnMaestro from running reliably.

---

Tests Performed and Results

1. Conversion from a working VirtualBox VM

   • A stable cnMaestro installation running under VirtualBox was exported, and its .vdi disk was converted to .qcow2 for import into Proxmox.

   • Although the conversion was successful and the virtual machine booted, the web interface failed to start, showing the message:

     Service Temporarily Unavailable!
     
     

2. Manual extraction and setup from the .OVA file

   • Following the steps documented in the Cambium Community (reference guide), we:

     • Extracted the .ova package

     • Converted the .vmdk disk to .qcow2

     • Created a new Proxmox VM (SeaBIOS, VirtIO adapters, bridged network)

     • Restored an existing cnMaestro backup

   • The VM successfully booted once or twice and briefly allowed web access, but then failed again with the same:

     Service Temporarily Unavailable!
     
     

   • Logs indicated that internal services stopped responding properly after reboot.

3. Nested VirtualBox inside Proxmox

   • As a last resort, a Linux VM was created in Proxmox, and VirtualBox was installed inside it to run the original cnMaestro .OVA image in a nested virtualization environment.

   • The outcome was the same: the cnMaestro web portal remained inaccessible, displaying Service Temporarily Unavailable! after a short period.

---

Conclusion

After several deployment attempts, it is confirmed that the current .OVA image is not stable or fully compatible with Proxmox VE (KVM/QEMU), even after advanced conversion and configuration steps.

---

Proposal for Cambium Networks

1. Publish an official Proxmox/KVM-compatible image, provided in a native format such as:

   • .qcow2 (QEMU/KVM standard disk format), or

   • .raw (generic disk image format)

2. Ensure the image includes:

   • Full VirtIO driver support (for network and disk)

   • Compatibility with both SeaBIOS and UEFI boot modes

   • A generic kernel optimized for KVM/QEMU environments

   • Flexible network configuration (bridge/NAT friendly)

3. Advantages of this approach:

   • Enables direct installation on Proxmox VE without conversions

   • Improves system stability and I/O performance

   • Reduces deployment complexity and risk of service failure

   • Expands cnMaestro’s compatibility with one of the most widely adopted virtualization platforms among ISPs and system administrators

---

Request

Given that Proxmox VE has become a leading virtualization solution in many production environments, we respectfully request that Cambium Networks release an official cnMaestro On-Premise image in .qcow2 or .raw format for native compatibility with KVM-based hypervisors.

Is there an estimated timeline or roadmap for publishing such an image?

thank you

[Hamish]

Hi @micampo - This looks like it might be an AVX issue - did you confirm you have support in the VM? If you run this on the proxmox host we can check for support:
cat /proc/cpuinfo | grep -q avx && echo "AVX support detected" || echo "no AVX support in CPU, not installable here"
You shouldnt need to use a virtualbox step at all - were you not able to run qm importovf.. from the files extracted from the .ova? If you share the errors from that too we can dig a bit.

[micampo]

@Hamish

cat /proc/cpuinfo | grep -q avx && echo “AVX support detected” || echo “no AVX support in CPU, not installable here”

Hello

1. As I mentioned in the text, one of the tests performed was decompressing the contents of the .ova file and then importing the files into PROMOX - this was unsuccessful.

2. Regarding this command - cat /proc/cpuinfo | grep -q avx && echo “AVX support detected” || echo “no AVX support in CPU, not installable here” - as I mentioned in the text - a link was used for the migration process that mentions this same command, but the process didn’t work either. (Installing cnMaestro on Proxmox)

3. I’ve already deleted all the virtual machines. Currently, I have a Linux virtual machine in PROMOX, and on top of that Linux, I have VirtualBox, and on top of that VirtualBox, I have cnMaestro… it’s the only survivor that I haven’t deleted yet (the others have already been removed). If it’s helpful to run any command on it, please let me know… because cnMaestro isn’t working there either.

[Hamish]

Hi @micampo lets start with exact errors, we can’t really do much with “this was unsuccessful”. Lets start at #1. You attempted to decompress the .ova file. What exact command did you run, and what was the exact output of that command that showed you it was unsuccessful?

PS You seem to be using something like chatgpt for this. I would try to do this without LLM and just follow the steps: this part is hallucination, and does not exist in the guide you referenced:
Manual extraction and setup from the .OVA file

• …

  • Converted the .vmdk disk to .qcow2

  • …

[micampo]

Okay, I understand. I’ll try to explain it better:

Points 1 and 2 refer to following the entire process exactly as explained in the link:

Installing cnMaestro on Proxmox

While not officially supported, cnMaestro on premises runs fine on the Qemu/KVM-based Proxmox system. Here’s how to get it running: Import cnmaestro OVA into proxmox NOTE: you can also just untar the ova file locally and upload the vmdk files, then attach these to a new vm. Using the importovf method is a bit quicker, but the end result is the same. scp or use another method to get the ova file available on the proxmox server Untar the ova file downloaded from https://support.cambiumnetworks.…

Everything was done, the .ovf files were imported… the virtual machine starts in all the scenarios explained, but cnMaestro doesn’t work; it doesn’t load. The message:

Service Temporarily Unavailable!

That’s what I mean.

Chatgpt was used for support, so I don’t see anything wrong with using it correctly.

What I mean by converting the .vdi files to qcow2 is that—on my own initiative (since I wasn’t getting positive results). I took the initiative to convert the .vdi files to .qcow2 to try and get cnMaestro working. I know there’s no guide that mentions this, but I did it on my own initiative, and it didn’t work either. .vdi files have worked for me in other processes on other machines. I thought it might work, but it didn’t, and again, it was my own initiative. But I also get the message:

Service Temporarily Unavailable!

Is that clearer now?

I used chatgpt to help me write the explanation of all the processes I’ve tried. As indicated, I’ve tried three different ways, and none of them work with cnMaestro. In all the processes, the virtual machines start, but cnMaestro doesn’t load.

[Hamish]

No problem, it can be helpful sometimes, just watch out for when it invents things! So lets be clear on what you’re trying to run. From your comment:

Currently, I have a Linux virtual machine in PROMOX, and on top of that Linux, I have VirtualBox, and on top of that VirtualBox, I have cnMaestro

• Proxmox
  • Linux with VirtualBox
    • cnMaestro

Is there something you need in virtualbox? It would be a lot more reliable without all the nested stuff and just installing on Proxmox.

Lets start at the very basics

@micampo

Regarding this command - cat /proc/cpuinfo | grep -q avx && echo “AVX support detected” || echo “no AVX support in CPU, not installable here” - as I mentioned in the text - a link was used for the migration process that mentions this same command, but the process didn’t work either. (Installing cnMaestro on Proxmox)

We agree that the link mentions this command, but you say the process doesnt work - lets get to the exact part that it breaks. What is the result of running this command on proxmox cli?

cat /proc/cpuinfo | grep -q avx && echo "AVX support detected" || echo "no AVX support in CPU, not installable here"

We cannot carry on without AVX support in the CPU, so lets verify this is present first. The symptoms of starting without AVX support is seeing a web interface that says “Service Temporarily Unavailable!”

Alternatively, you could open a support ticket and send in a techdump (do not post those in any public forum, they contain sensitive data)

[micampo]

Hello

Is there something you need in virtualbox? It would be a lot more reliable without all the nested stuff and just installing on Proxmox.

R// What I’ve tried to explain is that I’ve created several scenarios, one of which involved creating a Linux virtual machine in Proxmox, installing VirtualBox on that virtual machine, and then running cnMaestro within that VirtualBox environment. This scenario (like all the others) loads cnMaestro, but the webadmin doesn’t load; the same message keeps appearing.

“Service temporarily unavailable!”

What I’d like you to understand is that I created all three scenarios on my own initiative. You should try installing them yourself to verify that they work. For me, it was a failure.

What is the result of running this command on proxmox cli?

R// I followed the steps in the link exactly… the command output is this:

cat /proc/cpuinfo | grep -q avx && echo “AVX support detected” || echo “no AVX support in CPU, not installable here”
AVX support detected

But after creating the PROMOX machine and importing the .ovf file (exactly as explained in the link), the same thing happens… cnMaestro starts but the webadmin doesn’t load (the same error appears):

“Service temporarily unavailable!”

Alternatively, you could open a support ticket and send in a techdump (do not post those in any public forum, they contain sensitive data)

R// We’ve decided to move to the cloud until Cambium has a dedicated image for the Proxmox hypervisor.

Thanks anyway.

[agryph]

@Hamish @micampo

Service Temporarily Unavailable!

You may intermittently experience the “Service Temporarily Unavailable!” error message when running cnMaestro on a non-VMware hypervisor. This is due to how Cambium has the disk mount points configured in fstab; the stock mount points utilize device names (such as /dev/sda1) which expect the virtual disks to be presented in a particular order by the hypervisor. With the stock bindings on Proxmox or Hyper-V, the initial boot may work- but after a reboot if the hypervisor switches the virtual drive order you will run into this exact error.

To resolve the issue, the stock mount point bindings (on BOTH cnMaestro OS partitions) should instead be pointed to a UUID or file system label.

I won’t go into too much detail here, but in short you will need to enumerate the UUIDs for both drives (such as via blkid or lsblk), then via your favorite terminal editor such as nano, update the mount points for /boot and /mnt/data to link to their drive’s respective UUID.

@Hamish - ideally Cambium would update their stock cnMaestro image to use a more resilient mount point system such as detailed above, especially as more and more companies switch away from VMware to other hypervisor platforms such as Proxmox and Hyper-V.

[micampo]

I understood perfectly… UUIDs are always more effective in fstab… I’ll try to correct it

[micampo]

step 1

root@cnmaestro:~# more /etc/fstab
UUID=abcdfg12-4321-4321-b123-898989898989 /boot           ext4    defaults        0       2
/dev/mapper/system-os1 /               ext4    noatime,errors=panic 0       1
/dev/mapper/system-os2 /mnt/os2        ext4    noatime         0       2
/dev/mapper/system-tmp /tmp            ext4    noatime,nodev,nosuid 0       2
/dev/mapper/system-log /var/log        ext4    noatime         0       2
/dev/mapper/system-swap none            swap    sw              0       0
/dev/sdb1 /mnt/data          ext4   noatime,errors=panic,nofail    0    2

It seems /boot has its UUID, but /mnt/data doesn’t… that could be the problem.

step 2


root@cnmaestro:~# blkid
/dev/sdb1: UUID="abcdfg12-1234-1234-b123-45454545454545" TYPE="ext4" PARTUUID="abcdfg12-12"
/dev/sda1: UUID="abcdfg12-4321-4321-b123-89898989898989" TYPE="ext4" PARTUUID="abcdfg12-43"
/dev/sda2: UUID="df34ge537-5678-5678-b123-454-545-4545-4545" TYPE="LVM2_member" PARTUUID="df34ge537-56"

step 3

root@cnmaestro:~# nano /etc/fstab
root@cnmaestro:~# more /etc/fstab
UUID=abcdfg12-4321-4321-b123-89898989898989 /boot           ext4    defaults        0       2
/dev/mapper/system-os1 /               ext4    noatime,errors=panic 0       1
/dev/mapper/system-os2 /mnt/os2        ext4    noatime         0       2
/dev/mapper/system-tmp /tmp            ext4    noatime,nodev,nosuid 0       2
/dev/mapper/system-log /var/log        ext4    noatime         0       2
/dev/mapper/system-swap none            swap    sw              0       0
#/dev/sdb1 /mnt/data          ext4   noatime,errors=panic,nofail    0    2 (It’s not deleted, it’s commented on)
UUID=abcdfg12-1234-1234-b123-45454545454545 /mnt/data          ext4   noatime,errors=panic,nofail    0    2

That’s how it turned out after the change

[agryph]

Exactly!

/mnt/data is set to the device name /dev/sdb1 - but if the hypervisor flips the order the drives are presented (which can and does sporadically happen on reboot), /mnt/data will reference the wrong virtual drive; so need to ensure that /mnt/data is instead set to the UUID of the secondary virtual drive (which you will need to enumerate). And since cnMaestro has two OS partitions, need to ensure you update fstab on BOTH of the OS partitions in case of failover/update.

[micampo]

Thank you so much for your help.

I’ve already modified /etc/fstab and assigned UUIDs to all mount points.

I’ve performed several reboots, and so far cnMaestro onPremise has started and the webadmin has loaded normally.

Thanks again.

[Hamish]

thanks @agryph - ill feed this back to dev, its a sensible idea even on its own.

[agryph]

@micampo you are most welcome, glad it worked out.

@hamish much appreciated, thank you for listening and relaying!

[Hamish]

@micampo

modified /etc/fstab and assigned UUIDs

This is very likely to break things. We do not recommend changing things in the appliance, as other parts will make assumptions about them staying as shipped.

[micampo]

Only the UUID in /etc/fstab, which is part of the partition mount point, has been modified… the partition mount points still have the same names in the operating system.

What does your comment refer to?