Editing VPS Management (section)

=== src=2.5.x ===

First, go to the private dir:

 cd /vz1/private/

Stop the VE - make sure it stops totally cleanly.
 
 vzctl stop 1212

Then you’d use vemove - a script written to copy over the config, create tarballs of the ve’s data on the destination virt, and cancel the ve on the source system (in this example we’re going to put a ve that was in /vz1/private on the src virt, in /vz/private on the dst virt):

<pre>[root@virt12 sbin]# vemove
ERROR: Usage: vemove veid target_ip target_path_dir
[root@virt12 sbin]# vemove 1212 10.1.4.64 /vz/private/1212
tar cfpP - 1212 --ignore-failed-read | (ssh -2 -c arcfour 10.1.4.64 "split - -b 1024m /vz/private/1212.tar" )
scp /vzconf/1212.conf 10.1.4.64:/vzconf
cancelve 1212
v stop 1212
v set 1212 --offline_management=no --save
Delete port redirection
Deleting IP address(es) from pool: 69.55.229.84
Saved parameters for VE 1212
mv /vzconf/1212.conf /vzconf/deprecated-1212
mv /vz1/private/1212 /vz1/private/old-1212-cxld-20050414
don't forget to remove firewall rules and domains!
[root@virt12 sbin]#</pre>

Note: if the system had backups, cancelve would offer to remove them. You want to say no to this option – doing so would mean that the backups would have to be recreated on the dst virt. Instead, copy over the backup configs (make note of path changes in this example) from backup.config on the src virt to backup.config on the dst virt.
Then go to backup2 and move the dirs. So you’d do something like this:
 mv /mnt/data1/virt12/0/vz1/private/1212 /mnt/data3/virt14/0/vz/private/

We don’t bother with the other dirs since there’s no harm in leaving them and eventually they’ll drop out. Besides, moving harlinked files across a filesystem as in the example above will create actual files and consume lots more space on the target drive. 
If moving to the same drive, you can safely preserve hardlinks and move all files with:
 sh
 for f in 0 1 2 3 4 5 6; do mv /mnt/data1/virt12/$f/vz1/private/1212  /mnt/data1/virt14/$f/vz/private/; done

When you are done, go to /vz/private on the dst virt you will have files like this:

<pre>1212.taraa
1212.tarab
1212.tarac</pre>

Each one 1024m (or less, for the last one) in size.

on the dst server and run:

 cat 1212.tar?? | tar xpPBf -

and after 20 mins or so it will be totally untarred.  Now since the conf
file is already there, you can go ahead and start the system.

 vzctl start 1212

Update the customer’s systems by clicking the “move” link on the moved system, update the system, template (should be pre-selected as the same), and the shut down date.

NOTE: you MUST tar the system up using the virtuozzo version of tar that
is on all the virt systems, and further you MUST untar the tarball with
the virtuozzo tar, using these options:  `<tt>tar xpPBf -</tt>`

If you tar up an entire VE and move it to a non-virtuozzo machine, that is
ok, and you can untar it there with normal tar commands, but do not untar
it and then repack it with a normal tar and expect it to work - you need
to use virtuozzo tar commands on virtuozzo tarballs to make it work.

The backups are sort of an exception, since we are just (usually)
restoring user data that was created after we gave them the system, and
therefore has nothing to do with magic symlinks or vz-rpms, etc.