Forum Discussion

Jeff_02_137093's avatar
Jeff_02_137093
Icon for Nimbostratus rankNimbostratus
Mar 25, 2015

Viprion Guest Spanning Multiple Slots and Primary Member - Question

I am involved in a very difficult case where one of our Viprion guests has been unstable since January and we've incurred countless hours trying to get one of the guests in a traffic group back to normal operation in the traffic group etc.

 

Currently, the guest is severed from the network to allow support to attempt to resolve the issue. They've tried countless ideas but none have worked.

 

At this point, I am thinking a complete deletion of the guest from both slot 1 and 2 on the severed host and a reprovision of the guest is in order. F5 support indicates that this won't work as "slot 2 is primary for this guest, and it needs to be slot 1 or it won't work." They indicate that re-provisioning the guest will fail as slot 2 will still become the primary member for this guest.

 

This does not make much sense to me as I did not know there was a difference of which slot number in a guest spanning multiple slots becomes active. For instance, I could provision a guest to only exist on slot 2 and it would be functional. Why does it matter if slot 1 is primary and 2 is not, so long as they sync properly?

 

I've asked the engineer for written verification of this issue because it doesn't make any sense to me. Can anyone elaborate on why he is indicating a complete re-provision of this faulty guest on the chassis would not work?

 

Thank you in advance. It is appreciated.

 

6 Replies

  • If you have a full sizes guest across both blades, deleting it on the host will remove it from both blades. Re-provisioning it as a full sized guest on all slots will re-create it as vanilla all all blades regardless of who is primary. I'm not quite sure what support is telling you.

     

    • Jeff_02_137093's avatar
      Jeff_02_137093
      Icon for Nimbostratus rankNimbostratus
      Thanks for the reply, Brad. That is what I would expect. We have to slots in a Viprion Chassis and slot 1 is offline and is not communicating properly. Slot 2 is primary. We are trying to bring this cluster up and the support engineer states the following: **The support engineer states:** The crux of the current issue is that the cluster/management IP address is not being propagated to slot 1. Unfortunately, any changes need to be made on the Primary slot, which is slot 2. "A floating management IP address that you use to manage the guest. The BIG-IP system assigns this IP address to the primary cluster member for the guest." There are a few options that we can try before the action plan we discussed earlier. 1) "Modify" the cluster/management IP address: 'Change' the cluster IP (DON'T UPDATE), then change it back to the original value and update the 'changed config. This should be occurring already (propagation of cluster iP from slot 2 --> slot 1 for the guest) System --> Cluster --> Management IP 2) Change the guest stated from Deployed --> Provisioned, then back to Deployed. 3) Create an UCS archive for the guest, delete the guest entirely, then re-create the guest and restore the UCS archive. ***Please keep in mind that the propagation of the cluster/management IP address should already be occurring, and as such, we do not believe there is a high degree of probability that the above step(s) would work.***
    • Brad_Parker_139's avatar
      Brad_Parker_139
      Icon for Nacreous rankNacreous
      I'm not going to get involved too much with your support case, but know that the primary slot for the vCMP guest can be a different slot than the primary for the vCMP host.
  • If you have a full sizes guest across both blades, deleting it on the host will remove it from both blades. Re-provisioning it as a full sized guest on all slots will re-create it as vanilla all all blades regardless of who is primary. I'm not quite sure what support is telling you.

     

    • Jeff_02_137093's avatar
      Jeff_02_137093
      Icon for Nimbostratus rankNimbostratus
      Thanks for the reply, Brad. That is what I would expect. We have to slots in a Viprion Chassis and slot 1 is offline and is not communicating properly. Slot 2 is primary. We are trying to bring this cluster up and the support engineer states the following: **The support engineer states:** The crux of the current issue is that the cluster/management IP address is not being propagated to slot 1. Unfortunately, any changes need to be made on the Primary slot, which is slot 2. "A floating management IP address that you use to manage the guest. The BIG-IP system assigns this IP address to the primary cluster member for the guest." There are a few options that we can try before the action plan we discussed earlier. 1) "Modify" the cluster/management IP address: 'Change' the cluster IP (DON'T UPDATE), then change it back to the original value and update the 'changed config. This should be occurring already (propagation of cluster iP from slot 2 --> slot 1 for the guest) System --> Cluster --> Management IP 2) Change the guest stated from Deployed --> Provisioned, then back to Deployed. 3) Create an UCS archive for the guest, delete the guest entirely, then re-create the guest and restore the UCS archive. ***Please keep in mind that the propagation of the cluster/management IP address should already be occurring, and as such, we do not believe there is a high degree of probability that the above step(s) would work.***
    • Brad_Parker's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      I'm not going to get involved too much with your support case, but know that the primary slot for the vCMP guest can be a different slot than the primary for the vCMP host.