The most likely reason for this is a version mismatch in the EZ OS template. It will prevent migrating the VPS even if ‘vzmigrate’ is run in ‘-f’ mode (force).

1. Check if the VPS uses an EZ OS template and which one it is:

   # vzpkg list -O 1001
   fedora-core-4-x86 2006-12-01 14:41:34

2. Check if there are updates available (output shortened):

   # vzpkg status
   Loading “rpm2vzrpm” plugin
   Setting up repositories
   Reading repository metadata in from local files
   Next update(s) are available:
   device-mapper i386 1.02.07-2.0
   gnupg i386 1.4.5-1
   libtiff i386 3.7.1-6.fc4.3
   libuser i386 0.53.7-1.fc4.1
   lvm2 i386 2.02.06-1.0.fc4

3. Ok, it looks like the template is outdated. Let’s make sure our cached template is up-to-date (output shortened).

   #vzpkg update cache fedora-core-4-x86
   Updating cache for fedora-core-4-x86 OS template
   Reading repository metadata in from local files
   No Packages marked for Update/Obsoletion
   Packing cache file fedora-core-4-x86.tar.gz …
   Cache file fedora-core-4-x86.tar.gz [15M] created.

4. Now update the VPS:

   #vzpkg update 1001 fedora-core-4-x86
   Loading “rpm2vzrpm” plugin
   Setting up Update Process
   Setting up repositories
   [ .. ]
   Dependency Updated: samba-common.i386 0:3.0.23a-1.fc4.1
   Complete!
   Dependency Installed:
   gamin i386 0:0.1.1-3.FC4
   Updated:
   gnupg i386 0:1.4.5-1
   python i386 0:2.4.3-8.FC4
   samba i386 0:3.0.23a-1.fc4.1
   samba-client i386 0:3.0.23a-1.fc4.1
   samba-swat i386 0:3.0.23a-1.fc4.1
   sendmail i386 0:8.13.7-2.fc4.2
   sendmail-cf i386 0:8.13.7-2.fc4.2
   sendmail-doc i386 0:8.13.7-2.fc4.2
   Dependency Updated:
   samba-common i386 0:3.0.23a-1.fc4.1

5. If you run ‘vzmigrate’ using –keep-dst argument log on to your second hardware node first and rename /vz/private/1001 to /vz/private/1001.migrated. (Removing that directory is fine, too, if you’re familiar with the process).
6. Now run ‘vzmigrate’ again:

   #vzmigrate –keep-dst –remove-area no 192.168.0.1 1001
   root@192.168.0.1′s password:
   Connection to destination HN (192.168.0.1) is successfully established
   Moving/copying VE#1001-> VE#1001, [], [] …
   destination ‘/vz/private/1001′ for VE#1001already exists
   Syncing private area ‘/vz/private/1001′
   \ 100% |*****************************|
   done
   Stopping VE#228128 …
   done
   Fast syncing private area ‘/vz/private/1001′
   - 100% |*****************************|
   done
   Starting VE#1001 …
   done

   Successfully completedSee, it worked like a charm!

Fixing this involves a little handwork on the destination hardware node.

1. Check using ‘vzlist’ if a VPS #1001 exists (should not)
2. Check if directory /vz/root/1001 exists  and remove it
3. Check if directory /vz/private/1001 exists and rename it to /vz/private/1001.migrated (deleting the directory is fine too)

   In case you did not run ‘vzmigrate’ with ‘–keep-dst’ argument, step #3 may be omitted as this directory shouldn’t exist then.

4. Disable the quoata: ‘vzquota of 1001 -f’ (yes, it will complain, but that’s ok)
5. Try again migrating your VPS to the new node

As always YMMV. It worked for me when running ‘vzmigrate’ just as shown above. To be honest: This particular error happened only twice for some 50 or 60 VPS’s migrated and was likely caused by network timeouts.