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

Tue Aug 19 20:28:52 MDT 2014

Hello Darren and all,

On 2014-08-20 T 10:01 +1000 Darren Thompson wrote:

> I'm still unclear on one point though...
> 
> I believe an "in place" update from SLES11 => SLES12
> is tested and a viable option (please correct me if
> I'm incorrect).

Yes, in place upgrade from SLES 11 => SLES 12 is
supported. 

To compare with the "real world": when you upgrade your
house to have new electricity, new water pipes, new
central heating and new windows, all "in place" (instead
of the old), you still do not change the floor plan of
your house.

> That leaves the default ext3 file-system from SLES11
> so you miss out on the SLES12 roll-back advantage (as
> you have clearly explained).

Yes. 

To remain in the picture: to do that, you would have to
create a new basement slab -- while your house and all
the upper floors remain not yet upgraded -- and change
(parts of) the floor plan. ... Well ...

> I was under the impression that there was a straight
> forward process to go from ext3 => BTRFS but I now see
> that there are a lot of "prerequisites" that may be
> more difficult to meet.

We do support "offline in place" migration from ext3 =>
btrfs for data partitions.

> Assuming that the SLES11 => SLES12 is done in one step
> and the ext3 file-system is migrated as a separate
> process, is there actually a guide as to what steps
> are required to achieve that e.g.  {this is a guess at
> the process}
[....] 
> Is this close to correct and is it worth testing as a
> Beta tester???

Well, as said in my E-Mail before: instead of pursuing
this kind of excercise or migration path, I suggest to
have a look at "machinery" and "kiwi", as this is what
will be supported, once machinery is out of the
TechPreview status.

As a benefit, going forward this can not only be used to
go from 11 to 12, but also from physical to virtual or
cloud or vice versa. Lots of options, ...

Enjoy!

so long -
	MgE

> On 20 August 2014 08:48, Matthias G. Eckermann <mge at suse.com> wrote:
> 
> > 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)
> >

-- 
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)