If you have followed the setup procedures as described in this guide, BIG-IP VE should be working correctly with the hypervisor.
However, because BIG-IP VE emulates BIG-IP hardware running in a virtual
environment, you might encounter some issues as you try new configurations for
BIG-IP VE that are outside the scope of this setup guide, or unsupported in BIG-IP
VE with certain hypervisor environments. Use this troubleshooting information to
solve problems and address limitations that you might encounter with BIG-IP
- XenCenter OVF wizard's Run Operating System Fixups option blocks
appliance import (ID 351367)
- When importing the OVA into XenCenter, make sure
the Run Operating System Fixups check box is
- XenServer reservations should be set (ID 351199)
- When importing an OVA into XenServer, CPU priority is not set. F5
Networks recommends setting a higher priority for the virtual machine. To do this, using XenCenter, click the
General tab for the virtual machine, click
Properties, and under the CPU
and Memory tab, move the scheduling priority to the
- XenServer deployments are not allocated on demand
- BIG-IP system deployments will automatically consume 40 GB of space on
Thick configured storage repositories. Utilize Thin deployment
strategies on the Storage Repository to make use of allocate on-demand
disk allocation strategies.
- XenServer allocates less RAM than configured (ID 353416)
- XenServer virtual machine memory allocations are inclusive of the
emulated hardware. A slight difference between memory allocated and
memory presented to the virtual machine can be noticed. BIG-IP
software has been written to accommodate this difference with no
adverse effects on traffic.
- Configuration of additional interfaces (CR 137616; CR 137621)
When a BIG-IP VE system has been configured with more than five
interfaces (one management interface and more than four TMM
interfaces), the interface numbering might appear out of order.
To view the actual portgroup interface mapping, compare the MAC
addresses of the interfaces displayed in the BIG-IP
Configuration utility to those displayed in the hypervisor
If you change the number of virtual interfaces on the BIG-IP VE
system after a binary MCPD database has been created, the system
does not detect the change when subsequently rebooted. To ensure
that the system properly detects the new or removed interfaces,
type the command rm /var/db/mcpd* at the
BIG-IP VE command prompt, and reboot the system.
- Virtual network interface status is wrong (CR 126854-1)
- The BIG-IP VE system reports the status of host-only network interfaces
as UNINITIALIZED, even though the interface is functioning
- Auto-licensing and the default management route (CR 133194)
- If you have not defined a default route to the management port, the
default interface 1.1 is used, which does not work.
To prevent this from occurring, verify that you have defined a default
route for the management port before attempting to activate a
- BIG-IP licensing and User Configuration Sets (CR 138498)
- When you import a User Configuration Set (UCS) from another BIG-IP
system or BIG-IP VE system, the system overwrites the local license
with the license contained in the UCS. To work around this issue, you
can re-license the local system after importing the UCS by accessing a
backup copy of the license file, located in
/config/bigip.license.bak. Also, when
importing a UCS, ensure that the host names of the two systems differ.
When the host names differ, the system correctly imports only the
configuration data that is common to both the originating platform and
the target platform. If the host names match, the system attempts to
import all of the UCS configuration data, which can cause the import
process to fail.
- Use of SNMP OID for RMON tables (CR 137905)
- Setting the source OID for RMON alarm, event, and history tables
generates an error message. This OID will be disabled in future
- Media speed messages in log file (CR 137973)
- When starting the BIG-IP VE system or when removing an interface from a
VLAN, the system logs media-related messages to the file
/var/log/ltm. You can ignore these
- The virtual switch clears the QoS field in 802.1q headers (ID 358996)
- A hypervisor's Layer 2 bridging device might remove quality of service
(QoS) classification from packets.