Editing VPS Management (section)

=== migrateonline/migrate failures (migrate manually) ===

Lets say for whatever reason the migration fails. If it fails with [[#migrateonline|migrateonline]], you should try [[#migrate|migrate]] (which will reboot the customer, so notify them ahead of time).

You may want to run a [[#pre-seeding_a_migration|pre-seed]] rsync to see if you can find the problem. On older virts, we've seen this problem due to a large logfile (which you can find and encourage the customer to remove/compress):
 for f in `find / -size +1048576k`; do ls -lh $f; done

You may also see migration failing due to quota issues.

You can try to resolve by copying any quota file into the file you need:

 cp /var/vzquota/quota.1 /var/vzquota/quota.xxx

If it complains about quota running you should then be able to stop it

 vzquota off xxxx

If all else fails, migrate to a new VEID
i.e. 1234 becomes 12341


If the rsync or [[#migrate|migrate]] fails, you can always move someone manually:

1. stop ve: <br>
 v stop 1234

2. copy over data<br>
 rsync -avSH /vz/private/1234/ root@1.1.1.1:/vzX/private/1234/

NOTE: if you've previously seeded the data (run rsync while the VE was up/running), and this is a subsequent rsync, make sure the last rsync you do (while the VE is not running, has the --delete option in the rsync)

3. copy over conf<br>
 scp /vzconf/1234.conf root@1.1.1.1:/vzconf

4. on dst, edit the conf to reflect the right vzX dir<br>
 vi /vzconf/1234.conf

5. on src remove the IPs<br>
 ipdel 1234 2.2.2.2 3.3.3.3

6. on dst add IPs <br>
 ipadd 1234 2.2.2.2 3.3.3.3

7. on dst, start ve: <br>
 v start 1324

8. cancel, then archive ve on src per above instrs.