Wireless Access

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
------------------------------

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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

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.

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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

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?

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.

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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

Just log in to the secondary?

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?

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.

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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

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.

Just log in to the secondary?

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?

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.

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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

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.

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.

Just log in to the secondary?

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?

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.

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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

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

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.

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.

Just log in to the secondary?

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?

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.

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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

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

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

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.

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.

Just log in to the secondary?

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?

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.

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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

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

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

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

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.

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.

Just log in to the secondary?

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?

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.

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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

On here, I think I get paid in kudos.

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

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

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

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.

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.

Just log in to the secondary?

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?

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.

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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

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.

On here, I think I get paid in kudos.

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

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

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

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.

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.

Just log in to the secondary?

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?

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.

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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

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.

On here, I think I get paid in kudos.

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

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

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

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.

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.

Just log in to the secondary?

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?

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.

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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

Hey mate, did you ever get a resolution to this issue?

Currently seeing the same thing post migration.

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.

On here, I think I get paid in kudos.

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

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

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

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.

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.

Just log in to the secondary?

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?

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.

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.  

Original Message:
Sent: Oct 07, 2024 01:58 PM
From: chulcher
Subject: Mobility Master VM Replacement?

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