Help Center/ Server Migration Service/ FAQs/ OS Compatibility and Migration Restrictions/ What Should I Consider and Prepare Before Migrating a Server Running Red Hat Enterprise Linux CoreOS?
Updated on 2025-07-30 GMT+08:00

What Should I Consider and Prepare Before Migrating a Server Running Red Hat Enterprise Linux CoreOS?

Red Hat Enterprise Linux CoreOS (RHCOS) is primarily designed to serve as the OS for container nodes. To ensure a successful migration, specific constraints, precautions, and preparatory steps must be considered.

Constraints

Item

Constraint

Read-only /sysroot

By default, the /sysroot directory is mounted as read-only with the chattr +i /sysroot command. Before the migration, you must remove the write protection of the /sysroot directory.

Read-only mount points

The /etc, /sysroot, /boot, and /usr directories are mounted as read-only by default. To proceed with the migration, you must remount them with read-write permissions.

/boot/efi not mounted by default

The /boot/efi directory is not mounted by default after system startup. You must mount it manually.

Servers with BIOS and GPT

File-level migration does not support BIOS boot partitions. As a result, servers with BIOS firmware and GPT partitioning cannot be migrated using this method. They must be migrated using block-level migration instead.

Automatic injection of Virtio drivers during the migration

RHCOS uses the initramfs kernel structure tied to its system version, so it is impossible to use the dracut command to inject drivers during the migration. If the virtio drivers are missing on the source server, the migration cannot proceed.

Precautions

  • Slow migration or synchronization: SMS migrates data by remotely replicating files. The time required for the initial replication or synchronization cannot be accurately estimated.
  • Impact on PVS-based mounting: During the migration, the target server inherits the disk settings of the source server. This may change the settings of any existing PVs and PVCs on the target server, thereby affecting the original mounting mode.

    In PVS-based mounting, PVs and PVCs are created in statically, and then PVs are bound to PVCs so pods can access them.

  • Container startup failure: SMS ensures file system consistency but does not ensure that containers can be started properly after migration.

Preparations

  • Remove the read-only attribute for /sysroot.
    The read-only attribute of /sysroot is enforced using the chattr +i /sysroot command. To remove the write protection for /sysroot, run the following command on the source server as user root:
    chattr -i /sysroot
  • Remount the mount points with read-write permissions.
    The /etc, /sysroot, /boot, and /usr directories are mounted as read-only by default. You need to remount them with read-write permissions on the source server as user root.
    mount -o remount,rw /etc
    mount -o remount,rw /sysroot
    mount -o remount,rw /boot
    mount -o remount,rw /usr
  • Manually mount the /boot/efi directory.

    RHCOS automatically unmounts the /boot/efi directory after startup, but the files in the mount point must be accessible for migration. You can run the blkid command to find the device for the /boot/efi directory. Typically, the device is the partition labeled LABEL="EFI-SYSTEM".

    Then, manually mount the partition. The command below is an example.
    mount /dev/vda2 /boot/efi
  • Check for the Virtio drivers.
    RHCOS uses the initramfs kernel structure tied to its system version, so it is impossible to use the dracut command to inject drivers during the migration. You can run the following command to check whether the initrd file includes VirtIO drivers. If they are missing, manually add them.
    lsinitrd {initrd-file} | grep virtio