Migration Restrictions for Containers

Listed below are the limitations you should take into account when deciding on the migration process.

Migrating to Containers on Linux servers:

• During the migration, all the filesystems available on your physical server are joined to one filesystem inside the Container - VZFS (Virtuozzo File System). Detailed information on VZFS is provided in the Virtuozzo File System subsection .
• If there are several IP addresses assigned to the physical server, all these IP addresses will be reassigned to one and the same device on the Parallels server - venet0 . This virtual network adapter is used to connect all the Containers on the given Parallels server among themselves and with the server. After the migration, you can create additional virtual network adapters inside the Container and decide what IP address to be assigned to what network adapter. For detailed information on how to create and manage Container virtual network adapters, turn to Managing Adapters in Containers .
• During the migration process, you may specify only one partition on the physical server which will be migrated to the Container together with all quotas imposed on it. All the other partitions of the server will be copied without keeping their quota limits. Moreover, the quota limits imposed on the selected partition will be applied to the entire Container after the server migration.
• While migrating your physical server running a Linux operating system with the security-enhanced (SE) Linux kernel, keep in mind that the SE Linux kernel is currently not supported by Parallels Server Bare Metal. Therefore, the Container where the server running the SE Linux distribution has been migrated will not support the SE security features.
• If any of your files and/or directories on the physical server have extended attributes associated with them, these attributes will be lost after the server migration.
• Raw devices on the physical server cannot and will not be migrated to the Container on the Parallels server.
• If you are running an application which is bound to the physical server MAC address, you will not be able to run this application inside the Container after the server migration. In this case, you can do one of the following:
  • If you are running a licensed application, you should obtain a new license and install the application inside the Container anew.
  • If you are running a non-licensed application, you can try to reconfigure the application and to make it work without being bound to any MAC address.
• If the migration process fails on the step of transferring files and directories from the physical server to the Container by means of rsync , the /vz/private/ CT_ID directory on the Parallels server will contain all the copied files and directories and may occupy a great amount of disk space. You can keep the directory, which will greatly speed up the repeated migration procedure, or manually remove the directory by using the rm utility.

Migrating to Containers on Windows servers:

• The following migration types are supported:
  • Physical servers running Windows Server 2008 can be migrated only to destination servers running Windows Server 2008.
  • Physical servers running Windows Server 2003 can be migrated only to destination servers running Windows Server 2003.
• Non-NTFS volumes cannot be migrated.
• After the physical server migration, the Quality of Service packet scheduler is disabled inside the Container irrespective of its state on the server before the migration began.
• You cannot migrate physical servers running the 32-bit version of Windows Server to destination servers running the 64-bit version of Parallels Containers, neither can you move physical servers running the 64-bit version of Windows Server to servers running the 32-bit version of Parallels Containers.