Forum Discussion

Martin_Vlasko

Altocumulus

Dec 02, 2019

F5 VE on Proxmox

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

Proxmox:

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

F5 VE:

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

According to https://clouddocs.f5.com/cloud/public/v1/matrix.html, Debian should be supported distribution.

Following instructions on https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ve-setup-linux-kvm-13-0-0/1.html.

Creating new VM in Proxmox:

OS: guest OS Linux, 2.6 Kernel, no media for OS
Hard Disk: bus SCSI, VirtIO SCSI, NFS storage, QEMU format (qcow2), 100GB
CPU: 4 sockets
Memory: 8GB
Network: bridge vmbr0 openvswitch with appropriate vlan tag, VirtIO, no firewall
VM is created
replacing just created qcow2 on remote storage with downloaded F5 qcow2 image.
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.)

thx.

3 Replies

ecce
Cirrostratus
Feb 18, 2020
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:

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
Detach the disk from the VM and delete it.
Download the qcow2 image from F5
SCP it to Proxmox
unzip it. apt install unzip if needed.
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
Doubleclick on the now unused disk image in the VM hardware settings. Add it.
Boot VM. Bring up a console. It shows nothing of the boot process except the GRUB menu, but the login prompt eventually comes.
Login. Set root password.
mcpd reboots in a loop. Kill it: tmsh stop sys service mcpd
mkdir /shared/.snapshots_d
tmsh start sys service mcpd
Wait a while. Then run config and set mgmt IP.
Login to GUI. You are forced to update GUI password.
Go though license activation procedure.
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.
Leave it there and bring up a console.
Active license via CLI: tmsh install sys license registration-key <regkey>
Magic happens
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 BIGIP-13.1.3-0.0.6.ALL.qcow2.zip, then jumped to BIGIP-14.1.2.3-0.0.5 and then BIGIP-15.1.0.1-0.0.4 and they all worked just fine.
Luuk_Dries
Employee
Nov 18, 2020

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-7.1.0.2.0.0.21.qcow2 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
lnxgeek
MVP
Jan 18, 2024
Just a heads up if you plan to upgrade to Proxmox 8.1:

https://forum.proxmox.com/threads/latest-proxmox-update-breaks-working-f5-big-ips-stops-licensing-new-big-ips.137782/

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).