OpenVZ Virtuozzo Containers Wiki - User contributions [en]

Migration from one HN to another

2012-05-27T08:11:24Z

Kotakomputer: /* Summary */

{{wikify}}

The vzmigrate script is used to migrate a [[container]] from one [[Hardware Node]] to another.

== Summary ==

OLD SERVER:
<pre>
[root@OpenVZ ~]# ssh-keygen -t rsa
[root@OpenVZ ~]# cd .ssh/
[root@OpenVZ .ssh]# scp id_rsa.pub root@10.1.5.6:./id_rsa.pub
</pre>
NEW SERVER:
<pre>
[root@Char ~]# cd .ssh/
[root@Char .ssh]# touch authorized_keys2
[root@Char .ssh]# chmod 600 authorized_keys2
[root@Char .ssh]# cat ../id_rsa.pub >> authorized_keys2
[root@Char .ssh]# rm ../id_rsa.pub
rm: remove regular file `../id_rsa.pub'? y
</pre>
OLD SERVER: (test if we can ssh without password)
<pre>
[root@OpenVZ .ssh]# ssh -2 -v root@10.1.5.6
[root@Char ~]# exit
[root@OpenVZ .ssh]# vzmigrate 10.1.5.6 101
</pre>
Above example migrate VM 101 to 10.1.5.6. You can read detail explanation below:

== Setting up SSH keys ==

You first have to setup SSH to permit the old HN to be able to login to the new HN without a password prompt. Run the following on the old HN.

<pre>[root@OpenVZ ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
74:7a:3e:7f:27:2f:42:bb:52:4c:ad:55:31:6f:79:f2 root@OpenVZ.ics.local
[root@OpenVZ ~]# cd .ssh/
[root@OpenVZ .ssh]# ls -al
total 20
drwx------ 2 root root 4096 Aug 11 09:41 .
drwxr-x--- 5 root root 4096 Aug 11 09:40 ..
-rw------- 1 root root 887 Aug 11 09:41 id_rsa
-rw-r--r-- 1 root root 231 Aug 11 09:41 id_rsa.pub
[root@OpenVZ .ssh]# scp id_rsa.pub root@10.1.5.6:./id_rsa.pub
The authenticity of host '10.1.5.6 (10.1.5.6)' can't be established.
RSA key fingerprint is 3f:2a:26:15:e4:37:e2:06:b8:4d:20:ee:3a:dc:c1:69.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.1.5.6' (RSA) to the list of known hosts.
root@10.1.5.6's password:
id_rsa.pub 100% 231 0.2KB/s 00:00</pre>

Run the following on the new HN.

<pre>[root@Char ~]# cd .ssh/
[root@Char .ssh]# touch authorized_keys2
[root@Char .ssh]# chmod 600 authorized_keys2
[root@Char .ssh]# cat ../id_rsa.pub >> authorized_keys2
[root@Char .ssh]# rm ../id_rsa.pub
rm: remove regular file `../id_rsa.pub'? y</pre>

Run the following on the old HN.

<pre>[root@OpenVZ .ssh]# ssh -2 -v root@10.1.5.6
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.1.5.6 [10.1.5.6] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.1.5.6' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Thu Aug 9 16:41:30 2007 from 10.1.5.20
[root@Char ~]# exit</pre>

== Prerequisites ==

Make sure:
* you have at least one good backup of the virtual machine you intend to migrate
* rsync is installed on the target host
* In general you cannot migrate from bigger kernel versions to smaller ones
* By default, after the migration process is completed, the Container private area and configuration file are '''deleted''' on the old HN. However, if you wish the Container private area on the Source Node to not be removed after the successful Container migration, you can override the default <code>vzmigrate</code> behavior by using the <code>–r no</code> switch.

== vzmigrate usage ==

Now that the vzmigrate script will function, a little bit on vzmigrate.

<pre>This program is used for container migration to another node
Usage:
vzmigrate [-r yes|no] [--ssh=<options>] [--keep-dst] [--online] [-v]
destination_address <CTID>
Options:
-r, --remove-area yes|no
Whether to remove container on source HN for successfully migrated container.
--ssh=<ssh options>
Additional options that will be passed to ssh while establishing
connection to destination HN. Please be careful with options
passed, DO NOT pass destination hostname.
--keep-dst
Do not clean synced destination container private area in case of some
error. It makes sense to use this option on big container migration to
avoid syncing container private area again in case some error
(on container stop for example) occurs during first migration attempt.
--online
Perform online (zero-downtime) migration: during the migration the
container hangs for a while and after the migration it continues working
as though nothing has happened.
-v
Verbose mode. Causes vzmigrate to print debugging messages about
its progress (including some time statistics).</pre>

=== Example ===
Here is an example of migrating container 101 from the current HN to one at 10.1.5.6:

<pre>[root@OpenVZ .ssh]# vzmigrate 10.1.5.6 101
OPT:10.1.5.6
Starting migration of container 101 on 10.1.5.6
Preparing remote node
Initializing remote quota
Syncing private
Syncing 2nd level quota
Turning quota off
Cleanup</pre>

== Migrate all running containers ==

Here's a simple shell script that will migrate each container one after another. Just pass the destination host node as the single argument to the script. Feel free to add the -v flag to the vzmigrate flags if you'd like to see it execute with the verbose option:

for CT in $(vzlist -H -o veid); do vzmigrate --remove-area no --keep-dst $1 $CT; done

== Additional Information ==

You can also use this guide to migrate from OpenVZ to Proxmox VE.

If you use Proxmox VE, you may also want to read how to [http://pve.proxmox.com/wiki/Backup_-_Restore_-_Live_Migration Backup-Restore] a virtual machine, be it OpenVZ or KVM.

[[Category:HOWTO]]

Migration from one HN to another

2012-05-27T08:07:37Z

Kotakomputer: /* Summary */

{{wikify}}

The vzmigrate script is used to migrate a [[container]] from one [[Hardware Node]] to another.

== Summary ==

OLD SERVER:
<pre>
[root@OpenVZ ~]# ssh-keygen -t rsa
[root@OpenVZ ~]# cd .ssh/
[root@OpenVZ .ssh]# scp id_rsa.pub root@10.1.5.6:./id_rsa.pub
</pre>
NEW SERVER:
<pre>
[root@Char ~]# cd .ssh/
[root@Char .ssh]# touch authorized_keys2
[root@Char .ssh]# chmod 600 authorized_keys2
[root@Char .ssh]# cat ../id_rsa.pub >> authorized_keys2
[root@Char .ssh]# rm ../id_rsa.pub
rm: remove regular file `../id_rsa.pub'? y
</pre>
OLD SERVER: (test if we can ssh without password)
<pre>
[root@OpenVZ .ssh]# ssh -2 -v root@10.1.5.6
</pre>
OLD SERVER: migrate VM 101 to 10.1.5.6
<pre>
[root@OpenVZ .ssh]# vzmigrate 10.1.5.6 101
</pre>

== Setting up SSH keys ==

You first have to setup SSH to permit the old HN to be able to login to the new HN without a password prompt. Run the following on the old HN.

<pre>[root@OpenVZ ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
74:7a:3e:7f:27:2f:42:bb:52:4c:ad:55:31:6f:79:f2 root@OpenVZ.ics.local
[root@OpenVZ ~]# cd .ssh/
[root@OpenVZ .ssh]# ls -al
total 20
drwx------ 2 root root 4096 Aug 11 09:41 .
drwxr-x--- 5 root root 4096 Aug 11 09:40 ..
-rw------- 1 root root 887 Aug 11 09:41 id_rsa
-rw-r--r-- 1 root root 231 Aug 11 09:41 id_rsa.pub
[root@OpenVZ .ssh]# scp id_rsa.pub root@10.1.5.6:./id_rsa.pub
The authenticity of host '10.1.5.6 (10.1.5.6)' can't be established.
RSA key fingerprint is 3f:2a:26:15:e4:37:e2:06:b8:4d:20:ee:3a:dc:c1:69.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.1.5.6' (RSA) to the list of known hosts.
root@10.1.5.6's password:
id_rsa.pub 100% 231 0.2KB/s 00:00</pre>

Run the following on the new HN.

<pre>[root@Char ~]# cd .ssh/
[root@Char .ssh]# touch authorized_keys2
[root@Char .ssh]# chmod 600 authorized_keys2
[root@Char .ssh]# cat ../id_rsa.pub >> authorized_keys2
[root@Char .ssh]# rm ../id_rsa.pub
rm: remove regular file `../id_rsa.pub'? y</pre>

Run the following on the old HN.

<pre>[root@OpenVZ .ssh]# ssh -2 -v root@10.1.5.6
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.1.5.6 [10.1.5.6] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.1.5.6' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Thu Aug 9 16:41:30 2007 from 10.1.5.20
[root@Char ~]# exit</pre>

== Prerequisites ==

Make sure:
* you have at least one good backup of the virtual machine you intend to migrate
* rsync is installed on the target host
* In general you cannot migrate from bigger kernel versions to smaller ones
* By default, after the migration process is completed, the Container private area and configuration file are '''deleted''' on the old HN. However, if you wish the Container private area on the Source Node to not be removed after the successful Container migration, you can override the default <code>vzmigrate</code> behavior by using the <code>–r no</code> switch.

== vzmigrate usage ==

Now that the vzmigrate script will function, a little bit on vzmigrate.

<pre>This program is used for container migration to another node
Usage:
vzmigrate [-r yes|no] [--ssh=<options>] [--keep-dst] [--online] [-v]
destination_address <CTID>
Options:
-r, --remove-area yes|no
Whether to remove container on source HN for successfully migrated container.
--ssh=<ssh options>
Additional options that will be passed to ssh while establishing
connection to destination HN. Please be careful with options
passed, DO NOT pass destination hostname.
--keep-dst
Do not clean synced destination container private area in case of some
error. It makes sense to use this option on big container migration to
avoid syncing container private area again in case some error
(on container stop for example) occurs during first migration attempt.
--online
Perform online (zero-downtime) migration: during the migration the
container hangs for a while and after the migration it continues working
as though nothing has happened.
-v
Verbose mode. Causes vzmigrate to print debugging messages about
its progress (including some time statistics).</pre>

=== Example ===
Here is an example of migrating container 101 from the current HN to one at 10.1.5.6:

<pre>[root@OpenVZ .ssh]# vzmigrate 10.1.5.6 101
OPT:10.1.5.6
Starting migration of container 101 on 10.1.5.6
Preparing remote node
Initializing remote quota
Syncing private
Syncing 2nd level quota
Turning quota off
Cleanup</pre>

== Migrate all running containers ==

Here's a simple shell script that will migrate each container one after another. Just pass the destination host node as the single argument to the script. Feel free to add the -v flag to the vzmigrate flags if you'd like to see it execute with the verbose option:

for CT in $(vzlist -H -o veid); do vzmigrate --remove-area no --keep-dst $1 $CT; done

== Additional Information ==

You can also use this guide to migrate from OpenVZ to Proxmox VE.

If you use Proxmox VE, you may also want to read how to [http://pve.proxmox.com/wiki/Backup_-_Restore_-_Live_Migration Backup-Restore] a virtual machine, be it OpenVZ or KVM.

[[Category:HOWTO]]

Migration from one HN to another

2012-05-27T08:05:39Z

Kotakomputer: /* Summary */

{{wikify}}

The vzmigrate script is used to migrate a [[container]] from one [[Hardware Node]] to another.

== Summary ==

OLD SERVER:
[root@OpenVZ ~]# ssh-keygen -t rsa
[root@OpenVZ ~]# cd .ssh/
[root@OpenVZ .ssh]# scp id_rsa.pub root@10.1.5.6:./id_rsa.pub

NEW SERVER:
[root@Char ~]# cd .ssh/
[root@Char .ssh]# touch authorized_keys2
[root@Char .ssh]# chmod 600 authorized_keys2
[root@Char .ssh]# cat ../id_rsa.pub >> authorized_keys2
[root@Char .ssh]# rm ../id_rsa.pub
rm: remove regular file `../id_rsa.pub'? y

OLD SERVER: (test if we can ssh without password)
[root@OpenVZ .ssh]# ssh -2 -v root@10.1.5.6

OLD SERVER: migrate VM 101 to 10.1.5.6
[root@OpenVZ .ssh]# vzmigrate 10.1.5.6 101

== Setting up SSH keys ==

You first have to setup SSH to permit the old HN to be able to login to the new HN without a password prompt. Run the following on the old HN.

<pre>[root@OpenVZ ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
74:7a:3e:7f:27:2f:42:bb:52:4c:ad:55:31:6f:79:f2 root@OpenVZ.ics.local
[root@OpenVZ ~]# cd .ssh/
[root@OpenVZ .ssh]# ls -al
total 20
drwx------ 2 root root 4096 Aug 11 09:41 .
drwxr-x--- 5 root root 4096 Aug 11 09:40 ..
-rw------- 1 root root 887 Aug 11 09:41 id_rsa
-rw-r--r-- 1 root root 231 Aug 11 09:41 id_rsa.pub
[root@OpenVZ .ssh]# scp id_rsa.pub root@10.1.5.6:./id_rsa.pub
The authenticity of host '10.1.5.6 (10.1.5.6)' can't be established.
RSA key fingerprint is 3f:2a:26:15:e4:37:e2:06:b8:4d:20:ee:3a:dc:c1:69.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.1.5.6' (RSA) to the list of known hosts.
root@10.1.5.6's password:
id_rsa.pub 100% 231 0.2KB/s 00:00</pre>

Run the following on the new HN.

<pre>[root@Char ~]# cd .ssh/
[root@Char .ssh]# touch authorized_keys2
[root@Char .ssh]# chmod 600 authorized_keys2
[root@Char .ssh]# cat ../id_rsa.pub >> authorized_keys2
[root@Char .ssh]# rm ../id_rsa.pub
rm: remove regular file `../id_rsa.pub'? y</pre>

Run the following on the old HN.

<pre>[root@OpenVZ .ssh]# ssh -2 -v root@10.1.5.6
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.1.5.6 [10.1.5.6] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.1.5.6' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Thu Aug 9 16:41:30 2007 from 10.1.5.20
[root@Char ~]# exit</pre>

== Prerequisites ==

Make sure:
* you have at least one good backup of the virtual machine you intend to migrate
* rsync is installed on the target host
* In general you cannot migrate from bigger kernel versions to smaller ones
* By default, after the migration process is completed, the Container private area and configuration file are '''deleted''' on the old HN. However, if you wish the Container private area on the Source Node to not be removed after the successful Container migration, you can override the default <code>vzmigrate</code> behavior by using the <code>–r no</code> switch.

== vzmigrate usage ==

Now that the vzmigrate script will function, a little bit on vzmigrate.

<pre>This program is used for container migration to another node
Usage:
vzmigrate [-r yes|no] [--ssh=<options>] [--keep-dst] [--online] [-v]
destination_address <CTID>
Options:
-r, --remove-area yes|no
Whether to remove container on source HN for successfully migrated container.
--ssh=<ssh options>
Additional options that will be passed to ssh while establishing
connection to destination HN. Please be careful with options
passed, DO NOT pass destination hostname.
--keep-dst
Do not clean synced destination container private area in case of some
error. It makes sense to use this option on big container migration to
avoid syncing container private area again in case some error
(on container stop for example) occurs during first migration attempt.
--online
Perform online (zero-downtime) migration: during the migration the
container hangs for a while and after the migration it continues working
as though nothing has happened.
-v
Verbose mode. Causes vzmigrate to print debugging messages about
its progress (including some time statistics).</pre>

=== Example ===
Here is an example of migrating container 101 from the current HN to one at 10.1.5.6:

<pre>[root@OpenVZ .ssh]# vzmigrate 10.1.5.6 101
OPT:10.1.5.6
Starting migration of container 101 on 10.1.5.6
Preparing remote node
Initializing remote quota
Syncing private
Syncing 2nd level quota
Turning quota off
Cleanup</pre>

== Migrate all running containers ==

Here's a simple shell script that will migrate each container one after another. Just pass the destination host node as the single argument to the script. Feel free to add the -v flag to the vzmigrate flags if you'd like to see it execute with the verbose option:

for CT in $(vzlist -H -o veid); do vzmigrate --remove-area no --keep-dst $1 $CT; done

== Additional Information ==

You can also use this guide to migrate from OpenVZ to Proxmox VE.

If you use Proxmox VE, you may also want to read how to [http://pve.proxmox.com/wiki/Backup_-_Restore_-_Live_Migration Backup-Restore] a virtual machine, be it OpenVZ or KVM.

[[Category:HOWTO]]

Migration from one HN to another

2012-05-27T07:48:56Z

Kotakomputer:

{{wikify}}

The vzmigrate script is used to migrate a [[container]] from one [[Hardware Node]] to another.

== Summary ==

== Setting up SSH keys ==

You first have to setup SSH to permit the old HN to be able to login to the new HN without a password prompt. Run the following on the old HN.

<pre>[root@OpenVZ ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
74:7a:3e:7f:27:2f:42:bb:52:4c:ad:55:31:6f:79:f2 root@OpenVZ.ics.local
[root@OpenVZ ~]# cd .ssh/
[root@OpenVZ .ssh]# ls -al
total 20
drwx------ 2 root root 4096 Aug 11 09:41 .
drwxr-x--- 5 root root 4096 Aug 11 09:40 ..
-rw------- 1 root root 887 Aug 11 09:41 id_rsa
-rw-r--r-- 1 root root 231 Aug 11 09:41 id_rsa.pub
[root@OpenVZ .ssh]# scp id_rsa.pub root@10.1.5.6:./id_rsa.pub
The authenticity of host '10.1.5.6 (10.1.5.6)' can't be established.
RSA key fingerprint is 3f:2a:26:15:e4:37:e2:06:b8:4d:20:ee:3a:dc:c1:69.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.1.5.6' (RSA) to the list of known hosts.
root@10.1.5.6's password:
id_rsa.pub 100% 231 0.2KB/s 00:00</pre>

Run the following on the new HN.

<pre>[root@Char ~]# cd .ssh/
[root@Char .ssh]# touch authorized_keys2
[root@Char .ssh]# chmod 600 authorized_keys2
[root@Char .ssh]# cat ../id_rsa.pub >> authorized_keys2
[root@Char .ssh]# rm ../id_rsa.pub
rm: remove regular file `../id_rsa.pub'? y</pre>

Run the following on the old HN.

<pre>[root@OpenVZ .ssh]# ssh -2 -v root@10.1.5.6
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.1.5.6 [10.1.5.6] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.1.5.6' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Thu Aug 9 16:41:30 2007 from 10.1.5.20
[root@Char ~]# exit</pre>

== Prerequisites ==

Make sure:
* you have at least one good backup of the virtual machine you intend to migrate
* rsync is installed on the target host
* In general you cannot migrate from bigger kernel versions to smaller ones
* By default, after the migration process is completed, the Container private area and configuration file are '''deleted''' on the old HN. However, if you wish the Container private area on the Source Node to not be removed after the successful Container migration, you can override the default <code>vzmigrate</code> behavior by using the <code>–r no</code> switch.

== vzmigrate usage ==

Now that the vzmigrate script will function, a little bit on vzmigrate.

<pre>This program is used for container migration to another node
Usage:
vzmigrate [-r yes|no] [--ssh=<options>] [--keep-dst] [--online] [-v]
destination_address <CTID>
Options:
-r, --remove-area yes|no
Whether to remove container on source HN for successfully migrated container.
--ssh=<ssh options>
Additional options that will be passed to ssh while establishing
connection to destination HN. Please be careful with options
passed, DO NOT pass destination hostname.
--keep-dst
Do not clean synced destination container private area in case of some
error. It makes sense to use this option on big container migration to
avoid syncing container private area again in case some error
(on container stop for example) occurs during first migration attempt.
--online
Perform online (zero-downtime) migration: during the migration the
container hangs for a while and after the migration it continues working
as though nothing has happened.
-v
Verbose mode. Causes vzmigrate to print debugging messages about
its progress (including some time statistics).</pre>

=== Example ===
Here is an example of migrating container 101 from the current HN to one at 10.1.5.6:

<pre>[root@OpenVZ .ssh]# vzmigrate 10.1.5.6 101
OPT:10.1.5.6
Starting migration of container 101 on 10.1.5.6
Preparing remote node
Initializing remote quota
Syncing private
Syncing 2nd level quota
Turning quota off
Cleanup</pre>

== Migrate all running containers ==

Here's a simple shell script that will migrate each container one after another. Just pass the destination host node as the single argument to the script. Feel free to add the -v flag to the vzmigrate flags if you'd like to see it execute with the verbose option:

for CT in $(vzlist -H -o veid); do vzmigrate --remove-area no --keep-dst $1 $CT; done

== Additional Information ==

You can also use this guide to migrate from OpenVZ to Proxmox VE.

If you use Proxmox VE, you may also want to read how to [http://pve.proxmox.com/wiki/Backup_-_Restore_-_Live_Migration Backup-Restore] a virtual machine, be it OpenVZ or KVM.

[[Category:HOWTO]]

Control panels

2012-05-26T14:12:13Z

Kotakomputer: /* Free software / Open source (in alphabetical order) */

This page contains links to different control panels for OpenVZ, written by third parties. If you know the project that's missing here, please add it.

== Free software / Open source (in alphabetical order) ==
* BoxCtrl-VZ [http://www.boxctrl.com homepage] - Free and open source. Uses PHP, XML, and bash scripts. Lightweight. Released on Feb. 18th, 2012.
* FOSVM (Free Open Source Virtual Machine manager): [http://fosvm.sourceforge.net/ homepage] | Uses php and bash scripts, monitors bandwidth, Version 0.03a. Last updated 2009-05-18.
* HyperVM: [http://lxcenter.org/software/hypervm/ homepage] AGPL V3
* MiniCloud: [https://github.com/ryandoyle/minicloud homepage] | A set of client/server programs that provides similar functionality to the EC2 CLI tools for OpenVZ.
* OpenNode: [http://opennode.activesys.org/ homepage (English)] - Bare-metal ISO installer (CentOS based) providing openvz, kvm, libvirt and func out-of-box together with OpenNode Management Server appliance - containing also ajax Web Management Console with secure HTML5 vnc and ssh vm consoles.
* OpenVZ Web Panel [http://code.google.com/p/ovz-web-panel/ homepage] - Version 2.1. Written on Ruby. Automatic installer, backup/restore/clone, pretty interface with charts, multi-user/roles/server/lingual support, user requests, event logging and all NEW: remote API, IP management and VZ migrations. Version 2.1 released on 2012-05-02. Very active development.
* Proxmox Virtual Environment: [http://pve.proxmox.com Proxmox VE Wiki] - including bare-metal ISO installer. Requires 64bit Processor.
* SLKVM [http://solukom.com/software/slkvm homepage]: console scripts to handle vz virtualization in a two node cluster.
* unxsVZ OpenVZ Infrastructure Manager: [http://openisp.net/openisp/unxsVZ unxsVZ Trac Wiki] | Includes autonomic UBC adjusting and per container traffic graphs. Supports hot-spare clones and mount/umount conf file templates. Very active development. Last change to public svn code base July 24, 2011.
* VirtuoCP ( formerly Vtonf): [http://sourceforge.net/projects/vtonf/ homepage] | According to the documentation only runs on CentOS 4.5 or higher. Last update 2008-05-18.

== Proprietary / non-free ==
* Aventurin{e}: [http://www.aventurin.net/ homepage (English)]
* FluidVM: [http://www.fluidvm.com Home Page] free (trial) for up to 5 VE's
* NGASI: [http://www.ngasi.com/cloud/cp/index.zul homepage] is the Out-of-the-Box Platform-as-a-Service (PaaS) Solution. Quickly and easily create a cloud based P-a-a-S with 2 or more Virtuzzo/OpenVZ servers.
* oVZManager [http://www.ovzmanager.de homepage (Webinterface German and English)] Terminal and Rescue, IPv6 - Admin, Reseller, Customer - Windows Support over KVM -Free 30 day trial
* Plesk [http://www.parallels.com/plesk homepage], a control panel from Parallels.
* SolusVM [http://www.solusvm.com homepage], Appears to be reasonably priced. Also supports KVM, Xen PV & HVM. Soluslabs Ltd (the company behind SolusVM) announced SolusVM hosts over 153,000 OpenVZ containers across it's clientbase (stats October 2011). Highly maintained, Free 15 day trial & 24/7 support included in license fee. '''Now includes support for VSwap'''
* Sysvm :[http://sysvm.com Home Page], The Enterprise hybrid vps control panel with ipv6 and load balancing,formally known as vcPanel . It is the first centralized VPS control panel for managing VPS around the globe [http://sysvm.com/Demo Demo] 15 day free trial
* TekBASE: [http://teklab.de/ homepage /German)] Admin, Customer panel for openvz, game, stream and voice servers
* VDSmanager for Linux :[http://ispsystem.com/en/software/vdsmanager/ homepage (English)]
* vePortal: [http://www.veportal.com/ homepage (English)] - Widely used OpenVZ Management Panel.
* VirtPanel [http://www.virtpanel.com homepage], Support for Xen and VMware in the future.
* Virtualizor [http://www.virtualizor.com homepage] by Softaculous. Also supports Xen PV & HVM
* VZMaster [http://www.vzmaster.com homepage], [http://www.vzmaster.com/downloads/usermanual_vzmaster_1.0.0.pdf User Manual] -- We also provide complete OpenVz Distro based on Ubuntu Server distribution.

== Frozen projects ==
* EasyVZ: [http://easyvz.sourceforge.net/ screenshots] | [http://sourceforge.net/projects/easyvz sf.net project page] (little bit outdated, but working and free. Last update Feb 2007) (requires Unix/Linux)
* Mwamko: [http://mwamko.org/ homepage] Last activity May 2007
* RoboVZ: [http://sharesource.org/project/robovz homepage] {{forum|2559}} Lots of promises since announced in May 2007, nothing usable yet. Possibly GPL license. No activity in 2 years, calling it frozen.
* vpsAdmin (www.vpsadmin.org) - GPLv3 license, PHP+MySQL+Bash, Multi-server & Multilingual support, vpsAdmin 1.0 released on January 19, 2010
* VZ-Manager: [http://vzmanager.de/ homepage (German)] website shows apache default page (11. 02. 2010)
* WebVZ: [http://webvz.sourceforge.net/ homepage] Version 2.0 released September 7, 2008 (Moved to [https://github.com/shuaibzahda/webvz/commits/master GitHub], last commit 2009-03-20). Requires Ruby on Rails.
* Webmin: [http://www.webmin.com/ homepage] | [http://www.webmin.com/cgi-bin/search_third.cgi?search=OpenVZ OpenVZ plugin] | Version 1.0, last updated 2006-02-07
* Panenthe: [http://www.panenthe.com/ homepage (English)] • [http://www.panenthe.com/products/panenthe-media/cat_id=4/ Screen shots] <- does not exist anymore since 2010

== In development ==
* easyVZ! [http://www.easyVZ.org/ homepage]
* DTC-Xen [http://www.gplhost.com/software-dtc-xen.html homepage] - Currently being ported to OpenVZ by its main developers.

Control panels

2012-05-26T14:09:30Z

Kotakomputer: /* Free software / Open source (in alphabetical order) */

This page contains links to different control panels for OpenVZ, written by third parties. If you know the project that's missing here, please add it.

== Free software / Open source (in alphabetical order) ==
* BoxCtrl-VZ [http://www.boxctrl.com homepage] - Free and open source. Uses PHP, XML, and bash scripts. Lightweight. Released on Feb. 18th, 2012.
* FOSVM (Free Open Source Virtual Machine manager): [http://fosvm.sourceforge.net/ homepage] | Uses php and bash scripts, monitors bandwidth, Version 0.03a. Last updated 2009-05-18.
* HyperVM: [http://lxcenter.org/software/hypervm/ homepage] AGPL V3
* MiniCloud: [https://github.com/ryandoyle/minicloud homepage] | A set of client/server programs that provides similar functionality to the EC2 CLI tools for OpenVZ.
* OpenNode: [http://opennode.activesys.org/ homepage (English)] - Bare-metal ISO installer (CentOS based) providing openvz, kvm, libvirt and func out-of-box together with OpenNode Management Server appliance - containing also ajax Web Management Console with secure HTML5 vnc and ssh vm consoles.
* OpenVZ Web Panel [http://code.google.com/p/ovz-web-panel/ homepage] - Version 2.1. Written on Ruby. Automatic installer, backup/restore/clone, pretty interface with charts, multi-user/roles/server/lingual support, user requests, event logging and all NEW: remote API, IP management and VZ migrations. Version 2.1 released on 20012-05-02. Very active development.
* Proxmox Virtual Environment: [http://pve.proxmox.com Proxmox VE Wiki] - including bare-metal ISO installer. Requires 64bit Processor.
* SLKVM [http://solukom.com/software/slkvm homepage]: console scripts to handle vz virtualization in a two node cluster.
* unxsVZ OpenVZ Infrastructure Manager: [http://openisp.net/openisp/unxsVZ unxsVZ Trac Wiki] | Includes autonomic UBC adjusting and per container traffic graphs. Supports hot-spare clones and mount/umount conf file templates. Very active development. Last change to public svn code base July 24, 2011.
* VirtuoCP ( formerly Vtonf): [http://sourceforge.net/projects/vtonf/ homepage] | According to the documentation only runs on CentOS 4.5 or higher. Last update 2008-05-18.

== Proprietary / non-free ==
* Aventurin{e}: [http://www.aventurin.net/ homepage (English)]
* FluidVM: [http://www.fluidvm.com Home Page] free (trial) for up to 5 VE's
* NGASI: [http://www.ngasi.com/cloud/cp/index.zul homepage] is the Out-of-the-Box Platform-as-a-Service (PaaS) Solution. Quickly and easily create a cloud based P-a-a-S with 2 or more Virtuzzo/OpenVZ servers.
* oVZManager [http://www.ovzmanager.de homepage (Webinterface German and English)] Terminal and Rescue, IPv6 - Admin, Reseller, Customer - Windows Support over KVM -Free 30 day trial
* Plesk [http://www.parallels.com/plesk homepage], a control panel from Parallels.
* SolusVM [http://www.solusvm.com homepage], Appears to be reasonably priced. Also supports KVM, Xen PV & HVM. Soluslabs Ltd (the company behind SolusVM) announced SolusVM hosts over 153,000 OpenVZ containers across it's clientbase (stats October 2011). Highly maintained, Free 15 day trial & 24/7 support included in license fee. '''Now includes support for VSwap'''
* Sysvm :[http://sysvm.com Home Page], The Enterprise hybrid vps control panel with ipv6 and load balancing,formally known as vcPanel . It is the first centralized VPS control panel for managing VPS around the globe [http://sysvm.com/Demo Demo] 15 day free trial
* TekBASE: [http://teklab.de/ homepage /German)] Admin, Customer panel for openvz, game, stream and voice servers
* VDSmanager for Linux :[http://ispsystem.com/en/software/vdsmanager/ homepage (English)]
* vePortal: [http://www.veportal.com/ homepage (English)] - Widely used OpenVZ Management Panel.
* VirtPanel [http://www.virtpanel.com homepage], Support for Xen and VMware in the future.
* Virtualizor [http://www.virtualizor.com homepage] by Softaculous. Also supports Xen PV & HVM
* VZMaster [http://www.vzmaster.com homepage], [http://www.vzmaster.com/downloads/usermanual_vzmaster_1.0.0.pdf User Manual] -- We also provide complete OpenVz Distro based on Ubuntu Server distribution.

== Frozen projects ==
* EasyVZ: [http://easyvz.sourceforge.net/ screenshots] | [http://sourceforge.net/projects/easyvz sf.net project page] (little bit outdated, but working and free. Last update Feb 2007) (requires Unix/Linux)
* Mwamko: [http://mwamko.org/ homepage] Last activity May 2007
* RoboVZ: [http://sharesource.org/project/robovz homepage] {{forum|2559}} Lots of promises since announced in May 2007, nothing usable yet. Possibly GPL license. No activity in 2 years, calling it frozen.
* vpsAdmin (www.vpsadmin.org) - GPLv3 license, PHP+MySQL+Bash, Multi-server & Multilingual support, vpsAdmin 1.0 released on January 19, 2010
* VZ-Manager: [http://vzmanager.de/ homepage (German)] website shows apache default page (11. 02. 2010)
* WebVZ: [http://webvz.sourceforge.net/ homepage] Version 2.0 released September 7, 2008 (Moved to [https://github.com/shuaibzahda/webvz/commits/master GitHub], last commit 2009-03-20). Requires Ruby on Rails.
* Webmin: [http://www.webmin.com/ homepage] | [http://www.webmin.com/cgi-bin/search_third.cgi?search=OpenVZ OpenVZ plugin] | Version 1.0, last updated 2006-02-07
* Panenthe: [http://www.panenthe.com/ homepage (English)] • [http://www.panenthe.com/products/panenthe-media/cat_id=4/ Screen shots] <- does not exist anymore since 2010

== In development ==
* easyVZ! [http://www.easyVZ.org/ homepage]
* DTC-Xen [http://www.gplhost.com/software-dtc-xen.html homepage] - Currently being ported to OpenVZ by its main developers.