How is choosen the master or primary slot of the cluster?
Hi there, I'd like to know how the cluster master slot is choosen? Is there any rule or algorithm to choose the primary slot on boot? I'm wondering why my Viprion has decided this configuration after booting: On the vCMP host: ----------------------------------------- Sys::Cluster: default ----------------------------------------- Address 192.168.16.32/21 Availability available State enabled Reason Cluster Enabled Primary Slot ID 1 Primary Selection Time 11/27/14 09:03:31 ---------------------------------------------------------------------------------------------------------------------- | Sys::Cluster Members | ID Address Availability State Licensed HA Clusterd Reason ---------------------------------------------------------------------------------------------------------------------- | 1 192.168.16.33 available enabled true active running Run | 2 192.168.16.34 available enabled true active running Run | 3 :: unknown disabled false unknown shutdown Slot powered off or empty, manually disabled | 4 :: unknown disabled false unknown shutdown Slot powered off or empty, manually disabled On the guest: ----------------------------------------- Sys::Cluster: default ----------------------------------------- Address 192.168.16.55/21 Availability available State enabled Reason Cluster Enabled Primary Slot ID 2 Primary Selection Time 11/27/14 09:06:27 ---------------------------------------------------------------------------------- | Sys::Cluster Members | ID Address Availability State Licensed HA Clusterd Reason ---------------------------------------------------------------------------------- | 1 :: available enabled true active running Run | 2 :: available enabled true active running Run | 3 :: unknown enabled false unknown shutdown Slot powered off or empty | 4 :: unknown enabled false unknown shutdown Slot powered off or empty I'd expect to see the guest active on slot 1 too, how is this? It doesn't matter that the slot 1 is the active one for the host and slot 2 for the guest?
Reboot Blade / Reboot Chassis options in a vCMP Guest
Hi, Which is the difference between "Reboot Blade" and "Reboot Chassis" when we're working at a Guest level? It's clear that from a Guest I'll never be able of affect the real hardware, so I'l never be able of reboot the blade or chassis. When I use this options on a Guest, what is the real effect? I don't have a vCMP test environment, so I can't test it. I guess that any of those options will reboot the Guest, but with any difference between the blade or chassis option? I guess that maybe, "Reboot Blade" at a Guest level will reboot the VM for that Guest on that blade, and "Reboot Chassis" at a Guest level will, maybe, reboot all the VMs for that Guest on all the slots to which that Guest is spanned. I haven't find any documentation about this specific subject, so any help to clarify this will be welcomed :) Thanks.
Viprion slot core reorganization
Hello Everyone, I started working a while ago managing some F5 hosts and guests and I encounter a strange situation. During an upgrade from v13 to v15 of a 1 core per slot vcmp guest I ran into a memory issue and I was unable to upgrade this guest. I was suggested to reconfigure the cores in this vcmp guest to get more memory. My current setup is the following: Viprion Host with 4 slots with 20 cores each. (We have 2 chassis) 18 Of the cores in every slot are used. So I have 2 vcmp guests with one core per slot. I was suggested to reconfigure the vcmp guests using 2 cores in 2 slots so I can get double the memory, moving from 1x4 to 2x2. I read all the manuals regarding resource allocation but I can't seem to understand why will this perform better (aside from the fact that it will have more memory). Is it better to have more cores assigned per slot rather than using all 4 slots? Will it handle the same amount of traffic the same way?
Unable to login F5 guest using admin credentials
I am having a strange issue where I cannot login to the F5 guest using the admin account . I have changed the admin credentials using the root account but the approach does not work .. Is there any workaround for this to get the admin account working again ?Consolidation of hardware BIG-IP on vCMP guests
Hi there, I'm just about to start a consolidation process of several BIG-IP 2000S into our new vCMP platform. I've looking for some documentation about consolidation good practices or technical recommendations but I haven't find much. My first thought was getting a UCS in the 2000S and load it in the guest, but I guess that first I've to adapt somehow the config to the guest "platform" (more than just loading it with the no-platform o no-license check options). I'm thinking here in things like VLAN definitions or physical interface definitions that are all specified in the bigip_base.conf Maybe it's enough with editing the file, remove completely VLAN and interface definitions and try to load it with the tmsh sys load config command. From your experience, are the physical interfaces and VLAN configuration all that I should remove (or adapt in any way) or there's something more? Second option I'm thinking of is just recreating all the LTM objects (nodes, pools, virtual servers) and re-importing certificates, external monitors... through config merge or maybe a tmsh script. Doing the consolidation process more "manually" but this is a lot more of work, and I'd prefer to adapt the config and just load the UCS in the guest. Prefering the UCS approach I'm afraid of letting behind some snippet of configuration that could cause weird behaviors at guest level. From some tests that I've done loading the UCS, I got weird interfaces and an incorrect monitoring of the nodes and pools. Any recommendation will be very welcomed! :) Thanks!
F5 viprion - guest fails after vlan added
I have an F5 Viprion and just created a new guest. I configured interfaces, trunks, and vlans. When I assign VLANs from the host to the new guest in the VCMP-Guest window, the guest Status changes from "green"/active, to "gray" on the host. I have to disable the guest and re-deploy again on the guest. I have worked with other models (i.e. 10200) and did not have this issue. Is there anything different that is required on the Viprion to prevent the guest from going offline after adding a new VLAN to a guest? Thanks.
