Issue Single migration works, multiple do not

[mr-wolf]

For years now I've been using the "new" Plesk migration which makes it possible to resync and migrate several domains at once.
I renew servers every 3 years and have been using that migration since its adoption and I love it a lot.
I see it as the best improvement in Plesk this decade.

This month I setup a new Plesk Obsidian and have trouble migrating more than 1 subscription at a time.
It took me some time to find out it was possible to migrate a domain from another server if I only picked 1.
This is strange as in the past I often do 6 or more domains at the same time as this takes the least time in combination with changing DNS (on another server).

It hangs on the pre-migration checks. Because it works if I do it 1 domain at the time, I have no clue what the culprit is.
The pre-migration indeed finds several stuff, but these are no problem.
The domains that don't migrate in such a multiple-domain session migrate easily if I do them one by one.

 

[IgorG]

It looks strange. I'd suggest you look at log /usr/local/psa/var/modules/panel-migrator/sessions/%SESSION_ID%/debug.log and find where migration hangs.
This instruction can help you:

Hanged migrator
Important notice before debugging hanged migration is that migrator is working in multi-threading mode. Multi-threading mode is needed to improve performance of migration: for example, when one thread is creating addon domains of one subscription, the other one copies mail messages of the other subscription. But because of multi-threading mode, log messages from different threads are mixed, and the last line of the log is not always what you are looking for.

1. When it seems that migrator hangs, the first thing you should do is to understand what it is doing (what was the last thing it was doing). There could be 2 situations:

• Migrator is executed in a single thread: the last line of the log contains "|MT|" string. In that case you just need to review the last lines of the log.
• Migrator is executed in multi-threading mode: the last line of the log contains "|STx|" string, where "x" is some number, which means number of the thread.
  In that case you should review the last lines of the log for each thread (from "ST1" to "ST5").

Also, to quickly understand what migrator is doing right now check "progress" file in session directory of migrator:

Subscription migration status: +--------------+-------------+---------------------------------------------------------+ | Subscription | Status | Action | +--------------+-------------+---------------------------------------------------------+ | sub1.tld | In Progress | Synchronize subscription with plan | +--------------+-------------+---------------------------------------------------------+ | myapps.tld | In Progress | Adjust common migrated applications for new environment | +--------------+-------------+---------------------------------------------------------+ | myown.tld | In Progress | Restore hosting settings of subscription | +--------------+-------------+---------------------------------------------------------+

When you have migrator hanged for the only subscription, that subscription will be the only with status "In Progress". Then you may check debug log for that subscription.

2. After you reviewed the log, you know which commands are executed right now.

• If it is some content copy command, you may check if data is actually transferred right now: for example for mail copy command check if number of mail messages increases, for copy web content command, check if amount of used disk space on the target server increases, and so on.
• If data is not actually copied:
  • For advanced users: try to debug the utility, for example on Unix you may use strace.
  • Kill the process.
    Note: In many cases migrator will try to restart the command once more (to avoid reliability issues).

 

[mr-wolf]

I will check this out. Probably next week.
Hopefully I can also find out if I have the same problem between the source server and a server I already have for a longer time.
My guess it's a problem with my new destination server.

 

[trialotto]

I will check this out. Probably next week.
Hopefully I can also find out if I have the same problem between the source server and a server I already have for a longer time.
My guess it's a problem with my new destination server.

@mr-wolf

I think that you should focus on the source server, amongst others due to the fact that the pre-migration checks seem to be the bottleneck.

Furthermore, it can be the case that the Plesk Obsidian version 18.0.27 (before MU1) caused some hardware damage (disks mostly) and/or caused some network related issues (with various root causes of the problem, some of them unknown) and/or psa database related issues (mostly 18.0.26 to 18.0.27 upgrade failures).

This is a huge spectrum of possible explanations....... but I can narrow it down to a distinction between the most likely root cause (SSH) and symptoms.

For instance, on one test server we had created an environment to replicate issues - most of the issues were actual symptoms of a SSH related issue that found its root cause in the bug that has been patched in the Plesk Obsidian 18.0.27 MU1 update : the firewall caused havoc.

Plesk Migrator will not work well if you have a problem with SSH - and if you have that SSH related problem, pre-flight check is a bit problematic.

However, that SSH related problem is not actually related to SSH config - in the worst case, SSH will time out.

The SSH related problem is related to firewall / iptables related issues, causing the network to behave erraticly.

You can do some simple tests with ping - just run the following commands

1- ip addr show
2 - ip route
3 - ping -c5 $(ip route | awk '/default/ {print $3}')
4 - ping -c5 [ip from your network of trusted IP addresses - another server in your possession]
5 - ping google.com

and commands 1 to 3 should not result in any problem, command 4 and 5 should sometimes work and sometimes not, if you have a firewall causing havoc or some major network issues.

You can use those commands also on the destination server, just to be sure.

I do not think that all of the above will help solve your problem, but it can certainly help to rule out SSH related issues as the root cause of the problem.

Kind regards.......