How to duplicate an OpenVZ SolusVM container then migrate it to a different node
In some instances, you may want to duplicate an OpenVZ VPS server and place it onto a different or even the same node. This saves time in setting up a new virtual server. Here we’re going to use vzdump to take a copy of the container, compress it then using SCP we will migrate the dump to a new node and finally restore the container.
Firstly, vzdump does not come packaged with OpenVZ so we need to install the repo, we’re going to use yum to install the software.
Duplicate an OpenVZ SolusVM container
Log in to the source server, the one with the container on you wish to duplicate and open the yum file to add the repo. You need to be logged in as the root user or a user with root privileges.
nano /etc/yum.repos.d/solusvm.repoNext, at the bottom of the file add the below code then save the file
[soluslabs]
name=Soluslab Repo
baseurl=http://repo.soluslabs.com/centos/$releasever/os/$basearch
mirrorlist=http://repo.soluslabs.com/centos/mirrors-soluslabs
gpgcheck=0
enabled=1Install VZDUMP
Next, we can install vzdump using yum
yum install vzdump -yOnce installed let’s find the CTID of the container you want to duplicate. You should already know the hostname so find it in the list using the following
vzlist -a
Look for the hostname and then make a note of the CTID number which is on the left of the list. Now we have the CTID we can go ahead and compress the container. For the purpose of this, we will use the CTID of 999.
Make a backup folder
mkdir /home/backupThen compress the container
vzdump --compress --dumpdir /home/backup 999Once complete the backup will be in the /home/backup folder. At this point if you simply want to restore it to the same node it’s currently on you can skip to the restore part below. If you want to move this to a different node and restore it, you can use SCP;
scp -P 22 /home/backup/vzdump-999.tgz [email protected]:/home- Swap -P 22 for any custom ssh port you use IE -P 5068
- Change the 999 for your CTID
- Swap 192.168.2.1 for the IP of the node the container will be restored to
Once the transfer is complete you can then log in to the destination node, the node you just moved the container to and as above open the /etc/yum.repos.d/solusvm.repo and add the below code
[soluslabs]
name=Soluslab Repo
baseurl=http://repo.soluslabs.com/centos/$releasever/os/$basearch
mirrorlist=http://repo.soluslabs.com/centos/mirrors-soluslabs
gpgcheck=0
enabled=1Save and close the file.
Destination Node
Save and close the file like we did on the source node then using yum install vzdump on the new node
yum install vzdump -yRestoring an OpenVZ Solusvm Container
To restore the dump you have made issue the below command on the destination server, the server which has the dump stored on it.
vzdump --restore /home/vzdump-999.tgz 1001- Swap 999 for your CTID which will be part of the dump name
- IMPORTANT give the dump a new unique CTID, not in use in your system, we used 1001
Once restored we now need to tell SolusVM that the container is there. We do this by switching to import mode
Import To SolusVM
In your SolusVM admin control panel navigate to;
Configuration > Settings > Other > Tick “Import Mode”
Next follow the below
1- Select Virtual Servers > Add Virtual Server
2- Select OpenVZ
3- Select the Node & Plan, then click Continue– The node you just placed the container backup on
4- Enter the container ID of the virtual server you want to import (as shown under vzlist on the host node) in the Container ID field- We used 1001 in the restore process so we would enter 1001 here
5- Fill in the rest of the fields
6- Click the Create Virtual Server button
7- Assign new IPs and change the main IP if required. Then reboot the server.
That should now be complete and you have duplicated an existing OpenVZ virtual server, migrated it to a new node and setup the container in SolusVM.
Correcting The network
On Debian / Ubuntu servers you may need to correct the interfaces file to reflect the new IP address of the container. For some reason when importing a container, specifically to a master the interfaces file is not updated correctly. The venet:0:0 should reflect the new IP address.
auto venet0:0
iface venet0:0 inet static
address NEW_GUEST_IP
netmask 255.255.255.255All other IP addresses assigned to the guest should be removed and the above file corrected. A reboot should then be performed from the control panel for the changes to take effect. If the guest can then ping outside addresses you can continue to assign more IPs in the usual way.
In some cases when rebooting the server from the control panel you may find the old IP addresses are added back into the interfaces file. This is because SolusVM doesn’t update the container’s configuration file with the correct IP. You can edit the containers config file using the below command. CTID is the container number, in our restore, we changed this to 1001 so swap CTID for your container number. Run this command on the node you have just restored the container too.
nano /etc/vz/conf/CTID.confThe file will look like this
CPUUNITS="1000"
VE_ROOT="/vz/root/$VEID"
VE_PRIVATE="/vz/private/$VEID"
VE_LAYOUT="simfs"
OSTEMPLATE="ubuntu-14.04-x86_64"
ORIGIN_SAMPLE="vswap-solus"
IP_ADDRESS="<strong>MAIN_CONTAINER_IP_HERE</strong>"
HOSTNAME="server.server.com"
NAMESERVER="8.8.8.8 8.8.4.4"
CPULIMIT="400"
CPUS="3"
AVNUMPROC="unlimited"
DISABLED="no"Enter the main virtual server IP address in here and reboot the server from the control panel. That will force the correct IP address to be placed into the interfaces file.
How was this article? – How to duplicate an OpenVZ SolusVM container then migrate it to a different node
More from Dedicated Servers
Enable Mod_RemoteIP – See Visitors Real IP address when using Cloudflare & Apache
If you are using Cloudflare on your Apache server you will always see Cloudflare IPs in your logs and not …
Fix 413 Request Entity Too Large Errors When Using NGINX
Just like Apache, NGINX imposes default limits on the size of files that can be uploaded. A 413 Request Entity …
Cloud-init Modules That Automate and Customize Deployments
Cloud-init is a popular way to automate deployments of instances in a cloud or none cloud environment. To save having …
