Forum

Hello,

We have checked the actual K8s status on your new server and found the root cause: the target server specifications are insufficient:

• The server you purchased (Tencent Tokyo 2C 2GB) currently has its memory fully consumed by Gitea + svn-server (usage ~120%).
• Cloning the project requires launching 3 additional 'pvmover-restore' Pods to migrate the volumes from the old project, but they have been stuck in Pending for over 3 hours. K8s message: 0/1 nodes are available: 1 Insufficient memory.

Regarding the contradiction where "every item shows completed, but the overall status shows failed":

The 4 green checkmarks on the progress panel only indicate that the platform has "triggered" these stages, not that the underlying work is finished.

• "Clone Started", "Deployment: Template deployed", "Clone Completed: new project ready", and "Volume Copy: Starting" are all initialization stages that trigger within the first second.
• The actual data migration work runs as K8s Jobs on your new server after that, and we can see those Jobs stuck in Pending, waiting indefinitely for memory.
• Subsequent events like "X completed" or "X failed" for Volume Copy only appear after the actual Job finishes or times out after 6 hours. Until then, the UI won't add new green checkmarks, but the "failed" banner might pop up due to a polling timeout, causing the visual contradiction of "everything completed but showing failed."

Regardless of what the UI displays, the actual blocker is insufficient memory. Recommended solutions:

Option A (Highly Recommended): Upgrade the target server specifications We suggest upgrading to at least 2C 4GB, ideally 2C 8GB. After upgrading, please delete the failed bmp-tatous project and re-trigger the "Clone Project" action from the source (cgk1).

Option B: Pause Gitea and svn-server on the target server, wait for the volume migration to finish, then restart

1. Go to the new project (bmp-tatous) and Pause both Gitea and svn-server.
2. Wait for pvmover-restore to change from Pending to Running and complete.
3. Restart Gitea and svn-server.

This is only a temporary workaround; running these services on 2GB will continue to hit limits in the long run.

Thank you for your help, the issue has been resolved. I really love this product.

I suggest adding a feature to evaluate whether the target server's specifications meet the requirements during the migration process.