Reformatting root disk


#1

Once I have upgraded my BigV VM to Debian Stretch, I would like to reformat the root partition as btrfs. However, as btrfs-convert has had several significant bugs, I don’t want to use that. I want to create a new btrfs filesystem and copy the files from the existing root. I am very happy with Linux filesystem admin and tools and have done the equivalent process with real disks and real systems many times in the past.

What is the best way to do that for my VM? I am considering several approaches:

  1. Get Bytemark to do it for me (take my existing disk image, create a new btrfs-formatted disk image, copy all the files, replace the root disk on my VM with the new disk image). But, as far as I know, this is not a service Bytemark offer. And I do want to keep both costs and downtime to a minimum.

  2. Add a new SSD disk to my VM. Create the filesystem and copy the files over. Boot and test the new root disk. Set up the new disk as my boot disk replacing the existing disk. This is the way I would do it with my physical systems. Unfortunately, the last step doesn’t seem to be supported: there is no way to remove a root disk. I’m not even sure if I can set up to boot from anything other than /dev/vda. Would Bytemark support be able to help me do this?

  3. Expand the SSD disk for my VM. Create a new partition, format with btrfs and copy the files over. Boot and test the new partition and set it up to boot. Unfortunately Bytemark do not offer any way to shrink the root disk again so I end up paying for the space occupied by my old root. Of course, I can use it for data but I will be paying for it for ever.

  4. Boot a CD image. Copy my existing root partition to my archive disk. Create a new btrfs filesystem in the root partition space. Copy the files back from the saved partition. Boot and test it works. This is not risk-free and is time-consuming to do and even more so if I need to rollback. So, quite a lot of downtime.

  5. There is a variant of option 4. I could create the new btrfs partition on a new disk (SSD or archive, or just a file on an archive disk). This would mean that assembling the new root could be done with the system still running (with a quick final rsync in single user mode to bring over the last few changes to the old root). If it is possible to boot from a non-root disk I could even boot it and test it before destroying the old root partition. Once tested I would copy the new partition over the old root partition and reboot hoping it all worked! The temporary disk could then be removed.

Option 4 (or the option 5 variant) seems to be the only choice, unless there is some way to replace the root disk. It can be made a little bit safer by making use of the new backup service (when it is available for my VM).

Has anyone else done this? Anyone have any comments? Most importantly, anyone see any problems with my options 4 or 5?


#2

Hi Graham,

Method 5 sounds plausible to me. You might also find Shrinking VM Disks interesting, especially at the end. Look out for duplicate UUIDs and labels after you’ve copied your image if it came from a partition rather than a file. You may be altering the destination’s ones after the copy anyway to have it match what’s sought at boot time.

Cheers, Ralph.


#3

Why not create a new VM, then migrate all your data to it? Always seems easier than upgrading and fussing about with all those little bugs that inevitably crop up.