Prev Next

2.14. Performing Container-specific Operations¶

This section provides the description of operations specific to containers.

2.14.1. Reinstalling Containers¶

Reinstalling a container may help if any required container files have been inadvertently modified, replaced, or deleted, resulting in container malfunction. You can reinstall a container by using the prlctl reinstall command that creates a new container private area from scratch according to its configuration file and relevant OS and application templates. For example:

# prlctl reinstall MyCT

To keep the personal data from the old container, the utility also copies the old private area contents to the /vz/root/<UUID>/old directory of the new private area (unless the --skipbackup option is given). This directory may be deleted after you copy the personal data where you need.

The prlctl reinstall command retains user credentials base, unless the --resetpwdb option is specified.

2.14.1.1. Customizing Container Reinstallation¶

The default reinstallation, as performed by the prlctl reinstall command, creates a new private area for the broken container as if it were created by the prlctl create command and copies the private area of the broken container to the /old directory in the new private area so that no file is lost. There is also a possibility of deleting the old private area altogether without copying or mounting it inside the new private area, which is done by means of the --skipbackup option. This way of reinstalling corrupted containers might in certain cases not correspond exactly to your particular needs. It happens when you are accustomed to creating new containers in some other way than just using the prlctl create command. For example, you may install additional software licenses into new containers, or anything else. In this case you would naturally like to perform reinstallation in such a way so that the broken container is reverted to its original state as determined by you, and not by the default behavior of the prlctl create command.

To customize reinstallation, you should write your own scripts determining what should be done with the container when it is being reinstalled, and what should be configured inside the container after it has been reinstalled. These scripts should be named vps.reinstall and vps.configure, respectively, and should be located in the /etc/vz/conf directory on the hardware node. To facilitate your task of creating customized scripts, the containers software is shipped with sample scripts that you may use as the basis of your own scripts.

When the prlctl reinstall <UUID> command is called, it searches for the vps.reinstall and vps.configure scripts and launches them consecutively. When the vps.reinstall script is launched, the following parameters are passed to it:

Option	Description
`--veid`	Container UUID.
`--ve_private_tmp`	The path to the container temporary private area. This path designates where a new private area is temporarily created for the container. If the script runs successfully, this private area is mounted to the path of the original private area after the script has finished.
`--ve_private`	The path to the container original private area.

You may use these parameters within your vps.reinstall script.

If the vps.reinstall script finishes successfully, the container is started, and the vps.configure script is called. At this moment the old private area is mounted to the /old directory inside the new one irrespective of the --skipbackup option. This is done in order to let you use the necessary files from the old private area in your script, which is to be run inside the running container. For example, you might want to copy some files from there to regular container directories.

After the vps.configure script finishes, the old private area is either dismounted and deleted or remains mounted depending on whether the --skipbackup option was provided.

If you do not want to run these reinstallation scripts and want to stick to the default prlctl reinstall behavior, you may do either of the following:

Remove the vps.reinstall and vps.configure scripts from the /etc/vz/conf directory, or at least rename them;
Modify the last line of the vps.reinstall script so that it would read exit 128 instead of exit 0.

The exit code 128 tells the utility not to run the scripts and to reinstall the container with the default behavior.

2.14.2. Enabling VPN for Containers¶

Virtual Private Network (VPN) is a technology which allows you to establish a secure network connection even over an insecure public network. Setting up a VPN for a separate container is possible via the TUN/TAP device. To allow a particular container to use this device, do the following:

Make sure the tun.o module is already loaded before Virtuozzo is started:
```
# lsmod | grep 'tun'
```

Allow the container to use the TUN/TAP device:

# vzctl set MyCT --devnodes net/tun:rw --save

Configuring the VPN properly is a common Linux administration task, which is out of the scope of this guide. Some popular Linux software for setting up a VPN over the TUN/TAP driver includes Virtual TUNnel and OpenVPN.

2.14.3. Setting Up NFS Server in Containers¶

To set up an NFS server in a container, do the following:

Make sure the rpcbind, nfsd, and nfslock services are installed in the container.
Enable the NFS server feature for the container by running the prlctl set --features nfsd:on command on the hardware node. For example:
```
# prlctl set MyCT --features nfsd:on
```
If the container is running, stop it first. After enabling the feature, restart the container.

Note

You cannot perform live migration or create snapshots of containers with enabled NFS server feature.

Start the rpcbind service in the container.

# service rpcbind start
Starting rpcbind:                                          [  OK  ]

Start the nfs and nfslock services in the container.

# service nfs start
Starting NFS services:                                     [  OK  ]
Starting NFS quotas:                                       [  OK  ]
Starting NFS mountd:                                       [  OK  ]
Starting NFS daemon:                                       [  OK  ]
# service nfslock start
Starting NFS statd:                                        [  OK  ]

You can now set up NFS shares in the configured container.

2.14.4. Mounting NFS Shares on Container Start¶

If you configured an NFS share in the /etc/fstab file of a CentOS or RHEL-based container, and you need this NFS share to be mounted on container start, enable autostart for the netfs service with the chkconfig netfs on command.

2.14.5. Adding Multiple Virtual Disks to Containers¶

Even though new containers are created with just one virtual hard disk, you can add more disks to a container and keep the corresponding ploop images at locations of your choice, be it directly attached HDDs or SSDs or Virtuozzo storage. Such functionality allows creating more flexible containers, in which, for example, the operating system is kept on a fast SSD and user content is stored on a capacious HDD or Virtuozzo storage.

To add a virtual hard disk to a container, whether stopped or running, use the prlctl set --device-add hdd command. For example:

# prlctl set MyCT --device-add hdd --image /hdd/MyCT --size 100G --mnt /userdisk

This command adds to the configuration of the container MyCT a virtual hard disk with the following parameters:

name: hdd<N> where <N> is the next available disk index,
image location: /hdd/MyCT,
size: 102400 MB,
mount point inside the container MyCT: /userdisk. A corresponding entry is also added to container’s /etc/fstab file.

2.14.6. Restarting Containers¶

You can restart containers from the inside using typical Linux commands, e.g., reboot or shutdown -r. Restarting is handled by the vzeventd daemon.

If necessary, you can forbid restarting containers from the inside as follows:

To disable restarting for a specific container, add the ALLOWREBOOT="no" line to the container configuration file (/etc/vz/conf/<UUID>.conf).
To disable restarting globally for all containers on the server, add the ALLOWREBOOT="no" line to the global configuration file (/etc/vz/vz.conf).
To disable restarting globally except for specific containers, add the ALLOWREBOOT="no" line to the global configuration file (/etc/vz/vz.conf) and explicitly specify ALLOWREBOOT="yes" in the configuration files of the respective containers.

2.14.7. Creating SimFS-based Containers¶

In Virtuozzo 7, the simfs layout is based on bindmounts. When a simfs-based container is started, its private area is bindmounted to the root container area.

To create a simfs container:

Set VEFSTYPE=simfs in /etc/vz/vz.conf.
Run prlctl create <CT_name>.

The limitations of simfs in Virtuozzo 7 are:

No support for first- or second-level quotas.
No support for live migration of simfs-based containers.

Version 7.0.5 — Sep 29, 2017

Edit Raw Print

Prev Next