You can move the data across at any time.
However, an important point to note is that the new Event Processor (EP), which is in HA, must be configured with the IP address of the old standalone EP.

We cannot change the IP address or run qchange_netsetup on a managed host that is part of an HA pair and already in a deployment.

Recommended Action Plan:

1. Break the HA on the new EP.
2. Redirect the Event Collector from the new EP to another EP or the Console.
3. Remove the new EP from the deployment.
4. Run qchange_netsetup on the new EP and assign it the IP address of the old EP. Ensure the old EP is shut down to avoid IP conflicts. Alternatively, run qchange_netsetup on the old EP first to release the IP.
5. Add the new EP (now with the old IP) back into the deployment.
6. Reconfigure the Event Collector to point to the new EP (now with the old EP's IP).
7. Re-establish HA on the new EP.

If you need assistance in carrying out this activity, feel free to reach out to the IBM Support Team.

Moving old data is not a big issue, all the IP are in the same subnet so we can use also ariel_sync.sh utility to quickly transfer the Ariel files.

BR,

Davide

You can move the data across at any time.
However, an important point to note is that the new Event Processor (EP), which is in HA, must be configured with the IP address of the old standalone EP.

We cannot change the IP address or run qchange_netsetup on a managed host that is part of an HA pair and already in a deployment.

Recommended Action Plan:

1. Break the HA on the new EP.
2. Redirect the Event Collector from the new EP to another EP or the Console.
3. Remove the new EP from the deployment.
4. Run qchange_netsetup on the new EP and assign it the IP address of the old EP. Ensure the old EP is shut down to avoid IP conflicts. Alternatively, run qchange_netsetup on the old EP first to release the IP.
5. Add the new EP (now with the old IP) back into the deployment.
6. Reconfigure the Event Collector to point to the new EP (now with the old EP's IP).
7. Re-establish HA on the new EP.

If you need assistance in carrying out this activity, feel free to reach out to the IBM Support Team.

Just a suggestion from my side (from personal experience) - as you mentioned that the appliances are in the same subnet and thus I am assuming they are not very distant. 

Looking into the syncAriel.sh script you will find at two places the command rsync -az --exclude='.*' $MONTH/ $SSHUSER@$IP:$MONTH/ 
I would suggest that the z from -az is removed in these lines (it forces it to compress the data to be sent - and leaving it like that you might end up with a data transfer taking noticeably longer than necessary).

Moving old data is not a big issue, all the IP are in the same subnet so we can use also ariel_sync.sh utility to quickly transfer the Ariel files.

BR,

Davide

You can move the data across at any time.
However, an important point to note is that the new Event Processor (EP), which is in HA, must be configured with the IP address of the old standalone EP.

We cannot change the IP address or run qchange_netsetup on a managed host that is part of an HA pair and already in a deployment.

Recommended Action Plan:

1. Break the HA on the new EP.
2. Redirect the Event Collector from the new EP to another EP or the Console.
3. Remove the new EP from the deployment.
4. Run qchange_netsetup on the new EP and assign it the IP address of the old EP. Ensure the old EP is shut down to avoid IP conflicts. Alternatively, run qchange_netsetup on the old EP first to release the IP.
5. Add the new EP (now with the old IP) back into the deployment.
6. Reconfigure the Event Collector to point to the new EP (now with the old EP's IP).
7. Re-establish HA on the new EP.

If you need assistance in carrying out this activity, feel free to reach out to the IBM Support Team.

Hello,

we followed the procedure but we got the error:

ERROR "The IP was previously used and is unavailable, re-run qchange_netsetup and enter a different IP address"

We must re-use the same IP that is currently used from a standalone EP because otherwise customer must edit configurations on more than 150 devices to change the destination IP for logs. Is there a workaround or some fix to overcome this error?

BR

Davide

Just a suggestion from my side (from personal experience) - as you mentioned that the appliances are in the same subnet and thus I am assuming they are not very distant. 

Looking into the syncAriel.sh script you will find at two places the command rsync -az --exclude='.*' $MONTH/ $SSHUSER@$IP:$MONTH/ 
I would suggest that the z from -az is removed in these lines (it forces it to compress the data to be sent - and leaving it like that you might end up with a data transfer taking noticeably longer than necessary).

Moving old data is not a big issue, all the IP are in the same subnet so we can use also ariel_sync.sh utility to quickly transfer the Ariel files.

BR,

Davide

You can move the data across at any time.
However, an important point to note is that the new Event Processor (EP), which is in HA, must be configured with the IP address of the old standalone EP.

We cannot change the IP address or run qchange_netsetup on a managed host that is part of an HA pair and already in a deployment.

Recommended Action Plan:

1. Break the HA on the new EP.
2. Redirect the Event Collector from the new EP to another EP or the Console.
3. Remove the new EP from the deployment.
4. Run qchange_netsetup on the new EP and assign it the IP address of the old EP. Ensure the old EP is shut down to avoid IP conflicts. Alternatively, run qchange_netsetup on the old EP first to release the IP.
5. Add the new EP (now with the old IP) back into the deployment.
6. Reconfigure the Event Collector to point to the new EP (now with the old EP's IP).
7. Re-establish HA on the new EP.

If you need assistance in carrying out this activity, feel free to reach out to the IBM Support Team.

Hello Davide,

You are hitting this known defect https://www.ibm.com/mysupport/s/defect/aCI3p0000004JVCGA2/dt174183?language=en_US
Now you need to involve IBM Support Team. 

Hello,

we followed the procedure but we got the error:

ERROR "The IP was previously used and is unavailable, re-run qchange_netsetup and enter a different IP address"

We must re-use the same IP that is currently used from a standalone EP because otherwise customer must edit configurations on more than 150 devices to change the destination IP for logs. Is there a workaround or some fix to overcome this error?

BR

Davide

Just a suggestion from my side (from personal experience) - as you mentioned that the appliances are in the same subnet and thus I am assuming they are not very distant. 

Looking into the syncAriel.sh script you will find at two places the command rsync -az --exclude='.*' $MONTH/ $SSHUSER@$IP:$MONTH/ 
I would suggest that the z from -az is removed in these lines (it forces it to compress the data to be sent - and leaving it like that you might end up with a data transfer taking noticeably longer than necessary).

Moving old data is not a big issue, all the IP are in the same subnet so we can use also ariel_sync.sh utility to quickly transfer the Ariel files.

BR,

Davide

You can move the data across at any time.
However, an important point to note is that the new Event Processor (EP), which is in HA, must be configured with the IP address of the old standalone EP.

We cannot change the IP address or run qchange_netsetup on a managed host that is part of an HA pair and already in a deployment.

Recommended Action Plan:

1. Break the HA on the new EP.
2. Redirect the Event Collector from the new EP to another EP or the Console.
3. Remove the new EP from the deployment.
4. Run qchange_netsetup on the new EP and assign it the IP address of the old EP. Ensure the old EP is shut down to avoid IP conflicts. Alternatively, run qchange_netsetup on the old EP first to release the IP.
5. Add the new EP (now with the old IP) back into the deployment.
6. Reconfigure the Event Collector to point to the new EP (now with the old EP's IP).
7. Re-establish HA on the new EP.

If you need assistance in carrying out this activity, feel free to reach out to the IBM Support Team.