[sles-beta] Thinking about SLES11 migration testing, BTRFS and sub-volumes?
Darren Thompson
darrent at akurit.com.au
Tue Aug 19 20:34:57 MDT 2014
Filipe
Thank you, again a full and thorough reply...
It's good to know I'm not the only one considering these options...
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:21, Filipe Lacerda <filipe.lacerda at lusolabs.com> wrote:
> Hello Darren,
>
> Sorry to jump into the thread. I did that question outside the list, some
> weeks ago in Dusseldorf, while on a training at SUSE.
>
> Basically, a direct "in place" migration / live upgrade, will not be
> supported by default. It is possible to do it if you follow the "if's" list
> that Mathias wrote, and some more from your own scenarios. But due to the
> unlimited scenarios that you could create with other SLES versions, as well
> as the big changes that SLES 12 offers over the previous ones, a "regular"
> and default acceptance / supported path is not possible. I think I'm not
> wrong, am I Mathias?
>
> However, if for a particular landscape / scenario, you find a way to do
> it, meaning, if you create your own protocol, and managed to do it all the
> way by yourself, and the final result is a working machine / system, and it
> is able to run the *supportconfig* tool , and the support accepts the
> result as a valid machine / system, you will end up with a supported
> system. But it is a case by case possibility, and up to the SUSE support to
> decide if the result is support or not. But you will have to do the hard
> lifting by yourself.
>
> I had this in the past when migrating a big infrastructure from SLES 10 to
> SLES 11. Due to the client architecture done by a previous supplier, it was
> not possible an upgrade "in place" for those landscapes. SUSE support said
> primarily that the upgrade was not supported and a full fresh install had
> to be done for each system. Finally, I , together with SUSE support,
> managed to get an agreement. I did the hard lifting, and the final result,
> acceptable for me an my client, was presented to SUSE support. After
> supportconfig tool was run, the systems were analysed and accepted as
> valid, and therefore they were able to continue as supported.
>
> As I mentioned before, this is a SUSE support decision, and case by case.
> Therefore, by default, it is a no.
>
> From my experience, create a fresh install, and copy configs over the wire
> ( wicked will, as we already seen, read old style config files for
> networking) and data to the new volumes. Then your up to go. Or, create a
> fresh install, from the previous SLES version (same of the machine to be
> migrated) with the config, prerequisites and "if's" that were mentioned,
> copy data and configs over the wire, and then make the "in place" migration.
>
> I would love not to have to passed trough that again :) but in my case, i
> had no choice but to go as i explained. If you have a major client, or your
> own infrastructure to migrate, big, and fresh install is just not
> acceptable, either reason, go ahead and test it :) Otherwise, save your
> time. :) My two cents.
>
> There is a list of must have volumes, and partition scheme, for you to be
> able to get the "in place" upgrade working, but i cannot find it right now.
> This would be most helpful for you, if you want to create your own protocol
> to test the migration. Mathias might have it, or someone at SUSE ?!
>
> One note, Mathias talked about "Machinery". I've tested this new module.
> It is impressive. It will make me say goodbye to my custom scripts, for
> audit and data gathering of an infrastructure, and create a regular way to
> do it with almost no effort. And it is *scriptable* :) . From an
> operations point of view, it will standardize a lot of procedures for
> collect information , and to replicate that system using gathered
> information.
>
> Another note. If you install a SLES 12 and accept default partition
> scheme, it will be supported and with system rollback functionality and
> further support options. But if you/we decide to change the partition
> scheme / layout, rollback functionality might be broken and some forms of
> support might not be accepted.
>
> Hope i could be of some assistance.
>
> Cheers,
>
>
> --
> ------------------------------
> *Filipe Lacerda*
>
> *Chief Technical Officer ISO 27001 Lead Auditor* Tel: (+351)211 201 650
> Fax: (+351)211 201 634 Tmv: (+351)91 812 01 24 MIPE - Tecnologias de
> Informação Lda Avenida da Liberdade, 36 - 6º 1250-145 Lisboa
> http://www.lusolabs.com <http://url>
>
> Esta mensagem é confidencial e é propriedade da MIPE - Tecnologias de
> Informação Lda. Destina-se unicamente ao conhecimento do destinatário nela
> identificado. Caso não seja o destinatário, não está autorizado a ler,
> reter, imprimir, copiar, divulgar, distribuir ou utiliza-la, parcial ou
> totalmente. Caso tenha recebido esta mensagem indevidamente, queira
> informar de imediato o remetente e proceder à destruição de todas as cópias
> da mesma. Esta mensagem e ficheiros anexos foram tratados para estarem
> livres de vírus ou de qualquer outro defeito. MIPE - Tecnologias de
> Informação Lda não é responsável por perdas e danos resultantes do uso
> desta mensagem. O correio electrónico via Internet não permite assegurar a
> confidencialidade ou a correcta recepção das mensagens. Para mais
> informações acerca da MIPE por favor visite o nosso website em
> http://www.lusolabs.com
>
> *P* Antes de imprimir este e-mail pense bem se tem mesmo que o fazer. Há
> cada vez menos árvores! / Before printing this e-mail, assess if it is
> really needed
>
>
> On 20/08/14 01:01, Darren Thompson wrote:
>
> Matthias
>
> Thank you for a truly comprehensive answer.
>
> 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).
>
> That leaves the default ext3 file-system from SLES11 so you miss out on
> the SLES12 roll-back advantage (as you have clearly explained).
>
> 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.
>
> 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}
> 1. Boot from SLES12 media and go into "recovery mode"
> 2. Using appropriate tool make backup copy of '/', '/boot' and any other
> required file-systems.
> 3. Create appropriate BTRFS root filesystem using command line 'xxxx"
> which creates required '/' and "default' sub-volumes (including snapshots).
> 4. mount BTRFS '/' and sub-volumes in temporary location, restore backed
> up '/', '/boot' and other file-systems to new BTRFS file-system.
> 5. Chroot into BRTFS '/' and restore bootloader config etc **** or remount
> root filesystem *** Not sure of this part....
> 6. Reboot
> 7. setup snapper config etc
>
> Is this close to correct and is it worth testing as a Beta tester???
>
> Regards
> Darren
>
> 5.
>
>
> 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 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)
>>
>
>
>
> _______________________________________________
> sles-beta mailing listsles-beta at lists.suse.comhttp://lists.suse.com/mailman/listinfo/sles-beta
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140820/a8752770/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001k.png
Type: image/jpeg
Size: 5382 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140820/a8752770/attachment.jpeg>
-------------- 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/a8752770/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3692 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140820/a8752770/attachment-0001.jpeg>
More information about the sles-beta
mailing list