[sles-beta] Question: Migration tools for ISCSI config from SLES11
Darren Thompson
darrent at akurit.com.au
Tue Jul 8 17:01:05 MDT 2014
Team
I'm thinking of this simple test case:
SLES11 SP3 - ISCSI target server, set-up using YAST (that way there is a
finite set of likely configurations) - manually set-up ISCSI targets may be
just to broad a starting point.
Doing an "In place" upgrade using SLES12 media (or sources from an
"installation server" if additional add-ons/modules are required).
Issues I can foresee:
1. Conversion of SLES11 ISCSI - (STGT/TGT) configuration into a valid LIO
configuration; before, during migration or shortly afterwards.
2. Adding 'initiators ID's" and LUN details (LIO requires this additional
information which was optional or not required under SLES11)
3. Managing the scenario where multiple IP addresses were "bound" to the
ISCSI target (Te default in SLES11 was to bing all available IP addresses).
I agree that the LIO implementation is the preferred delivery of these
services (greater upstream support, faster, more features, "in Kernel" etc).
To all intents and purposes the "Conversion" to LIO could be done before or
after the OS migration (as you say some of the LIO infrastructure was in
SLES11) but I cannot see any alternative to doing some form of "migration".
If the ISCSI target configuration is changes it would have a sever "flow
on" effect to all "clients" {connected initiators} and could result in a
substantial amount of reworking of systems outside of the SLES host being
upgraded.
*I* certainly have systems that would require this migration of ISCSI
target configurations, but have no viability to other client configurations
so would only be guessing as to how severe this issue is to other customers.
Regards
Darren
On 9 July 2014 08:20, Donald Vosburg <dvosburg at suse.com> wrote:
> Actually, all the LIO target system Lee describes here is present in
> SLES11 SP3 already - as an option.
>
>
> https://www.suse.com/documentation/sles11/stor_admin/data/new_sles11sp3.html
>
> While it requires some additional configuration, performance is very
> good. It is the go-forward way for iSCSI - not just for SUSE but for the
> Linux community.
>
> As you point out, you may need a bit more understanding than simply
> running the YaST module.
> Especially consider that discovery is only allowed for enumerated iSCSI
> initiators - unlike the tgt used to be. You use the IQN of the initiator
> as the name.
>
> http://linux-iscsi.org/wiki/Main_Page
>
>
>
>
>
>
> Don Vosburg
> Sales Engineer
> SUSE Linux
> dvosburg at suse.com
> cell 765.278.2505
>
>
> <http://www.novell.com/>
>
> >>> Darren Thompson <darrent at akurit.com.au> 07/08/14 5:43 PM >>>
> Lee
>
> To get the migration recipe developed, is the appropriate form a "request
> for Improvement" or a SR at this time?
>
> As an aside, " The only iSCSI target that is discontinued in SLE12 is
> "iscsitarget"." => This is actually the service start script used by YAST
> (e.g. SLES11) when it configures STGT ISCSI targets so removal of
> this service script will stop the "legacy" configuration from continuing
> after the SLES12 upgrade.
>
> This is definitely more complex than it first appears.
>
> Darren
>
>
> On 9 July 2014 07:16, Lee Duncan <lduncan at suse.com> wrote:
>
>> On 07/07/2014 02:43 PM, Darren Thompson wrote:
>> > Lee
>> >
>> > From an "end user" perspective, the default tools are what YAST defaults
>> > to, in this case they have changed from SLES11 to SLES12.
>>
>> First of all, I believe many end users do not use Yast. Certainly the
>> "power users" do not. But that is a side point, is it not?
>>
>> I was not aware that Yast developers decided to switch the back-end
>> target they wanted to use.
>>
>> >
>> > Secondary question: How are we to upgrade a SLES11 server offering ISCSI
>> > resources to SLES12 without loosing all our ISCSI configuarions (This
>> > would require changing al the clients as well).
>>
>> During upgrade, if the system is using stgt, it will continue to work.
>> But it looks like Yast will no longer be able to manage it.
>>
>> Some users will wish to continue using stgt if it "just works", rather
>> than trying to migrate their data and configuration.
>>
>> There would be several steps required to move from stgt to
>> lio-utils/targetcli:
>>
>> - Must move the target configuration, including:
>> - IQN
>> - ACL (access controls)
>> - target portal group number
>> - back-end storage
>>
>> - Must either move the data from one store to another, or must use the
>> same back-end store (better). But not all back-end stores supported by
>> stgt may be supported by lio-utils/targetcli -- but let's hope not.
>>
>> Since the SLE 11 SP3 yast code knows stgt, it should be able to extract
>> all of this information, since it already has to do this to manage these
>> targets.
>>
>> And the SLE 12 code already seems to grok lio-utils/targetcli, since it
>> chose to use this for a back-end.
>>
>> So creating a migration recipe should not be too difficult.
>>
>> >
>> > Darren
>> >
>> >
>> > On 8 July 2014 00:25, Lee Duncan <lduncan at suse.com
>> > <mailto:lduncan at suse.com>> wrote:
>> >
>> > On 07/06/2014 02:08 PM, Darren Thompson wrote:
>> > > Team
>> > >
>> > > The ISCSI engine changes from SLES11 to SLES12
>> > >
>> > > In SLES11 they were (STGT/TGT) based but under SLES12 they are LIO
>> > based.
>> >
>> > This is not strictly true. The _prefered_ iSCSI target has changed
>> > upstream to kernel-based targets.
>> >
>> > The only iSCSI target that is discontinued in SLE12 is
>> "iscsitarget".
>> >
>> > >
>> > > Is thaere any tools to parse/migrate a valid SLES11 ISCSI
>> > configuartion
>> > > to a SLES12 ISCSI configuration, in particular I would like to
>> ensure
>> > > that what is presented to the ISCSI clients is identical so their
>> > > configuration is not scrambled.
>> >
>> > No tools that I know of.
>> >
>> > >
>> > > --
>> > >
>> > > Darren Thompson
>> > >
>> > > Professional Services Engineer / Consultant
>> > >
>> > > *cid:image001.jpg at 01CB7C0C.6C6A2AE0*
>> > >
>> > > Level 3, 60 City Road
>> > >
>> > > Southgate, VIC 3006
>> > >
>> > > Mb: 0400 640 414
>> > >
>> > > Mail: darrent at akurit.com.au <mailto:darrent at akurit.com.au>
>> > <mailto:steve at akurit.com.au <mailto:steve at akurit.com.au>>
>> > > Web: www.akurit.com.au <http://www.akurit.com.au>
>> > <http://www.akurit.com.au/>
>> > >
>> >
>> > --
>> > Lee Duncan
>> > SUSE Labs
>> >
>> >
>> >
>> >
>> > --
>> >
>> > Darren Thompson
>> >
>> > Professional Services Engineer / Consultant
>> >
>> > *cid:image001.jpg at 01CB7C0C.6C6A2AE0*
>> >
>> > Level 3, 60 City Road
>> >
>> > Southgate, VIC 3006
>> >
>> > Mb: 0400 640 414
>> >
>> > Mail: darrent at akurit.com.au <mailto:steve at akurit.com.au>
>> > Web: www.akurit.com.au <http://www.akurit.com.au/>
>> >
>>
>> --
>> Lee Duncan
>> SUSE Labs
>>
>
>
>
> --
>
> 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
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140709/d451e879/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UPHTIBR4.img
Type: image/jpg
Size: 3692 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140709/d451e879/attachment.jpg>
-------------- 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/20140709/d451e879/attachment-0001.jpg>
More information about the sles-beta
mailing list