Wireless Access

 View Only
Expand all | Collapse all

Mobility Master VM Replacement?

This thread has been viewed 51 times
  • 1.  Mobility Master VM Replacement?

    Posted Oct 07, 2024 12:05 PM

    Hello all,

    Forgive me if I use the wrong terminology here or if I'm posting in the wrong area, I am trying to muddle my way through this process which we normally use an outside contractor for but my boss has said that's not an option at this time.  

    We have two Aruba 7220 Controllers (#1 is .41, #2 is .40).  We have two Aruba Mobility Master VMs in a Active/Standby configuration (#1 is .37, #2 is .38, and they have a VRRP IP of .39).  We are on version 8.10.0.8 (for both the physical controllers and the VMs).  We have deployed two replacement OVA files of the same exact version of the existing VMs (new #1 is .182, and new #2 is .183).  We want to replace .37 and .38 with .182 and .183.  I for the life of me can't figure out where to begin with this process.  

    I tried to follow the steps here: Replacing a Controller

    Arubanetworks remove preview
    Replacing a Controller
    The procedures below describe the steps to replace an existing stand-alone and/or a redundant . Best practices are to replace the backup first, and replace the active only after the new backup is operational on the network. When you remove the active from the network to replace it, the new backup takes over the active role.
    View this on Arubanetworks >

     but I think it's talking about the physical controller, and not the actual VM.  

    Can someone please point me in the correct direction for replacing the two Mobility Master VMs?  My understanding is that we will need to replace the standby VM first, let a sync occur, and then replace the primary, and then ensure the licensing is still correct, which will likely require a license conversion with HPE/Aruba.  I just can't find explicit steps to replace the VMs.



  • 2.  RE: Mobility Master VM Replacement?

    Posted Oct 07, 2024 01:58 PM

    First, don't use the OVA, use the ISO to build the virtual appliance.  That way you for sure have the correct configuration for the MCR, including storage requirements, for your deployed appliance sizing.

    Second, if you already have the VMs, and the desire is just to change the IP addresses, why are you deploying new VMs rather than just re-addressing the existing appliances?



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 3.  RE: Mobility Master VM Replacement?

    Posted Oct 07, 2024 02:11 PM
    Edited by msantangelo Oct 07, 2024 02:13 PM

    The VMs are being moved from a Hyperflex converged environment to a single standalone ESXi node.  We have tried migrating the VMs but it never works properly.  The advice we received was to deploy new VMs via OVA and migrate the config over, though they would not provide explicit steps.  




  • 4.  RE: Mobility Master VM Replacement?
    Best Answer

    Posted Oct 07, 2024 02:28 PM

    Ah.

    1. Deploy new virtual appliances using ISO
    2. Grab flashbackup of standby
    3. Power off standby MCR
    4. Bring up new standby MCR appliance, configuring with the same IP address as the old
    5. Restore flashbackup to new MCR appliance
    6. Validate functionality, database synchronization, and VRRP/conductor failover
    7. Repeat above steps with the other MCR
    8. Validate licensing, should require re-issuing the licenses as the MCR passphrase will have changed

    Obviously, do this during a maintenance period to avoid client issues.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 5.  RE: Mobility Master VM Replacement?

    Posted Oct 07, 2024 02:45 PM

    How do I grab the flashbackup of the standby though? I can grab it of the primary using the WebUI.  Do I have to do it via the CLI on the standby?




  • 6.  RE: Mobility Master VM Replacement?

    Posted Oct 07, 2024 02:49 PM

    Just log in to the secondary?



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 7.  RE: Mobility Master VM Replacement?

    Posted Oct 07, 2024 03:00 PM

    Yeah I realized that I had to login via CLI.  When we access the Web Interface for the secondary, we just got a X509 cert error.




  • 8.  RE: Mobility Master VM Replacement?

    Posted Oct 07, 2024 03:23 PM

    Certificate error can be bypassed by using some browsers or forcing unsafe usage.  Otherwise, update the certificate; usually this is done by adding/updating the certificate at the Mobility Conductor level in the configuration and then assigning that certificate for usage by the WebUI.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 9.  RE: Mobility Master VM Replacement?

    Posted Oct 07, 2024 03:40 PM

    VRRP is definitely not working but the new conductors are both seemingly online and communicate as they are in the list of mobility masters.




  • 10.  RE: Mobility Master VM Replacement?

    Posted Oct 07, 2024 03:44 PM

    Make sure promiscuous mode and forged transmits are enabled on the vSwitch/port group.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 11.  RE: Mobility Master VM Replacement?

    Posted Oct 07, 2024 03:50 PM

    THAT WAS IT!  You are a godsend.  How can I thank you!?! 




  • 12.  RE: Mobility Master VM Replacement?

    Posted Oct 07, 2024 04:04 PM

    On here, I think I get paid in kudos.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 13.  RE: Mobility Master VM Replacement?

    Posted 30 days ago

    Take all the kudos! I have clicked all the buttons and marked as best answer.  Thank you!

    I only have one more question: under Mobility Conductor we now have three entries... The two new mm vm's tech24-aruba-mm01 and tech24-aruba-mm02 and then one that is just a mac address: 00:50:56:84:73:af.  This matches the mac address for the old primary controller tech21-aruba-mm01.

    Is there any way to remove this entry? That VM is never coming back.