Last Modified: Dec 18, 2025
Affected Product(s):
BIG-IP AFM, APM, ASM, AVR, DNS, GTM, Install/Upgrade, LTM, PEM, SSLO, TMOS
Known Affected Versions:
17.5.0, 17.5.1, 17.5.1.2, 17.5.1.3, 21.0.0
Opened: Dec 12, 2025 Severity: 2-Critical
After a software upgrade to one of the affected versions, the value of /proc/sys/vm/min_free_kbytes might too big on Hyper-V and Azure VEs with multiple cores and multiple NICs. This can prevent the Virtual Edition from booting into the new software volume installed with one of the affected versions.
After an upgrade to one of the affected versions, the BIG-IP VE boot process hangs, or the VE takes hours to boot into the new volume and is so slow to result unusable.
BIG-IP VE running on Hyper-V hypervisor or on Azure with: - more than 4 cores and more than 4 NICs configured - 16GB of RAM or less allocated Attempt to upgrade to one of the affected versions.
There are two possible workarounds: (1) Before booting into the new volume, shutdown the VE and increase the total allocated RAM to 32GB. (2) - Install the new software volume. - Take note of the current value <KBYTES> of /proc/sys/vm/min_free_kbyte : # cat /proc/sys/vm/min_free_kbyte - Before rebooting into the new software volume, mount the "vg--db--vda-set.<N>.root" disk volume on a temporary directory, where <N> is the number of the new volume after the dot. E.G.: if the new volume is "HD1.2", then <N> is 2. # mkdir /mnt/temp # mount /dev/mapper/vg--db--vda-set.<N>.root /mnt/temp/ - Edit the /etc/rc.sysinit.f5 file: # vi /mnt/temp/etc/rc.sysinit.f5 - Replace this line: echo $VADC_MIN_FREE_KB > /proc/sys/vm/min_free_kbytes with this line (use the <KBYTES> value noted before): echo <KBYTES> > /proc/sys/vm/min_free_kbytes - Unmount the disk volume: # umount /mnt/temp/ - Reboot into the new software volume
None