Forum Discussion

Martin_Vlasko's avatar
Icon for Altocumulus rankAltocumulus
Dec 02, 2019

F5 VE on Proxmox

Has anybody been successful running F5 BIG-IP VE on Proxmox?



  • Operating System: Debian GNU/Linux 10 (buster)
  • Kernel: Linux 5.0.18-1-pve
  • Architecture: x86-64


F5 VE:

  • virtual edition from
  • I tried both qcow2 and .ova(scsi)
  • licensing with trial license obtained from F5
  • single NIC mode



According to, Debian should be supported distribution.

Following instructions on


Creating new VM in Proxmox:

  1. OS: guest OS Linux, 2.6 Kernel, no media for OS
  2. Hard Disk: bus SCSI, VirtIO SCSI, NFS storage, QEMU format (qcow2), 100GB
  3. CPU: 4 sockets
  4. Memory: 8GB
  5. Network: bridge vmbr0 openvswitch with appropriate vlan tag, VirtIO, no firewall
  6. VM is created
  7. replacing just created qcow2 on remote storage with downloaded F5 qcow2 image.
  8. VM is started


I am able to get prompt in Proxmox console, log in with default root account.


But then mcpd keeps on restarting - constantly every few seconds.

Logs show errors caused by permission errors.

For some reason F5 is complaining that it cannot create "/shared/.snapshots_d/" because of permission problem.

However permissions of "/shared" are OK.

When I create .snapshots_d folder manually as root, mcpd no longer restarts, no more console errors...


I run config utility to setup management IP/mask/gateway.

As expected in single NIC mode, https port is automatically configured to 8443.

I am able to reach GUI configuration utility and login as admin.

Up until now everything looks fine.


When trying to license the VM, I am able to generate dossier, also receive the generated license file from F5.

But when I apply the license to the VM and click next, it acts as if nothing has happened.

GUI keeps showing VE is not yet licensed.

LTM logs says: err mcpd: License file open fails, Permission denied.

"/config/bigip.license" has read permission for all and write for tomcat.

Those are expected permissions for the license file.


Funny though, content of /config/bigip.license is now actually populated with the correct new license.

But "Registration Key" in "tmsh show sys hardware" is empty.


There are several other file system related warnings or errors in logs.. so I suspect that the whole issue is with how F5 VE is accessing file system on Proxmox. But I don't know what to check or fix further.


Is it even possible to run F5 VE on Proxmox? (although F5 clearly states it should be.)



3 Replies

  • ecce's avatar
    Icon for Cirrostratus rankCirrostratus

    Yes, I got it working, I had the exact same problem as you. I used a converted vmdk image, but that behaves exactly like the qcow2 image so I dont think that has anything to do with it. In short, I activated the license via CLI instead of GUI. Here is the complete procedure:


    1. Create a VM, with any disk. It will be deleted later anyway. I used 16 Gb RAM, 2 sockets 4 cores CPU, Machine: i440fx, SCSI-controller: VirtIO SCSI, NICs: VirtIO
    2. Detach the disk from the VM and delete it.
    3. Download the qcow2 image from F5
    4. SCP it to Proxmox
    5. unzip it. apt install unzip if needed.
    6. Attach the qcow2 file to the VM, and move it to designated storage: qm importdisk <vm-id> BIGIP15.1.x.y.z.qcow2 VM-storage
    7. Doubleclick on the now unused disk image in the VM hardware settings. Add it.
    8. Boot VM. Bring up a console. It shows nothing of the boot process except the GRUB menu, but the login prompt eventually comes.
    9. Login. Set root password.
    10. mcpd reboots in a loop. Kill it: tmsh stop sys service mcpd
    11. mkdir /shared/.snapshots_d
    12. tmsh start sys service mcpd
    13. Wait a while. Then run config and set mgmt IP.
    14. Login to GUI. You are forced to update GUI password.
    15. Go though license activation procedure.
    16. Dont know if it matters, but I chose offline activation. It "succeded" but when provisioning modules in the next step AVR is the only licensed module.
    17. Leave it there and bring up a console.
    18. Active license via CLI: tmsh install sys license registration-key <regkey>
    19. Magic happens
    20. Complete the setup in the GUI.


    I used BIGIP 15.1 on Proxmox 6.1. Maybe license activation in the CLI right away works, but the above procedure is exactly how I did it. As far as I can tell, F5 states that VE should run under KVM, this seems to be a Proxmox-specific thing. I have run multiple BIGIP under KVM earlier (like GNS3 server) and never had this issues.


    I have not run my unit very long so I have no idea how it will behave over time... but hopefully this helps someone.



    UPDATE: The VM behaved weird in several ways. It seems fine in the GUI but there are issues. sshd would not start via systemd, and several services failed to start, big3d rebooted in a loop after a while. Some of it seems related to SELinux, sshd did start when SELinux was set to permissive ("setenforce 0"). sshd also started if you started it manually. Other services like network and f5-label did however not start. Never found out why. However a better workaround for me was booting 13.1, which start without issues. Then upgrade to the version you want. I got no errors at all. The exact version I used was, then jumped to BIGIP- and then BIGIP- and they all worked just fine.


    Thanks ECCE, works really well installing Big-IP V15.1 - from scratch too !

    Struggled a bit with BigIQ, but finally made it work:


    Proxmox 6.2-4 , BigIQ 7.1::, (It helps if you've installed Big-IP first, following ECCE's manual above ..)


    Import the QCOW2 image in Proxmox CLI ( I’m importing it to VM 107) :"qm importdisk 107 BIG-IQ- local-lvm --format qcow2"

    Go into the GUI and observe your virtual machine: you’ll see the newly imported disk

    Now, here’s the trick; don’t just add the disk, but first change it from SCSI into SATA

    Once you changed “Bus/Device” into “sata”, hit the blue “add” button

    Now’ your disk is added to the virtual machine, but it won’t boot yet ..

    Go into the virtual machine “options” menu on the left, and edit the boot order. You will see it’s set to boot from scsi, but there is no scsi disk, so the border around “boot device 1” is red.

    Change it into ‘sata0’

    Now hit start. It should boot

  • Just a heads up if you plan to upgrade to Proxmox 8.1:

    Qemu changed the default SMBIOS version to 3.0 with 64 Bit, which breaks all Juniper products as they set the system information in SMBIOS at boot.

    A workaround is to set "args: -machine q35,smbios-entry-point-type=32" in the config file, then the VM boots again without problems (as the SMBIOS runs in 32 Bit mode).