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
- 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
- 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.
- Incorrect status of VMware Tools in vSphere
- 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
- 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
- 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 ESX® or ESXi® Configuration
- Use of Single Configuration File (SCF) feature
- 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
- Configuration of an OVF with additional interfaces
When you deploy an OVF 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
TMM-to-vSwitch portgroup interface mapping, compare the MAC
addresses of the interfaces displayed in the BIG-IP
Configuration utility to those displayed in the vSphere
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.
- HA events due to BIG-IP VE inactivity
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- A hypervisor's Layer 2 bridging device might remove quality of service
(QoS) classification from packets.