[sles-beta] Thinking about SLES11 migration testing, BTRFS and sub-volumes?
Darren Thompson
darrent at akurit.com.au
Tue Aug 19 21:11:31 MDT 2014
Filipe
Excellent, thanks for the links...
Looks like I've got some reading/researching to do ;-)
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 13:02, Filipe Lacerda <filipe.lacerda at lusolabs.com> wrote:
> Hi again,
>
> I've forgot this:)
>
> http://machinery-project.org/
>
> https://github.com/SUSE/machinery
>
> Two links to know more about this 'Machinery' stuff.
>
> 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 03:54, Filipe Lacerda wrote:
>
> Hi Darren,
>
> Install the "Advanced System Management" ISO available for download.
> Create a REPO based on that. You will find the "Machinery" in there.
>
> As for the 'Kiwi' and 'Machinery' , my own interpretation ( might be wrong
> dough) is that you inspect / validate / show the systems that you run
> 'Machinery' into, and gather information about them, compare systems (
> feature to be?!), etc.
>
> Then use 'Kiwi' to build new systems based upon the collected information.
> That's how SUSE Studio builds its images, using 'Kiwi' as backend.
>
> Now, how to do it? Still don't know :) But going to find out :)
>
> 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 03:40, Darren Thompson wrote:
>
> 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)
>>
>
>
>
> _______________________________________________
> sles-beta mailing listsles-beta at lists.suse.comhttp://lists.suse.com/mailman/listinfo/sles-beta
>
>
>
>
>
>
> _______________________________________________
> 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/2439e6a6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5382 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140820/2439e6a6/attachment.png>
-------------- 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/2439e6a6/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/2439e6a6/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/2439e6a6/attachment-0001.jpeg>
More information about the sles-beta
mailing list