Migrating btrfs root partition to ext4 in OVM
Recently I spent some time trying to migrate root partition to another FS type in an OVM environment. The target was to migrate root partition from btrfs to ext4. Here is a short outline of how it was done. 1. Stopped VM and backed up everything. If something goes wrong, you need to have the ability to go back and start again. 2. Copied root vdisk into two new disk images: root_old and root_new. 3. Since those disks are exact copies of the original disk, their partitions have UUIDs identical to original partitions. If you try to attach these vdisks to the same VM, Linux would think that its disks now have alternate paths available, and everything would be quite messy. Because of that, partitions UUIDs have to be changed before attaching them to target VM. 4. vdisks can be attached/detached to another VM by using
xm block-attach/
xm block-detach commands online. Then partitions' UUIDs can be changed with re-formatting (for swap and new root partitions), and with the help of file system utils such as xfs_admin or btrfstune. 5. After both vdisks have their partitions with refreshed UUIDs, they now can be attached to the target VM, and their new and old root FS can be mounted under /mnt/root_old and /mnt/root_new (which is now formatted as ext4). This is to simplify the sync process and avoid excluding irrelevant mount points under root. 6. Now we can simply rsync /mnt/root_old to /mnt/root_new, and have a copy of an old root partition on an ext4 mount point. 7. Next we need to update references to UUIDs in /mnt/root_new/etc/fstab to reflect UUIDs of the new partitions (if UUIDs are in use). Mount options/FS type should be changed, as well, at this step. 8. Similarly, a new vdisk should have its grub.cfg in its boot partition updated. This can be done by mounting boot partition and updating
/boot/grub2/grub.cfg with proper partition UUIDs.
sed is a good choice to do this with a single command. btrfs mount options should also be updated. 9. At this point, we have everything ready. One final thing to fix is rebuilding initial ramdisk image for the appropriate kernel. We have to add ext4 support in it, otherwise, the system won't recognize ext4 partition and will fail to boot. 10. Now everything is finally ready for the switch of original vdisk to the newly created one, and reboot. If all was done correctly, the system will boot successfully. It may be possible that there is a more simple approach to this task, however, this has worked fine. Replacing UUIDs and rebuilding initial ramdisk image were two steps which took time to understand and fix. Hope this helps!
