7.5
9.0 7.5
Docs menu
MENU

Converting Containers to Virtual Machines with the c2v-convert Tool

The c2v-convert tool converts a Virtuozzo Server 7 system container to a virtual machine. This tool is tested to work with containers based on the following operating systems:

  • AlmaLinux 9
  • AlmaLinux 8
  • CentOS 9
  • CentOS 8
  • CentOS 7
  • Debian 12
  • Debian 11
  • Debian 10
  • RockyLinux 8
  • Ubuntu 24.04
  • Ubuntu 22.04
  • Ubuntu 20.04
An Internet connection is required for c2v-convert to access guest OS vendor repositories.

To install c2v-convert, use the following command:

1

# yum install c2v-convert

Find below a list of options you can use when running the c2v-convert command.

1
2
3

c2v-convert [-h] [--version] [-q] [-y] [-v] [-b] [--timeout TIMEOUT]
            [--swap SWAP] [--target-state {keep,start,stop}] [--log LOG]
            [--temp TEMP] [-f FROM_FILE] [ct [ct ...]]
NameDescription
ctThe name of the container to be converted to a virtual machine.
-h, --helpProvides a list of flags used with the c2v-convert command.
--versionSpecifies the program's version number.
-q, --quietSkips the confirmation prompt and suppresses the output. Useful when calling from a script.
-y, --yesThe system automatically selects Y for all requests. The -y option assumes Ask me later for data collection by CEP.
-v, --verboseThe verbose mode provides detailed processing information.
-b, --batch_logCreates a batch log file that provides log records for the containers subject to conversion.
--timeout TIMEOUTThe operation timeout in minutes [5..60]. By default, it is 30 minutes.
--swap SWAPThe swap size in the target virtual machine in MB. The default value is 2,048 MB.
--target-state {keep,start,stop}

This option specifies the desired target state of virtual machine(s) after conversion:

1. keep—The resulting virtual machine(s) will keep the state of the converted container. If the container started before the conversion, the resulting virtual machine will be started. If the container stopped before the conversion, its state will remain stop.

2. stop—The resulting virtual machine(s) will be stopped, regardless of the container's state prior to the conversion.

3. start—The resulting virtual machine(s) will be started, regardless of the container's state before the conversion.

By default, the value of this option is keep.

--log LOGThe path to the directory to store log files.
--temp TEMPThe path to the directory to store temporary files. By default, it is /vz/tmp.
-f FROM_FILE, --from-file FROM_FILEThe path to the batch file.

Operation

The container-to-virtual-machine conversion consists of 11 stages:

  1. Checking the configuration of the container to be converted.
  2. Checking disk consistency and snapshot presence. (If a container has snapshots, it may take longer to complete the conversion.)
  3. Installing kernel and grub. (The performance of this stage depends on the Internet speed.)
  4. Creating a target virtual machine in a temporary directory.
  5. Converting the copies of the container’s disks to a virtual machine format.
  6. Connecting the disks to the target virtual machine.
  7. Configuring the target virtual machine’s network. (The network in the container is disconnected to avoid potential conflicts.)
  8. Installing Guest Tools on the target virtual machine.
  9. Executing the virt-v2v scripts in the target virtual machine.
  10. Starting the target virtual machine.
  11. The cleanup stage.

Conversion Time

The conversion time will depend on the node CPU and storage performance. Typically, a single container conversion completes within less than 5 minutes.

Conversion Fallback The resulting virtual machine acquires the name of the original container.

The source system container’s name will include the C2V_ prefix to identify the converted containers easily. The source system container is left in the stopped state without IP configuration as a fallback.

Interactive and Non-interactive Modes

You can convert containers in interactive and non-interactive modes:

  • Interactive mode encompasses default settings and is used without any flags. Use this mode to test the conversion process or if you have a few containers to convert.
  • Non-interactive mode is used when you have many containers to convert and want the system to do it automatically. For example, you can specify options, such as -y and -v, etc., to instruct that the system automatically selects y for all requests and provides detailed processing information.

Example 1: Converting a Single Container in Interactive Mode

Converting a single container in the interactive mode is a good way to test the conversion process for the container types you have in your infrastructure. For example, you may have 40 containers based on Debian 9 and 120 containers based on CentOS 7, with half of CentOS 7 containers having MariaDB installed. You can set up new Debian 9, CentOS 7, and CentOS 7 containers with MariaDB containers and test the conversion. Alternatively, you can create three clones of each type and test the conversion using these clones.

To convert a single container with the name centos7 to a virtual machine in the interactive mode, run c2v-convert:

1

# c2v-convert centos7

Here is an example output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

[root@vhs75]# c2v-convert centos7
The conversion process will restart the container multiple times and may take up to 30 minutes to complete.
Proceed? (y/n)
y
2024-10-18 17:17:27,863 INFO: Starting conversion for CT centos7.
2024-10-18 17:17:27,863 INFO Stage [1/11]: Preconversion checks for container
2024-10-18 17:17:36,259 INFO Stage [2/11]: Checking disks consistency
2024-10-18 17:17:53,707 INFO Stage [3/11]: Installing kernel and grub, preparing CT for conversion
2024-10-18 17:18:45,773 INFO Stage [4/11]: Creating the VM for migration
2024-10-18 17:18:47,297 INFO Stage [5/11]: Converting disks in container
2024-10-18 17:19:03,679 INFO Stage [6/11]: Connecting disks to VM
2024-10-18 17:19:03,679 INFO Stage [6/11]: No extra disks to add to fstab
2024-10-18 17:19:08,602 INFO Stage [7/11]: Configuring network
2024-10-18 17:19:08,855 INFO Stage [8/11]: Installing Guest Tools and Agent
2024-10-18 17:19:09,097 INFO Stage [9/11]: Run v2v migration
2024-10-18 17:19:47,525 INFO Stage [10/11]: Start VM after v2v migration
2024-10-18 17:20:17,973 INFO Stage [11/11]: Cleanup and correct VENV names
2024-10-18 17:20:18,444 INFO: Conversion complete.

The source container is stopped and available as fallback.
If the resulting VM experiences boot issues, use prlctl start C2V_centos7.

The resulting VM UUID: 1731524066
The resulting VM name: centos7
[root@vhs75]#

The new virtual machine acquires the name of the original container, and the system assigns the C2V_ prefix to the container’s name. After the conversion is complete, run prlctl list -a to confirm that the new virtual machine centos7 is present in the system:

Run prlctl list -a to view a list of available virtual environments:

1
2
3
4

[root@vhs75]# prlctl list -a | grep centos7
{a1fa15c6-8d74-4335-befc-1dfab51798b1}  stopped      -               CT C2V_centos7
{e734f5e2-f136-4cdd-a644-e58430956c6f}  stopped      -               VM centos7
[root@vhs75]#

Execute prlctl list -i to receive information on the new virtual machine centos7:

1

# prlctl list -i centos7

Use the prlctl start command to start the new virtual machine:

1

# prlctl start centos7

Example 2: Converting Multiple Containers in Interactive Batch Mode

You can specify multiple containers when calling c2v-convert. In this case, the tool will run in batch mode and convert the containers sequentially. Use the interactive batch mode if you want to oversee the conversion process of multiple containers.

To convert two containers centos7_1 and centos7_2 to virtual machines in the interactive batch mode, run the following:

1

# c2v-convert centos7_1 centos7_2

In this mode, you will be prompted to confirm the conversion of both containers. The tool will convert them one after another in the order you specified them.

In the following example, we will convert two system containers to virtual machines and will not request a batch log file. Here is an example output of c2v-convert for two containers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

[root@vhs75]# c2v-convert centos7_1 centos7_2
2024-10-18 17:29:30,248 INFO: Starting batch conversion of: centos7_1, centos7_2
2024-10-18 17:29:30,249 INFO: Validating the list of CTs
2024-10-18 17:29:30,441 INFO: Container list successfully validated
The conversion process will restart the containers multiple times and may take up to 60 minutes to complete.
Proceed? (y/n)
y
2024-10-18 17:29:32,547 INFO Container [1/2]: Starting conversion for CT centos7_1.
2024-10-18 17:29:32,547 INFO Container [1/2] Stage [1/11]: Preconversion checks for container
2024-10-18 17:29:41,311 INFO Container [1/2] Stage [2/11]: Checking disks consistency
2024-10-18 17:29:58,587 INFO Container [1/2] Stage [3/11]: Installing kernel and grub, preparing CT for conversion
2024-10-18 17:30:24,825 INFO Container [1/2] Stage [4/11]: Creating the VM for migration
2024-10-18 17:30:26,177 INFO Container [1/2] Stage [5/11]: Converting disks in container
2024-10-18 17:30:41,100 INFO Container [1/2] Stage [6/11]: Connecting disks to VM
2024-10-18 17:30:41,100 INFO Container [1/2] Stage [6/11]: No extra disks to add to fstab
2024-10-18 17:30:43,671 INFO Container [1/2] Stage [7/11]: Configuring network
2024-10-18 17:30:43,925 INFO Container [1/2] Stage [8/11]: Installing Guest Tools and Agent
2024-10-18 17:30:44,174 INFO Container [1/2] Stage [9/11]: Run v2v migration
2024-10-18 17:31:21,901 INFO Container [1/2] Stage [10/11]: Start VM after v2v migration
2024-10-18 17:31:52,343 INFO Container [1/2] Stage [11/11]: Cleanup and correct VENV names
2024-10-18 17:31:52,821 INFO Container [1/2]: Conversion complete.

The source container is stopped and available as fallback.
If the resulting VM experiences boot issues, use prlctl start C2V_centos7_1.

The resulting VM UUID: 1744630373
The resulting VM name: centos7_1
2024-10-18 17:31:52,850 INFO Container [2/2]: Starting conversion for CT centos7_2.
2024-10-18 17:31:52,850 INFO Container [2/2] Stage [1/11]: Preconversion checks for container
2024-10-18 17:32:00,045 INFO Container [2/2] Stage [2/11]: Checking disks consistency
2024-10-18 17:32:17,236 INFO Container [2/2] Stage [3/11]: Installing kernel and grub, preparing CT for conversion
2024-10-18 17:33:06,333 INFO Container [2/2] Stage [4/11]: Creating the VM for migration
2024-10-18 17:33:07,662 INFO Container [2/2] Stage [5/11]: Converting disks in container
2024-10-18 17:33:21,350 INFO Container [2/2] Stage [6/11]: Connecting disks to VM
2024-10-18 17:33:21,351 INFO Container [2/2] Stage [6/11]: No extra disks to add to fstab
2024-10-18 17:33:25,016 INFO Container [2/2] Stage [7/11]: Configuring network
2024-10-18 17:33:25,277 INFO Container [2/2] Stage [8/11]: Installing Guest Tools and Agent
2024-10-18 17:33:25,506 INFO Container [2/2] Stage [9/11]: Run v2v migration
2024-10-18 17:34:03,603 INFO Container [2/2] Stage [10/11]: Start VM after v2v migration
2024-10-18 17:34:34,054 INFO Container [2/2] Stage [11/11]: Cleanup and correct VENV names
2024-10-18 17:34:34,527 INFO Container [2/2]: Conversion complete.

The source container is stopped and available as fallback.
If the resulting VM experiences boot issues, use prlctl start C2V_centos7_2.

The resulting VM UUID: 1920612944
The resulting VM name: centos7_2
2024-10-18 17:34:34,556 INFO: Containers successfully converted: centos7_1 centos7_2
[root@vhs75]#

Now, the output shows not only the conversion stage but also the currently processed and total number of containers to convert: Container [1/2] and Container [2/2]. It allows you to see how many containers have already been processed at a glance.

Logging in Batch Mode

If you specified more than one container to convert, c2v-convert will create a separate log file for each container in the working directory you started the conversion process. You may add the -b option to create a separate batch log file that will contain brief log information on each container and/or --log to specify the name of the folder to store log files with detailed information on each container:

1

# c2v-convert -b --log /tmp centos7_1 centos7_2

Conversion in Batch Mode Using GNU Screen

When converting containers in batch mode, we recommend using the GNU screen terminal program. It creates a virtual terminal persistent across SSH sessions and ensures a strong connection to the target host. With Screen, the program will continue working in the screen session in case of any SSH session disruption.

To start a screen session, run the following in your terminal:

1

$ screen

To detach from the screen session, execute Ctrl-a+d.

To reattach or resume your screen session, run as follows:

1

$ screen -r

Example 3: Converting Multiple Containers in Non-Interactive Batch Mode

The non-interactive batch mode is useful when converting many containers in a pre-defined maintenance window. Use the -y option to instruct the system to select y for all requests automatically. As with the interactive batch mode, we recommend starting c2v-convert in the non-interactive mode in the GNU screen.

Batch File

To simplify calling c2v-convert on large numbers of containers, we recommend preparing a batch file with container names or CTIDs that you want to convert during a maintenance window. The format of the batch file is as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

centos7-ct1
centos7-ct2
centos7-ct3
centos7-ct4
centos7-ct5
ubuntu20-1
ubuntu20-2
ubuntu20-3
ubuntu20-4
ubuntu20-5

It is possible to generate such a file based on the prlctl list output. For example, to create a batch file with the names of all containers apart from containers with Virtuozzo Automator, Virtuozzo Storage UI, and PowerPanel, use the following command:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

[root@vhs75]# prlctl list --vmtype ct -aHo name | egrep -v "va-mn|pp|vstorage-ui" > cts-to-convert.txt
[root@vhs75]# cat cts-to-convert.txt
100500
1113
200701
3000
3011
ubuntu20_ct
nfs-server
prometheus
1237612346
[root@vhs75]#

You can use different batch files for containers based on a specific template, end-user, or any other criteria you select. For example, if you confirmed a maintenance window with an end user owning 20 containers.

Example: Converting Containers in Unattended Mode Using Batch File

In this example, we want to convert all containers containing centos7 and dev in their names. We aligned the maintenance window with the users of said containers, and there are enough of them to justify running conversion in the quiet and unattended mode. We will create a batch file based on the prlctl list output and our filter and a batch log file to review once the conversion process ends.

We will be running the conversion in a screen session.

Create Batch File

To create a batch log file, we will use prlctl list and grep:

1
2
3
4
5
6
7
8
9

[root@vhs75]# prlctl list -aHo name | grep dev.*centos7 > cts-to-convert.txt
[root@vhs75]# cat cts-to-convert.txt
dev-112-centos7-spam
dev-11412-centos7-mail
dev-13412-centos7-proxy
dev-6759-centos7-proxy
dev-76224-centos7-mail
dev-8571-centos7-mail
[root@vhs75]#

Execute Conversion

Let’s open a screen session:

1

[root@vhs75]# screen

Next, we will call c2v-convert by specifying the following:

  • The -q flag to run the conversion in quiet mode, i.e., without confirmation prompts and output.
  • The -b flag to create a high-level batch log.
  • -f to point the tool to the file with container names.

Here is the command:

1
2

[root@vhs75]# c2v-convert -q -b -f ./cts-to-convert.txt
...

Because we are using quiet mode, nothing will be printed on the screen. Let’s detach from the screen session (Ctrl-a+d) and look at the batch log file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

[root@vhs75]# screen
[detached from 81468.pts-1.vhs75]
[root@vhs75]# ll
total 48
-rw-r--r-- 1 root root  1314 Oct 18 18:06 20241018-18-05-batch-conversion.log
-rw-r--r-- 1 root root 33818 Oct 18 18:06 20241018-18-05-dev-112-centos7-spam-conversion.log
-rw-r--r-- 1 root root   136 Oct 18 17:57 cts-to-convert.txt
[root@vhs75]#  tail -f 20241018-18-05-batch-conversion.log
2024-10-18 18:07:56,297 INFO Container [1/6]: Conversion complete.

The source container is stopped and available as fallback.
If the resulting VM experiences boot issues, use prlctl start C2V_dev-112-centos7-spam.

The resulting VM UUID: 1839266756
The resulting VM name: dev-112-centos7-spam
2024-10-18 18:07:56,327 INFO Container [2/6]: Starting conversion for CT dev-11412-centos7-mail.
2024-10-18 18:07:56,327 INFO Container [2/6] Stage [1/11]: Preconversion checks for container
2024-10-18 18:08:03,546 INFO Container [2/6] Stage [2/11]: Checking disks consistency

As we can see, the conversion process is underway. Running the conversion in quiet mode allows you to call it from external automation systems or scripts.

Troubleshooting

Running the Tool in Verbose Mode

In case the conversion process fails without a clear error message, rerun the conversion with the --verbose option:

1

# c2v-convert -y --verbose myct

A verbose output provides much more information about the steps performed, which is useful for troubleshooting. Here is an example of c2v-convert running in the verbose mode:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

[root@vhs75 ~]# c2v-convert -y --verbose myct
2024-11-01 12:42:38,432 DEBUG: Starting conversion with Namespace(batch_log=False, ct=['myct'], from_file=None, log=None, quiet=False, swap=2048, target_state='keep', temp='/vz/tmp/c2v', timeout=30, verbose=True, yes=True)
2024-11-01 12:42:38,433 DEBUG: Command "modprobe nbd max_part=8" started.
2024-11-01 12:42:38,435 DEBUG: Command "modprobe nbd max_part=8" output:

2024-11-01 12:42:38,435 DEBUG: Command "modprobe nbd max_part=8" finished.
2024-11-01 12:42:38,435 DEBUG: Command "mkdir -p /vz/tmp/c2v" started.
2024-11-01 12:42:38,437 DEBUG: Command "mkdir -p /vz/tmp/c2v" output:

2024-11-01 12:42:38,437 DEBUG: Command "mkdir -p /vz/tmp/c2v" finished.
2024-11-01 12:42:38,437 DEBUG: Command "prlctl list myct" started.
2024-11-01 12:42:38,469 DEBUG: Command "prlctl list myct" output:
UUID                                    STATUS       IP_ADDR         T  NAME
{653ae3d9-c475-4922-b7dc-99ee75bc2db9}  running      14.11.182.2     CT myct

2024-11-01 12:42:38,469 DEBUG: Command "prlctl list myct" finished.
2024-11-01 12:42:38,534 DEBUG: Checking CT myct status
2024-11-01 12:42:38,566 INFO: Starting conversion for CT myct.
2024-11-01 12:42:38,567 INFO Stage [1/11]: Preconversion checks for container
2024-11-01 12:42:38,567 DEBUG Stage [1/11]: Checking CT myct status
2024-11-01 12:42:38,599 DEBUG Stage [1/11]: Command "prlctl snapshot-list myct" started.
2024-11-01 12:42:38,634 DEBUG Stage [1/11]: Command "prlctl snapshot-list myct" output:
PARENT_SNAPSHOT_ID                      SNAPSHOT_ID

2024-11-01 12:42:38,634 DEBUG Stage [1/11]: Command "prlctl snapshot-list myct" finished.
2024-11-01 12:42:38,702 DEBUG Stage [1/11]: CT RAW HW list myct:
        cpu sockets=1 cpus=unlimited cores=unlimited VT-x hotplug accl=high mode=64 cpuunits=1000 ioprio=4
        memory 512Mb hotplug
        video 0Mb 3d acceleration=off vertical sync=yes
        memory_guarantee auto
        hdd0 (+) scsi:0 image='/vz/private/653ae3d9-c475-4922-b7dc-99ee75bc2db9/root.hdd' type='expanded' 10240Mb mnt=/ state=connected subtype=virtio-scsi
        venet0 (+) type='routed' ips='14.11.182.2/255.255.255.0 '
2024-11-01 12:42:38,702 DEBUG Stage [1/11]: Detected following HW list: {'disk': {'hdd0': {'scsi': '0', 'image': '/vz/private/653ae3d9-c475-4922-b7dc-99ee75bc2db9/root.hdd', 'type': 'expanded', 'mnt': '/', 'state': 'connected', 'subtype': 'virtio-scsi'}}, 'net': {'venet0': {'type': 'routed', 'ips': '14.11.182.2/255.255.255.0'}}, 'cpu': {'sockets': '1', 'cpus': 'unlimited', 'cores': 'unlimited', 'VT-x': True, 'hotplug': True, 'accl': 'high', 'mode': '64', 'cpuunits': '1000', 'ioprio': '4'}, 'memory': {'size': '512Mb', 'hotplug': True}, 'video': '0Mb 3d acceleration=off vertical sync=yes', 'memory_guarantee': 'auto'}

Falling Back to Converted Container in Case of Unsuccessful Conversion

If the conversion is a success, but the resulting virtual machine does not work as expected, you can:

  1. Stop the converted virtual machine centos7:

    1

    # prlctl stop centos7

  2. Assign the transferred IP address back to the converted container C2V_centos7:

    1

    # prlctl set C2V_centos7 --device-add <venetX|netX> --ipadd <addr>

  3. Start the container:

    1

    # prlctl start C2V_centos7

When running the c2v-convert utility on Virtuozzo Server, macOS users may encounter the locale-related error message while logging into Virtuozzo Server:

1

warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory

During conversion, it may cause errors as follows:

1

...AttributeError: 'NoneType' object has no attribute 'stdout'

or

1

...UnicodeEncodeError: 'ascii' codec can't encode character '\u201c' in position 679: ordinal not in range(128)

To avoid this issue, add the following to the /etc/environment file on Virtuozzo Server and log into it again:

1
2

LANG=en_US.UTF-8
LC_ALL=en_US.UTF-8

Unmounted Disk After Conversion

If a container to be converted has additional disks, add information about the mount point of these disks in the configuration file unless it has been added before:

1

# prlctl set MyCT --device-set hdd1 --mnt /userdisk

Otherwise, the disk will be unmounted after conversion and will need to be mounted manually.

Usage Data Collection

The c2v-convert tool collects anonymous statistics about conversion attempts if the host where the tool is used participates in the Customer Experience Program (CEP). It helps Virtuozzo proactively identify issues in the tool’s operation. The system will not gather personal data, such as hostnames, IP addresses, names, etc. The hosts already enrolled in CEP will send conversion statistics by default. If the host with the tool used on it does not participate in CEP, no statistics will be collected.

Below is a list of data gathered by CEP:

  • Unique identifier based on the CTID of the container subject to conversion
  • Conversion attempt date
  • Conversion result: success or failure. For failed conversions, the step where the conversion failed and the reason
  • The container OS template of the attempted conversion
  • The container App template of the attempted conversion
  • The number and type of NICs attached to the container
  • The number and size of disks attached to the container
  • The execution time of the conversion

Here is an example of the collected data:

1
2
3
4
5

Saving following information for CEP: {'ct_id': '1000', 'date': '2024-12-05 17:51:44.048897',
'success': True, 'reason': None, 'fail_step': 0, 'ct_os': 'centos7', 'ct_app': 'directadmin',
'nics': [{'name': 'venet0', 'type': 'routed'}, {'name': 'net0', 'network': 'Bridged'}],
'disks': [{'name': 'hdd0', 'size': '10240'}, {'name': 'hdd1', 'size': '65536'}],
'execution_time': 207}