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
- Event log reports insufficient video RAM (ID 324968; CR 134473)
- On VMware ESXi systems only, the following event message is logged:
The maximum resolution of the virtual machine will be limited to 1176x885 at 16 bits per pixel. To use the configured maximum resolution of 2360x1770 at 16 bits per pixel, increase the amount of video RAM allocated to this virtual machine by setting svga.vramSize="16708800" in the virtual machine's configuration file.
You can ignore this message or follow the recommended action without
- Time synchronization using VMware Tools or NTP protocol (CR 135980)
- If you want to use VMware Tools to enable time synchronization, you must
select the Synchronize guest time with host
check box within vSphere client. If you want to use network time
protocol (NTP) instead, you must first disable time synchronization in
VMware Tools by clearing the check box within vSphere client. For more
information, see the VMware vSphere™ client
documentation. Note that the two units of a BIG-IP VE redundant system
configuration must share the same time synchronization source.
- Link speed of management interface (ID 224507; CR 136578)
- The management port might not correctly reflect the uplink port speed
of the vSwitch that it is connected to. This should have no adverse
affects on actual management port traffic.
- Incorrect status of VMware Tools in vSphere (CR 136980)
- VMware vSphere incorrectly shows the status of VMware Tools as
Not Installed. You can verify that VMware
Tools are installed by viewing the IP Address
and DNS Name fields on the vSphere screen. Note
that if you migrate the virtual machine or start a snapshot or cloned
image of the virtual machine, the status correctly shows as
- Lack of VMXNET3 availability (CR 137014)
- The VMXNET3 driver can become unavailable after you suspend and resume
BIG-IP VE. Resetting the BIG-IP VE will resolve the problem.
- Use of VLAN groups (CR 137596)
- Use of VLAN groups with BIG-IP VE requires proper configuration of the
VMware vSwitch. To use the VLAN group feature, you must configure
security policies on the vSwitch. The properties of the security
policy that you need to configure are Promiscuous
Mode and Forged Transmits.
For any transparency mode, you must configure these properties to
accept (rather than reject) the security policy exceptions on the
vSwitch. For information about how to configure these options, see the
VMware vCloud™ Director Configuration
- Use of Single Configuration File (SCF) feature (CR 137597)
- Copying an SCF from a VMware host system to an F5 hardware platform
causes an error related to interface mismatching. Edit the SCF and
remove speed and duplex media statements from the network interface
statements before importing.
- Configuration of additional interfaces (CR 137616; CR 137621)
- When a BIG-IP VE system is configured with more than four interfaces
(one management interface and more than three 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 client. If you change the number of
virtual interfaces on the BIG-IP VE system after a binary MCPD
database is 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
at the BIG-IP VE command prompt, and reboot the system.
- HA events due to BIG-IP VE inactivity (CR 138676)
- If the VMware hypervisor runs the BIG-IP VE software for fewer than four
minutes continuously (for example, due to a manual suspension or the
timeout of network disk I/O), high-availability failure events occur.
The system might note a failure and restart key system processes and
trigger failover if within a high-availability (HA) group. This is
intended system behavior.
- VMware vSwitch Promiscuous Mode (CR 138798)
- When the VMware vSwitch Promiscuous Mode is set
to Reject, the VLAN group transparency mode,
Opaque, will not be able to pass
- 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
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 license.
- 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.
- 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.