[sles-beta] Thinking about SLES11 migration testing, BTRFS and sub-volumes?

Matthias G. Eckermann mge at suse.com
Tue Aug 19 16:48:00 MDT 2014


Hello Darren and all,

On 2014-08-20 T 07:51 +1000 Darren Thompson wrote:
 
> Just thinking out loud, please ignore if not relevant
> to you...

the question indeed is important, thus let me answer in
two steps:
I. What we do (not) support and why (not)
II. How you may achieve (soon) what you are looking for


Ad I. What we do (not) support and why (not)

Let me share some SUSE internal discussion (from 2012
already): Back then we discussed, if we should support
the in place migration of SLES 11 to SLES 12 including a
migration of ext3 to btrfs.

And we decided against this for one simple reason: complexity.

If you look at the changes from SLES 11 to SLES 12:
- default filesystem	ext3	 -> btrfs
- bootloader		grub1	 -> grub2
- init system		sysvinit -> systemd
- network		ifcfg	 -> wicked
...

The "logic" how to migrate things is built into YaST (and
AutoYaST / AutoUpgrade) respectively, and we do cover
migration of bootloader, init system, network and more
with this (YaST based) migration path.

We hesitated to support an inplace migration from ext3 to
btrfs for the "/" filesystem, though, and we are not
supporting it. Why?
1. The inplace migration of ext3 to btrfs requires some
   free space on the source file system. 
2. The inplace migration only works for ext3 filesystems
   which have been created with specific options; this
   for example does not always work for filesystems
   created by SLES 10 and early versions of SLES 11.
3. The disk partitioning must be prepared to have space
   for the Grub2 first- and second-stages. This is not
   true for all partitionings created with older SLES
   versions (including early SLES 11 versions).
4. People who are thinking about migrating "/" to btrfs
   most probably want to do so, to enable snapshot/
   rollback as the _real_ benefit.
   For _this_ to work, though, you would get rid of the
   the "/boot" partition, as for rollback to work
   "/boot" must be on the same file system as "/",
   and it not even can be a btrfs subvolume, ...

Now, if "/" would be a migratable ext3 filesystem and if
it would have enough space and even enough space to cover
/boot, and if the bootloader pieces would fit on the disk,
and if you would be able to run an AutoYaST profile on it,
to help migrating the other stuff mentioned above, ...  

=> Too many "ifs". Too many ifs to test this, and too many
ifs to make this reliably working and supported. 
 
> I know that you can do an "in place" migration from
> SLES11 to SLES12 I know that you can do an "in place"
> migration of ext3 (the SLES11 default) to BTRFS (the
> SLES12 default)
> 
> Done correctly an in-place SLES11 => SLES12 should
> produce a server that is indistinguishable from a clean
> install of SLES12 (except for retaining data etc)

I agree that as a "manual" process you might be able to
migrate a SLES 11 SP3 system to SLES 12 this way.

It's an error prone process, and you may end up losing
data, e.g. if you have to re-partition to create space
for the Grub2 bootloader pieces on your disk.

However,let's think about what you really want. Let's
start more theoretically ...


II. How you may achieve (soon) what you are looking for

You want a SLES 12 system, with snapshot/rollback for the
"full system" without the need to reconfigure and tweak
everything you did configure and tweak for SLES 11.

Is this the correct understanding?

> How do you set up the other "default" BTRFS
> sub-volumes and how do you move/migrate the existing
> subdirectories into the default BTRFS sub-volumes.
> 
> Is there a migration tool/script that would help to
> "complete" the ext3 => BTRFS migration process?

If yes, there are obviously two ways to achieve your goal:

1. In place migration; as discussed above, and not
   supportable / not supported.

2. A way to preserve your complex configurations (which
   you did in SLES 11 ) and re-apply them on SLES 12.
   Some tool, which
   - "inspects" your SLES 11 system
   - "validates" and normalizes your SLES 11 configuration
   - allows you to "show" and change the configuration
   - helps you to "build" a SLES 12 system based on your
     (former) configuration (using KIWI).

Do you remember the steps of "inspect" / "validate" /
"show" / "build"? 

It's what the tool "machinery" in the "Advanced Systems
Management Module" is meant for. And while the tool is not
fully there yet, where we want it to be, it is the most
promising way of migrating complex configurations between
operating system versions or even operating systems going
forward. 

Hope this helps to explain SUSE's plans in this area.

So long -
	MgE

-- 
Matthias G. Eckermann     Senior Product Manager   SUSE® Linux Enterprise
Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
SUSE LINUX Products GmbH  Maxfeldstraße 5          90409 Nürnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)


More information about the sles-beta mailing list