Updated 12/17/2012 • Originally posted on 17-Dec-2012 by
We have recently upgraded our ESX servers to 5.1.
Since then, my LTM VE 10.2.1.297 has stopped working and my interfaces shows as uninitialized.
Looking @ https://support.f5.com/kb/en-us/pro...0_2_1.html
I saw that 10.2.1. is compatible with ESX 4.0 - 4.1 only!
Thanks in advance!
IIRC, a change to the vmxnet3 driver was required in order to support vSphere 5, so an upgrade is probably the only solution. You should be able to upgrade your existing VE instance just as you would a physical LTM. http://support.f5.com/kb/en-us/solutions/public/12000/600/sol12628
1. "Is there an easy way to solve this?"
I'm guessing that since you can see the interfaces as unitiailized (normal on 10.2.1 VE with VMXNET3, fwiw) that the box does come up. The problem with pre 10.2.3 on ESX5.x and later is more of a deployment issue, not so much that the NICs won't work so well.
Anwyays, I think this indicates that the problem is likely in NIC ordering from your hypervisor upgrade. You can line the nics up again. This is written better in the manuals, but check the mac addresses against the BIG-IP view of the interfaces. Its likely that you'll have to reassign them.
You can also move them around on the BIG-IP by changing the VLAN(s) that the BIG-IP interfaces are assigned to.
2) "Can I upgrade 10.2.1 to 10.2.2\3\4 without messing up my configuration?"
Yes. My very bare-bones summary (manuals, askf5.com, support have more details)
Copy the 10.2.1 and 10.2.x iso of your choice to /shared/images and you can perform a liveinstall to another boot location. This will preserve the 10.2.1 configuration and let you experiment with the new technologies available in the later releases with simple time tested BIG-IP controls.
The old boot location and disk image can be kept around. Once the old version isn't needed and to save space, be sure to remove the m using the web based configuration utility or tmsh. Note that if the system was deployed using thin provisioning (for lab edition), flatten the filesystem on the hypervisor side when there is a chance for downtime to reclaim the deleted blocks on the hypervisor's storage.
For an extra and somewhat redundant layer of protection you can also take a snapshot of your 10.2.1 instance before installing 10.2.x and rolling back if need be, but this generally requires some consideration of snapshotting a live filesystem. Snapshotting the RAM isn't suggested.
Strangely enough, 11.3.0 is the first of a new architecture model for the virtual edition wherein the drivers are different from previous releases. Throughput is much higher and many new features are present.
in 11.3.0, you get CMP (multi-tmm) and extra hypervisors alongside the supported fleet.
I'd try rm'ing /var/db/mcpdb.bin and rebooting as a next step.
(only because of what you've already done and you're seeing the zero MAC)
that's a known bug, sadly. You can remove the media and duplex settings from /config/bigip_base.conf
Done that... Still MACs shows 0:0:0:0:0:0 Any ideas?
Additioanlly, another interface just came from no where... I had 1.1 and 1.2 and now I have 1.3 as well... O_O
appreciate your help!
10.2.2-hf2 has the first VMXNET3 code that will function on ESXi 5.x, but 10.2.4 is probably your best bet if you must stay 10.2.x.