From Dick.Waite at softwareag.com Mon Jul 7 03:10:42 2014 From: Dick.Waite at softwareag.com (Waite, Dick) Date: Mon, 7 Jul 2014 09:10:42 +0000 Subject: [sles-beta] RC1 on Friday - Upgrade with Server and SDK - VMware - Workstation Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D53854D46@hqmbx6.eur.ad.sag> Grand New Day, Back from looking for Nessie in Loch Ness, grand countryside but no Nessie. Looking over the emails I see some good words from SUSE people. Q1 ? Will RC1 on Friday allow an update of SLE 11-SP3 to SLE 12-0 using server and SDK? Q2 ? When does one run VMware tools or do you let it run itself? Q3 ? I only added the extra monitors to show how much the Gnome shell was using, my day-2-day monitor is ?xosview? which did show me a high usage. Ran a SLE12-b9 on zLinux on Saturday and did not see a high usage. A4 ? Reply to ?cups et al? I would like very much to check our applications with your grand applications, but until I can get an upgrade of SLE 11-SP3 running both you and I our sitting on the fence. My understanding at the start of the Beta was to check SAG applications that run on SLE11 will upgrade and run on SLE 12 without out any / minimal manual intervention. I did not want to test that SUSE?s OS enviroment was working, that I think is SUSE part of the bargain and I don?t have the knowledge or time to fix OS issues? I did create a SR and chatter on how /tmp and /var/tmp etc are going to be kept clean now that ?cron? seems to have also gone the way of KDE, I expect at the same meeting. From my point of view SUSE can rightly remove ?cron? but I also think they should provide samples with what ever replaced it so that there ?customers? can work through many hundreds a machine amending all the cron to ?whatever?, or the could in the update stage do the work for us, a grand service, doing no more that the ?cron? clean up does at the moment, or even better still, let ?cron? be deprecated over SLE12 so we have some time to do a lot of changes. Like KDE I missed the good words which gave the news, missed it when I was in Neuenburg late last year too or the meeting would have gone on in to the afternoon ;o) As others have said, we are now getting into ?holiday? mode in Europe, I know you don?t have much of this in the US but ;o) So I?d like to plan my time well. If SLE-12-RC1 can update a server/SDK/VMware-Workstation enviroment then let the README say so, if not, then let the README say so and I?ll call back for RC2 in August. My feeling in the water by the way is VMware Tools and Gnome shell high CPU are somewhat tied at the hip, but just a feeling. You should be able to upgrade a SLES 11 SP3 for VMware system to SLES 12 just by using the SLES 12 media. Direct upgrade from SLES 11 for VMware SP3 to SLES 12 should work. Judging that vm-tools etc are in the regular SLES 12 betas, VMWare support will be directly in SLES 12 and not in a separate product. on Wed, 25 Jun 2014 21:49:33 +0000 Waite Dick wrote (excerpt): --------------------------------------------------------------------- I have not run any of our applications on SLES12 yet. --------------------------------------------------------------------- I am a bit worried now because I am in particular interested that the base printing system was tested to get at least feedback by real users "out there". VMare tools are now part of SLES12. For upgrade, "default" install upgrade should work out of the box. Upgrade with SDK or with full installation are still being fixed. (Europe) Hope you all enjoyed the storm last night, its Heinerfest time in Darmstadt, and if the weather is going to be bad, this is the time. (http://www.darmstaedterheinerfest.de/) last night tonight !!!! __R ___________________________________________ Dick Waite Senior R&D Consultant Phone: +49 6151 92-1505 Mobile: +49 171 8393 769 Software AG Uhlandstr. 12 | 64297 Darmstadt | Germany www.softwareag.com ___________________________________________ Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lduncan at suse.com Mon Jul 7 08:25:57 2014 From: lduncan at suse.com (Lee Duncan) Date: Mon, 07 Jul 2014 07:25:57 -0700 Subject: [sles-beta] Question: Migration tools for ISCSI config from SLES11 In-Reply-To: References: Message-ID: <53BAADF5.1010400@suse.com> 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 > Web: www.akurit.com.au > -- Lee Duncan SUSE Labs From lduncan at suse.com Mon Jul 7 08:27:29 2014 From: lduncan at suse.com (Lee Duncan) Date: Mon, 07 Jul 2014 07:27:29 -0700 Subject: [sles-beta] Question: Migration tools for ISCSI config from SLES11 In-Reply-To: References: Message-ID: <53BAAE51.30203@suse.com> On 07/06/2014 02:11 PM, Darren Thompson wrote: > Team > > Less critical but on a similar note, are there tools to convert the > ISCSI client configs from SLSE11 to SLES12. By iSCSI client, do you mean iSCSI initiator? If so, then you are referring to open-iscsi, which has not changed appreciably from SLE11 SP3 to SLE12. > > I'm wanting to migrate a ISCSI dependant cluster from SLES11 to SLES12 > and want to see if it con be done without a full break/rebuild. > > Darren > > > ... -- Lee Duncan SUSE Labs From kdupke at suse.com Mon Jul 7 10:16:16 2014 From: kdupke at suse.com (Kai Dupke) Date: Mon, 07 Jul 2014 18:16:16 +0200 Subject: [sles-beta] RC1 on Friday - Upgrade with Server and SDK - VMware - Workstation In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D53854D46@hqmbx6.eur.ad.sag> References: <46AC8C81C10B8C48820201DF2AE1D76D53854D46@hqmbx6.eur.ad.sag> Message-ID: <53BAC7D0.6080104@suse.com> On 07/07/2014 11:10 AM, Waite, Dick wrote: > Q2 ? When does one run VMware tools or do you let it run itself? If on a VMware hypervisor the installation will add the open-vm-tools. If the tools are installed they start automatically. These are (now) fully L3 supported by SUSE in cooperation with VMware. greetings Kai Dupke Senior Product Manager Server Product Line -- Phone: +49-(0)5102-9310828 Mail: kai.dupke at suse.com Mobile: +49-(0)173-5876766 WWW: www.suse.com SUSE Linux Products GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany) GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG Nurnberg) From Dick.Waite at softwareag.com Mon Jul 7 11:51:35 2014 From: Dick.Waite at softwareag.com (Waite, Dick) Date: Mon, 7 Jul 2014 17:51:35 +0000 Subject: [sles-beta] RC1 on Friday - Upgrade with Server and SDK - VMware - Workstation In-Reply-To: <53BAC7D0.6080104@suse.com> References: <46AC8C81C10B8C48820201DF2AE1D76D53854D46@hqmbx6.eur.ad.sag> <53BAC7D0.6080104@suse.com> Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D53856035@hqmbx6.eur.ad.sag> Many Thanks Kai, good news indeed. I'll be running VMware Workstation 10-0-3 for the SLE 12 RC1 update; this became available 1st July so maybe that too has good relations with SLE 12. __R ___________________________________________ Dick Waite Senior R&D Consultant Phone: +49 6151 92-1505 Mobile: +49 171 8393 769 Software AG Uhlandstr. 12 | 64297 Darmstadt | Germany www.softwareag.com ___________________________________________ -----Original Message----- From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] On Behalf Of Kai Dupke Sent: Monday, July 07, 2014 6:16 PM To: sles-beta at lists.suse.com Subject: Re: [sles-beta] RC1 on Friday - Upgrade with Server and SDK - VMware - Workstation On 07/07/2014 11:10 AM, Waite, Dick wrote: > Q2 ? When does one run VMware tools or do you let it run itself? If on a VMware hypervisor the installation will add the open-vm-tools. If the tools are installed they start automatically. These are (now) fully L3 supported by SUSE in cooperation with VMware. greetings Kai Dupke Senior Product Manager Server Product Line -- Phone: +49-(0)5102-9310828 Mail: kai.dupke at suse.com Mobile: +49-(0)173-5876766 WWW: www.suse.com SUSE Linux Products GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany) GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG Nurnberg) _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com From darrent at akurit.com.au Mon Jul 7 15:43:50 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Tue, 8 Jul 2014 07:43:50 +1000 Subject: [sles-beta] Question: Migration tools for ISCSI config from SLES11 In-Reply-To: <53BAADF5.1010400@suse.com> References: <53BAADF5.1010400@suse.com> Message-ID: Lee >From an "end user" perspective, the default tools are what YAST defaults to, in this case they have changed from SLES11 to SLES12. 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). Darren On 8 July 2014 00:25, Lee Duncan 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 > > Web: 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 Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: From darrent at akurit.com.au Mon Jul 7 15:44:51 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Tue, 8 Jul 2014 07:44:51 +1000 Subject: [sles-beta] Question: Migration tools for ISCSI config from SLES11 In-Reply-To: <53BAAE51.30203@suse.com> References: <53BAAE51.30203@suse.com> Message-ID: Lee That is good news at-least... Darren On 8 July 2014 00:27, Lee Duncan wrote: > On 07/06/2014 02:11 PM, Darren Thompson wrote: > > Team > > > > Less critical but on a similar note, are there tools to convert the > > ISCSI client configs from SLSE11 to SLES12. > > By iSCSI client, do you mean iSCSI initiator? If so, then you are > referring to open-iscsi, which has not changed appreciably from SLE11 > SP3 to SLE12. > > > > > I'm wanting to migrate a ISCSI dependant cluster from SLES11 to SLES12 > > and want to see if it con be done without a full break/rebuild. > > > > Darren > > > > > > ... > > -- > 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 Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: From bjoern.lotz at suse.com Tue Jul 8 03:06:21 2014 From: bjoern.lotz at suse.com (Bjoern Lotz) Date: Tue, 08 Jul 2014 11:06:21 +0200 Subject: [sles-beta] Question regarding multipathd Message-ID: <53BBB48D.7090501@suse.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I have Beta9 set up with LIO Target on one machine, two targets with two paths each. I connect to those from another machine and they appear as expected on the client (initiator) side. However, after a reboot, multipathing does not work directly - only after manually restarting multipathd with systemctl restart multipathd are the devices assembled to mpatha and mpathb. (And only after entering systemctl restart multipathd again does the raid1 on top of it get activated, but for now I would be glad if the mpatha and mpathb devices would appear.) Did anyone see this too and know what I have to tweak to make it work directly after the system (initiator machine) reboots? I guess it's some sort of a timing issue during the system start, but I have not found a way to fix it. Any help is appreciated! Kind regards, Bj?rn - -- Dr. Bj?rn Lotz, Instructional Designer, CISSP SUSE Linux GmbH, Maxfeldstrasse 5, 90409 N?rnberg Tel: +49 89 8639 9664 Mobil: +49 173 5876724 bjoern.lotz at suse.com PGP-ID: 0xD437D363 - ------------------ SUSE Linux GmbH, N?rnberg; HRB 21284 (AG N?rnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO7tIUACgkQKZToxtQ302O1/gCg6TeObYD35PT+O4udrAHuFJrh cs0AoO1QHtVfxaYB05ft1ESm0F45h9mk =XG+3 -----END PGP SIGNATURE----- From wstephenson at suse.de Tue Jul 8 04:47:27 2014 From: wstephenson at suse.de (Will Stephenson) Date: Tue, 08 Jul 2014 12:47:27 +0200 Subject: [sles-beta] Question concerning SUSEConnect subscription register process In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9B6CA9@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9B6CA9@HXMB12.pnet.ch> Message-ID: <2846501.RLekJtX8ON@whistler.site> On Monday 07 Jul 2014 10:37:48 urs.frey at post.ch wrote: > Upon registering a new installation against NCC / SMT a unique installation > UID gets created The registration against a subscription gets done by this > UID. > > On a second installation of the very same server again a new UID gets > created. Now in my subscription register list I have two registrations but > only one server So I have to clean up my subscription registrations > manually and regularly, else there might be to many subscriptions "eaten" > by non-existing servers. > > In the operations team, there very often installations get redone, > interrupted etc. Wrong orders, customers not satisfied after installation, > etc. So I miss a mechanism where I can de-register a server node first upon > re-installation Something like SUSEConnect unregister `hostname` The SCC team are currently working on duplicate detection, de-duplication, product updates and migration from NCC-registered systems to SCC. These will give registration operations an 'at most once' semantic. There is "deregister" API already, but it's not exposed in the SUSEConnect CLI, yet. Will From gjn at gjn.priv.at Tue Jul 8 09:08:52 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Tue, 08 Jul 2014 17:08:52 +0200 Subject: [sles-beta] snapper delete a snapshot Message-ID: <5325169.ZLeSV9L0Lh@gjn.priv.at> Hello, I have read snapper don't delete a self created snapshot? I have create a snapshot with snapper create -d "After LDAP and Kerberos installation" I found this in the Docu // Creates a stand-alone snapshot (type single) for the default (root) configuration with a description. Because no cleanup-algorithm is specified, the snapshot will never be deleted automatically. // But now it is deleted :-(. Is this a Bug or a old Doku ? -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From kdupke at suse.com Tue Jul 8 12:15:09 2014 From: kdupke at suse.com (Kai Dupke) Date: Tue, 08 Jul 2014 20:15:09 +0200 Subject: [sles-beta] monit package In-Reply-To: References: Message-ID: <53BC352D.2030404@suse.com> Wendy, SUSE Linux Enterprise Server 12 is feature complete, if you don't find this or an alternative solution on the beta media (including the SDK) it will mostlikely not be planned for 12 yet. Given the current time in the development period additional features are not easy at all to integrate. So far I like feature requests and would be glad to get feature requests via your regular channel (i.e.partner manager) for the next version, or at least for after the GA versions. greetings kai On 07/08/2014 06:18 PM, Wendy Palm wrote: > Has SUSE considered including "monit" in SLES12? > > Our developers want to use it on our Cray systems, and think it would be a good general use tool to include in the SLE distros. > > Is there some package already included that may be as useful, or more useful for such monitoring? > > Thanks, > wendy > > > - - - > When in trouble, when in doubt, run in circles, scream and shout. > > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > Kai Dupke Senior Product Manager Server Product Line -- Phone: +49-(0)5102-9310828 Mail: kai.dupke at suse.com Mobile: +49-(0)173-5876766 WWW: www.suse.com SUSE Linux Products GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany) GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG Nurnberg) From darrent at akurit.com.au Tue Jul 8 15:42:40 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Wed, 9 Jul 2014 07:42:40 +1000 Subject: [sles-beta] Question: Migration tools for ISCSI config from SLES11 In-Reply-To: <53BC5F92.8040104@suse.com> References: <53BAADF5.1010400@suse.com> <53BC5F92.8040104@suse.com> Message-ID: 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 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 > > 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 > > > > > > Web: 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 > > Web: 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 Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: From darrent at akurit.com.au Tue Jul 8 17:01:05 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Wed, 9 Jul 2014 09:01:05 +1000 Subject: [sles-beta] Question: Migration tools for ISCSI config from SLES11 In-Reply-To: <53BC1A5C020000C2001516A3@prv-mh.provo.novell.com> References: <53BAADF5.1010400@suse.com> <53BC5F92.8040104@suse.com> <53BC1A5C020000C2001516A3@prv-mh.provo.novell.com> Message-ID: 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 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 > > > > > >>> Darren Thompson 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 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 > > > 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 >> > > >> > > Web: 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 >> > Web: 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 > 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 Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UPHTIBR4.img Type: image/jpg Size: 3692 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: From lduncan at suse.com Tue Jul 8 15:16:02 2014 From: lduncan at suse.com (Lee Duncan) Date: Tue, 08 Jul 2014 14:16:02 -0700 Subject: [sles-beta] Question: Migration tools for ISCSI config from SLES11 In-Reply-To: References: <53BAADF5.1010400@suse.com> Message-ID: <53BC5F92.8040104@suse.com> 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 > 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 > > > > Web: 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 > Web: www.akurit.com.au > -- Lee Duncan SUSE Labs From urs.frey at post.ch Thu Jul 10 03:53:06 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Thu, 10 Jul 2014 09:53:06 +0000 Subject: [sles-beta] Question concerning SUSEConnect subscription register process In-Reply-To: <2846501.RLekJtX8ON@whistler.site> References: <40637DBB36AF3941B243A286A432CA0B0F9B6CA9@HXMB12.pnet.ch> <2846501.RLekJtX8ON@whistler.site> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9B7E45@HXMB12.pnet.ch> Hi Will >The SCC team are currently working on duplicate detection, de-duplication, >product updates and migration from NCC-registered systems to SCC. These will >give registration operations an 'at most once' semantic. > >There is "deregister" API already, but it's not exposed in the SUSEConnect >CLI, yet. Thank you for this most welcome announcement In my place here, servers get set up using autoyast by operations team. In about 5% of all cases, the operations team does get a wrong setup order. (Project people coming from Microsoft world, not knowing about the Linux functional (pattern) setup. So a server might get set up as web server instead getting set up as proxy server. Or if there is no function at all, base pattern gets set up. So the operations team does a second setup. On my SMT I get the two different UIDs for the same server with the same IP and hostname. For me it would be most helpful if I could use a kind of autoyast tag to deregister versus my SMT if already existing. Of course I cannot put an existing UID string into my autoinst.xml profile, because at setup time nobody will go and check the SMT manually before creating the autoinst.xml profile. But all my servers do have a defined hostname, IP, hardware model, MAC. So if the UID gets created out of such parameters there would be a way to check versus the SMT if a registration already exists and one could either use the same UID when re-installing, or deregister. I can imagine MAC does probably not get used when generating the registration UID. This can simply be proven because when changing the motherboard with its NICs in a HP Proliant server, the MAC changes, but the SLES registration UID afterwards stays the same. Maybe you can see now what the idea behind is: Reducing manual work on SMT and / or NCC / SCC and having a proper registration base where each SLES installation is registered once. Of course you will also have to deal with sites, where the server gets set up using DHCP and then being transferred to its final network segment. Best regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Will Stephenson Gesendet: Tuesday, July 08, 2014 12:47 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] Question concerning SUSEConnect subscription register process On Monday 07 Jul 2014 10:37:48 urs.frey at post.ch wrote: > Upon registering a new installation against NCC / SMT a unique installation > UID gets created The registration against a subscription gets done by this > UID. > > On a second installation of the very same server again a new UID gets > created. Now in my subscription register list I have two registrations but > only one server So I have to clean up my subscription registrations > manually and regularly, else there might be to many subscriptions "eaten" > by non-existing servers. > > In the operations team, there very often installations get redone, > interrupted etc. Wrong orders, customers not satisfied after installation, > etc. So I miss a mechanism where I can de-register a server node first upon > re-installation Something like SUSEConnect unregister `hostname` The SCC team are currently working on duplicate detection, de-duplication, product updates and migration from NCC-registered systems to SCC. These will give registration operations an 'at most once' semantic. There is "deregister" API already, but it's not exposed in the SUSEConnect CLI, yet. Will _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From Dick.Waite at softwareag.com Thu Jul 10 04:05:46 2014 From: Dick.Waite at softwareag.com (Waite, Dick) Date: Thu, 10 Jul 2014 10:05:46 +0000 Subject: [sles-beta] Weekend planning - July 12-13 Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D53856B90@hqmbx6.eur.ad.sag> Grand Day, Looks to be a very wet weekend in Europe and soccer is only in the evenings. Will be interesting to see who gets 3rd place. Does SLE 12 RC1 look Okay to hit the wires on Friday, I could reserve some time on zLinux as the good system_people are running some checks before we switch to a new IBM box, IFL?s with 30% more oomph they say. __R ___________________________________________ Dick Waite Senior R&D Consultant Phone: +49 6151 92-1505 Mobile: +49 171 8393 769 Software AG Uhlandstr. 12 | 64297 Darmstadt | Germany www.softwareag.com ___________________________________________ Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From behlert at suse.com Thu Jul 10 08:57:44 2014 From: behlert at suse.com (Stefan Behlert) Date: Thu, 10 Jul 2014 16:57:44 +0200 Subject: [sles-beta] Update for SLE 12 RC1: Delay in release Message-ID: <20140710145744.GT13797@suse.de> Dear all, we are aware that you are waiting for RC 1 to be released this week. Unfortunately, we have still some issues that we want to get fixed before we call our current builds an "RC 1". For most of these, we have fixes, but verification is still taking time. Those tests will not be finished today nor tomorrow. We expect a release of RC 1 therefore not during this week, but early next week. We apologize for the inconvenience, Your SUSE Linux Enterprise Team -- Stefan Behlert, SUSE LINUX Project Manager Enterprise Server Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-173 SUSE LINUX Products GmbH, Nuernberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) From allen at ua.edu Fri Jul 11 13:22:15 2014 From: allen at ua.edu (Beddingfield, Allen) Date: Fri, 11 Jul 2014 19:22:15 +0000 Subject: [sles-beta] SR 10901431571 created for not being able to run under XenServer 6.2.x Message-ID: It looks like I now have rights to enter an SR, so I have belatedly entered one (SR# 10901431571) for the issue I uncovered with running under XenServer. The description I submitted is as follows: I have been trying to get SLES 12 running under Citrix XenServer 6.2. SLES 11 works on there with no problems. Here is the result of SLES 12: The installation goes off with no problem. There are no errors or issues. On final reboot, the last three lines seen on the screen are: Linux agpgart interface v0.103 Xen virtual console successfully install on ttyS0 i8042: PNP: No PS/2 controller found. Probing ports directly. At this point, it not only stops, but the VM actually powers off. I can install using the "Other Install Media" template, which generates a HVM virtual machine, but that is not acceptable for production. The problems above occur when trying to use the SLES 11 template (which would generate a PV virtual machine). It is my understanding from discussions on the beta team maling list that XenServer is supposed to be targeted as a supported platform for SLES. I can confirm that it does not work with any beta version under the latest version of XenServer. -- Allen Beddingfield Systems Engineer The University of Alabama