[sles-beta] Thinking about SLES11 migration testing, BTRFS and sub-volumes?
Darren Thompson
darrent at akurit.com.au
Tue Aug 19 20:40:14 MDT 2014
Matthias
Thanks again, looks like I'm going to have to have a good look at the
"Machine" module.
I have seen "kiwi" in the context of a "JEOS" install, I'm not sure I
understand it's role/involvement in a "inspect" / "validate" / "show" /
"build" migration using 'machine'.
Regards
Darren
Darren Thompson
Professional Services Engineer / Consultant
*[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]*
Level 3, 60 City Road
Southgate, VIC 3006
Mb: 0400 640 414
Mail: darrent at akurit.com.au <steve at akurit.com.au>
Web: www.akurit.com.au
On 20 August 2014 12:28, Matthias G. Eckermann <mge at suse.com> wrote:
> 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140820/228d9cc4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3692 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140820/228d9cc4/attachment.jpg>
More information about the sles-beta
mailing list