30-Dec-201718:30 - last edited on 05-Jun-202322:05 by JimmyPackets
Hello,
File downloaded: BIGIP-13.1.0.1.0.0.8.LTM.qcow2
Notes: Using a lab license with no support eligibility. UUID tampering seems to be isolated to BigIP VE on KVM.
What happens:
BigIP software does not honor UUID parameter as set in QEMU/KVM xml configuration. There's value mismatch provided by different tools of the underlying RHEL. One tool shows correct UUID while the other provides a tampered result. Due to this, license cannot be activated.
dmidecode -s system-uuid
(Output provides correct UUID)
cat /sys/class/dmi/id/product_uuid
(First 12 digits of UUID are tampered, the rest is correct)
Expected: they should be 1 to 1 match. It appears BigIP system relies on /sys/class/dmi/id/product_uuid to validate license rather than dmidecode's system-uuid which has the correct value.
Troubleshooting done:
My first trought was it could be a QEMU/KVM or RHEL problem but then I tested blank RHEL 5.11 Guest installation on same QEMU/KVM Host, and it correctly fetched UUID to both locations. Then I installed BigIP 13.1.0.1 on same host but at a Windows 10 boot location. Tested as a Guest of Hyper-V and VMware Workstation. UUID in /sys/class/dmi/id/product_uuid and dmidecode was correct, both matched one another. Encountered no licensing issues on HyperV nor VMware Workstation.
I'm not sure if it's a bug or a feature to prevent license abuse. Moving VE license from one hypervisor to other is definitely possible on same hardware without any help from F5 rep. But what if license is moved to a different boot location where not only hypervisor but also operating system is different? At least in my case, I encountered problems but would still like to find a way to put those licenses on QEMU/KVM.
