date:20151006

Re: zKVM on zpdt

2015-10-06 Thread Carsten Otte

Hi Tito,

I am sorry that this time I don't have a workaround. The installer code
assumes diag 308 IPL functions to be available, however it is'nt on zPDT. I
believe this should be fixed in the installer. The Linux kernel propagates
the error to the script, and it fails to handle it.

so long,
Carsten



From:   Tito Garrido 
To: LINUX-390@VM.MARIST.EDU
Date:   05/10/2015 23:57
Subject:Re: zKVM on zpdt
Sent by:Linux on 390 Port 



Hi Carsten,

Thanks for your inputs.

I have formatted from another linux and it worked.

Now I got another error on chreipl step:
























*2015-10-02 17:16:24,106 - model.installfunctions - DEBUG - Zipl output is:
Using config file '/etc/zipl.conf'Building bootmap in '/boot'Building menu
'zipl-automatic-menu'Adding #1: IPL section 'linux' (default)Preparing boot
device: dasda (5001).Done.2015-10-02 17:16:24,111 - model.installfunctions
- DEBUG - Zipl error output is:2015-10-02 17:16:24,130 -
model.installfunctions - DEBUG - Zipl bootName is: dasda2015-10-02
17:16:24,187 - model.installfunctions - DEBUG - chreipl output
is:2015-10-02 17:16:24,191 - model.installfunctions - DEBUG - chreipl error
output is: chreipl: Could not open "reipl/ccw/loadparm" (Permission
denied)2015-10-02 17:16:24,194 - model.installfunctions - ERROR - Error
running chreipl2015-10-02 17:16:24,198 - model.installfunctions - CRITICAL
- Failed installSystem2015-10-02 17:16:24,201 - model.installfunctions -
CRITICAL - EXCEPTION:2015-10-02
17:16:24,204 - model.installfunctions - CRITICAL - Error running
chreipl2015-10-02 17:16:24,223 - model.installfunctions - CRITICAL -
Stacktrace:Traceback (most recent call last): File
"/opt/ibm/kvmibm-installer/model/installfunctions.py", line 377, in
installSystem   installBootloader(diskSelected, rootDir, bootDev, rootDev,
swapDev) File "/opt/ibm/kvmibm-installer/model/installfunctions.py", line
1101, in installBootloader   raise RuntimeError('Error running
chreipl')RuntimeError: Error running chreipl2015-10-02 17:16:24,625 -
controller.controller - CRITICAL - ZKVMError: [['KVMIBMIN70500', 'Error
while installing packages.'], ('INSTALLER', 'INSTALLSYSTEM',
'INSTALL_MSG')](END)*
Probably is another issue with zPDT.



On Mon, Oct 5, 2015 at 5:30 AM, Carsten Otte  wrote:

>
> Tito,
>
> I think you ran into a Linux dasd device driver problem. The issue is,
that
> the awsckd emulator does not support (and does not advertiese) the prefix
> command. This is perfectly fine for a 3390 device, however Linux does
issue
> this command on 3390. The issue has been reported and is fixed in
upstream
> Linux. I think the bugfix needs to be backported to your level of code.
> As a workaround, you can bring up another linux that is either old enough
> for not having the bug or new enough to have the fix, and do dasdfmt on
> your dasd. Using the dasd (partitioning, creating and mounting
filesystems)
> works flawless from your kernel as far as I can tell.
>
> so long,
> Carsten
> --
> Carsten Otte
> IBM Deutschland R
> Firmware Development
>
>
>
> From:   Tito Garrido 
> To: LINUX-390@VM.MARIST.EDU
> Date:   02/10/2015 18:30
> Subject:Re: zKVM on zpdt
> Sent by:Linux on 390 Port 
>
>
>
> FYI: To make it work I had to format the dasds on an older Linux like
> RHEL6.
>
> On Fri, Oct 2, 2015 at 10:47 AM, Tito Garrido 
> wrote:
>
> > Hi Folks,
> >
> >   I have already asked this question on z1090 mail list but it may be
> > interesting for other people here that would like to try zKVM and also
> you
> > may know the answer :)
> >
> >
> > I am trying to install zKVM on zpdt but it is not able to run dasdfmt
> > during the installation:
> >
> >
> > 2015-10-02 02:13:15,704 - program - INFO - Running... /sbin/dasdfmt -y
-d
> > cdl -b 4096 /dev/dasda
> > 2015-10-02 02:13:15,734 - program - INFO - /sbin/dasdfmt: (invalidate
> > first track) IOCTL BIODASDFMT failed. (Input/output error)
> >
> > Any clue?
> >
> > I have already tried to run CPFMTXA on a z/VM instance and run the
> > installation again but no success...
> >
> >
> >
> > Regards,
> > Tito
> >
> > --
> >
> > Linux User #387870
> > .
> >  _/_õ|__|
> > ..º[ .-.___.-._| . . . .
> > .__( o)__( o).:___
> >
>
>
>
> --
>
> Linux User #387870
> .
>  _/_õ|__|
> ..º[ .-.___.-._| . . . .
> .__( o)__( o).:___
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>
>
>
> --
> For LINUX-390

How to force crash dump from hung Red Hat guest

2015-10-06 Thread Vitale, Joseph

Hello,

Running  Red Hat 6.6  under zVM 6.3.  I had a guest hang and unable to issue 
linux commands to force a kernel crash dump( echo c > /proc/sysrq-trigger ).

Any suggestions how that can be accomplished?

Thanks
Joe


Joseph Vitale
Technology Services Group
Mainframe Operating Systems

Pershing Plaza
95 Christopher Columbus Drive
Floor 14
Jersey City,  N.J.  07302
Work  201-395-1509
Cell917-903-0102


The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: How to force crash dump from hung Red Hat guest

2015-10-06 Thread Marcy Cortes

I think it was worse than 30 minutes for 16G the last time I tried!
And it is non-interruptible.
If you are on a problem call, you may have people screaming at you to get their 
server back sooner and you have no control at that point.

Best imho to make yourself a volume with zipl -d .You can attach that to 
whatever guest as needed and simply do from the console:
#cp stop cpu all
#cp store status
#cp ipl 

It's very fast and always works.
It’s a good practice to always have one ready.

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Robert J 
Brenneman
Sent: Tuesday, October 06, 2015 10:02 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] How to force crash dump from hung Red Hat guest

from the guest's console issue #CP VMDUMP to trigger a CP managed dump of the 
virtual machine. This dumps to spool space and it shows up in the guest's rdr 
device. You can then 'vmur receive --convert  
/path/to/where/dump/goes' to import the vmcore to the Linux file system when 
you IPL after the dump completes.

Make sure you have enough spool space to contain however much virtual memory 
the guest is defined with. Also make sure you have time - a VMDUMP of a 16 GB 
virtual machine can take on the order of 30 minutes - dumping to spool is slow 
but it will save your bacon when the kdump function does not work for whatever 
reason.

http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdt/lgdt_c_intro.html

On Tue, Oct 6, 2015 at 11:41 AM, Vitale, Joseph  wrote:

> Hello,
>
> Running  Red Hat 6.6  under zVM 6.3.  I had a guest hang and unable to 
> issue linux commands to force a kernel crash dump( echo c > 
> /proc/sysrq-trigger ).
>
> Any suggestions how that can be accomplished?
>
> Thanks
> Joe
>
>
> Joseph Vitale
> Technology Services Group
> Mainframe Operating Systems
>
> Pershing Plaza
> 95 Christopher Columbus Drive
> Floor 14
> Jersey City,  N.J.  07302
> Work  201-395-1509
> Cell917-903-0102
>
>
> The information contained in this e-mail, and any attachment, is 
> confidential and is intended solely for the use of the intended recipient.
> Access, copying or re-use of the e-mail or any attachment, or any 
> information contained therein, by any other person is not authorized. 
> If you are not the intended recipient please return the e-mail to the 
> sender and delete it from your computer. Although we attempt to sweep 
> e-mail and attachments for viruses, we do not guarantee that either 
> are virus-free and accept no liability for any damage sustained as a result 
> of viruses.
>
> Please refer to http://disclaimer.bnymellon.com/eu.htm for certain 
> disclosures relating to European legal entities.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send 
> email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit 
> http://wiki.linuxvm.org/
>

--
Jay Brenneman

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

Re: LVM usage

2015-10-06 Thread van Sleeuwen, Berry

Actually, those were just examples. The Samba and TSM guests have the biggest 
LVM filesystems. We have a quite a few linux guests, most of them use LVM. 
Ranging from a small webserver to a couple of oracle database machines with 
LVM's up to 40G.

I don’t think it matters if we are talking zVM guests or native linux machines. 
The usage of LVM depends on what storage is available. Mainframe DASD typically 
doesn't have the large disksizes so the smaller disks require LVM or any other 
solution that glues disk together. But even when the storage solution has the 
required sizes available there can be other reasons for using LVM. We use LVM 
primarily for two reasons. First of all to glue smaller disks together and 
secondly to spread IO onto multiple disks.

We use LVM only for user filesystems. The system data remains on non-LVM disks. 
Most of the user data is located in /srv that is located in an LVM.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Sergey 
Korzhevsky
Sent: Monday, October 05, 2015 5:23 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: LVM usage

Stories about TSM and Samba are great, but this is one installation for the 
site and we are speaking in terms of z/VM, right?
This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.

Re: DIRM problem

2015-10-06 Thread Alan Altmark

On Monday, 10/05/2015 at 01:42 EDT, Bruce Hayden 
wrote:
> What do you have for all the configuration variables that start with PW_
in
> your CONFIG99 DATADVH file?  The expire days should be set by
> PW_INTERVAL_FOR_SET= according to the documentation.  I'm guessing it is
> not the default value or at least greater than zero.
>
> But - you say you also have RACF.  In that case, forget all of the PW_
> settings because RACF is the one that will be managing the passwords.
You
> set the password change interval, etc. using the RAC SETROPTS (set RACF
> options) command.

Nah.  DIRMAINT still keeps track of when passwords were changed via
DIRMAINT.

Tearing the problem apart...
DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG

This error is because there is a problem with the PW_INTERVAL_FOR_SET
statement.  A DIRM ADD, CHNGID, or SETPW command (ADD, in this case)
attempted to set the password validity interval to a value that is higher
than the interval from the PW_INTERVAL_FOR_GEN statement (2nd value).  The
default is 97 days.

There is either a bug in the doc or a bug in the code. PW_INTERVAL_FOR_GEN
is documented to have to values on it:  The first value specifies the
number of days a password is valid following one of the commands that set
the password for a general user, the second value specifies the number of
days a password is valid for a privileged user.

The code doesn't do that.  It assumes all users are general users as far
as PW_INTERVAL_FOR_SET is concerned.

I would do a
   DIRM CMS LISTFILE CONFIG* DATADVH *
to see what configuration files are available.  Then I would look in all
of them for a PW_INTERVAL_FOR_SET statement.  Not finding any, I would
simply restart DIRMAINT.  If you comment out a statement, RLDDATA won't
always work since as far as it's concerned, nothing is overriding the
existing value.

You can just put a null value on it.
   PW_INTERVAL_FOR_SET=

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: How to force crash dump from hung Red Hat guest - Thank You all

2015-10-06 Thread Vitale, Joseph

All excellent suggestions.  Thank you all, extremely helpful.

Joe

Joseph Vitale
Technology Services Group
Mainframe Operating Systems

Pershing Plaza
95 Christopher Columbus Drive
Floor 14   
Jersey City,  N.J.  07302
Work  201-395-1509
Cell917-903-0102

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy 
Cortes
Sent: Tuesday, October 06, 2015 2:28 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: How to force crash dump from hung Red Hat guest

I think it was worse than 30 minutes for 16G the last time I tried!
And it is non-interruptible.
If you are on a problem call, you may have people screaming at you to get their 
server back sooner and you have no control at that point.

Best imho to make yourself a volume with zipl -d .You can attach that to 
whatever guest as needed and simply do from the console:
#cp stop cpu all
#cp store status
#cp ipl 

It's very fast and always works.
It’s a good practice to always have one ready.

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Robert J 
Brenneman
Sent: Tuesday, October 06, 2015 10:02 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] How to force crash dump from hung Red Hat guest

from the guest's console issue #CP VMDUMP to trigger a CP managed dump of the 
virtual machine. This dumps to spool space and it shows up in the guest's rdr 
device. You can then 'vmur receive --convert  
/path/to/where/dump/goes' to import the vmcore to the Linux file system when 
you IPL after the dump completes.

Make sure you have enough spool space to contain however much virtual memory 
the guest is defined with. Also make sure you have time - a VMDUMP of a 16 GB 
virtual machine can take on the order of 30 minutes - dumping to spool is slow 
but it will save your bacon when the kdump function does not work for whatever 
reason.

http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdt/lgdt_c_intro.html

On Tue, Oct 6, 2015 at 11:41 AM, Vitale, Joseph  wrote:

> Hello,
>
> Running  Red Hat 6.6  under zVM 6.3.  I had a guest hang and unable to 
> issue linux commands to force a kernel crash dump( echo c > 
> /proc/sysrq-trigger ).
>
> Any suggestions how that can be accomplished?
>
> Thanks
> Joe
>
>
> Joseph Vitale
> Technology Services Group
> Mainframe Operating Systems
>
> Pershing Plaza
> 95 Christopher Columbus Drive
> Floor 14
> Jersey City,  N.J.  07302
> Work  201-395-1509
> Cell917-903-0102
>
>
> The information contained in this e-mail, and any attachment, is 
> confidential and is intended solely for the use of the intended recipient.
> Access, copying or re-use of the e-mail or any attachment, or any 
> information contained therein, by any other person is not authorized.
> If you are not the intended recipient please return the e-mail to the 
> sender and delete it from your computer. Although we attempt to sweep 
> e-mail and attachments for viruses, we do not guarantee that either 
> are virus-free and accept no liability for any damage sustained as a result 
> of viruses.
>
> Please refer to http://disclaimer.bnymellon.com/eu.htm for certain 
> disclosures relating to European legal entities.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send 
> email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit 
> http://wiki.linuxvm.org/
>

--
Jay Brenneman

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities.

Re: How to force crash dump from hung Red Hat guest

2015-10-06 Thread Vitale, Joseph

Thanks for that information.  Question, is that dump usable by Red Hat or only 
IBM Linux support  as  my support contract is via Red Hat.

Thanks
Joe

Joseph Vitale
Technology Services Group
Mainframe Operating Systems

Pershing Plaza
95 Christopher Columbus Drive
Floor 14   
Jersey City,  N.J.  07302
Work  201-395-1509
Cell917-903-0102

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Robert J 
Brenneman
Sent: Tuesday, October 06, 2015 1:02 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: How to force crash dump from hung Red Hat guest

from the guest's console issue #CP VMDUMP to trigger a CP managed dump of the 
virtual machine. This dumps to spool space and it shows up in the guest's rdr 
device. You can then 'vmur receive --convert  
/path/to/where/dump/goes' to import the vmcore to the Linux file system when 
you IPL after the dump completes.

Make sure you have enough spool space to contain however much virtual memory 
the guest is defined with. Also make sure you have time - a VMDUMP of a 16 GB 
virtual machine can take on the order of 30 minutes - dumping to spool is slow 
but it will save your bacon when the kdump function does not work for whatever 
reason.

http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdt/lgdt_c_intro.html

On Tue, Oct 6, 2015 at 11:41 AM, Vitale, Joseph  wrote:

> Hello,
>
> Running  Red Hat 6.6  under zVM 6.3.  I had a guest hang and unable to 
> issue linux commands to force a kernel crash dump( echo c > 
> /proc/sysrq-trigger ).
>
> Any suggestions how that can be accomplished?
>
> Thanks
> Joe
>
>
> Joseph Vitale
> Technology Services Group
> Mainframe Operating Systems
>
> Pershing Plaza
> 95 Christopher Columbus Drive
> Floor 14
> Jersey City,  N.J.  07302
> Work  201-395-1509
> Cell917-903-0102
>
>
> The information contained in this e-mail, and any attachment, is 
> confidential and is intended solely for the use of the intended recipient.
> Access, copying or re-use of the e-mail or any attachment, or any 
> information contained therein, by any other person is not authorized. 
> If you are not the intended recipient please return the e-mail to the 
> sender and delete it from your computer. Although we attempt to sweep 
> e-mail and attachments for viruses, we do not guarantee that either 
> are virus-free and accept no liability for any damage sustained as a result 
> of viruses.
>
> Please refer to http://disclaimer.bnymellon.com/eu.htm for certain 
> disclosures relating to European legal entities.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send 
> email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit 
> http://wiki.linuxvm.org/
>

--
Jay Brenneman

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities.

LVM usage - Thank you very much!

2015-10-06 Thread Sergey Korzhevsky

It was very valuable for me, thanks to all of you!



WBR, Sergey

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: How to force crash dump from hung Red Hat guest

2015-10-06 Thread Thomas Anderson

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Kernel_Crash_Dump_Guide/Red_Hat_Enterprise_Linux-7-Kernel_Crash_Dump_Guide-en-US.pdf

Is a really nice write up on how to get your guest image configured to dump in 
a manner that will be useful to Red Hat support (and actually has some mention 
of Z systems too! ;) ).
Without doing this prep work, even if you had been able to send your gust a 
SysReq or NMI to force the panic, it wouldn’t have collected the diagnostics 
for you to give to the vendor.


Tom Anderson
Ex ignorantia ad sapientiam
e tenebris ad lucem!

> On Oct 6, 2015, at 10:17 AM, Vitale, Joseph  
> wrote:
> 
> Thanks for that information.  Question, is that dump usable by Red Hat or 
> only IBM Linux support  as  my support contract is via Red Hat.
> 
> Thanks
> Joe
> 
> Joseph Vitale
> Technology Services Group
> Mainframe Operating Systems
> 
> Pershing Plaza
> 95 Christopher Columbus Drive
> Floor 14   
> Jersey City,  N.J.  07302
> Work  201-395-1509
> Cell917-903-0102
> 
> 
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Robert 
> J Brenneman
> Sent: Tuesday, October 06, 2015 1:02 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: How to force crash dump from hung Red Hat guest
> 
> from the guest's console issue #CP VMDUMP to trigger a CP managed dump of the 
> virtual machine. This dumps to spool space and it shows up in the guest's rdr 
> device. You can then 'vmur receive --convert  
> /path/to/where/dump/goes' to import the vmcore to the Linux file system when 
> you IPL after the dump completes.
> 
> Make sure you have enough spool space to contain however much virtual memory 
> the guest is defined with. Also make sure you have time - a VMDUMP of a 16 GB 
> virtual machine can take on the order of 30 minutes - dumping to spool is 
> slow but it will save your bacon when the kdump function does not work for 
> whatever reason.
> 
> http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdt/lgdt_c_intro.html
> 
> On Tue, Oct 6, 2015 at 11:41 AM, Vitale, Joseph > wrote:
> 
>> Hello,
>> 
>> Running  Red Hat 6.6  under zVM 6.3.  I had a guest hang and unable to 
>> issue linux commands to force a kernel crash dump( echo c > 
>> /proc/sysrq-trigger ).
>> 
>> Any suggestions how that can be accomplished?
>> 
>> Thanks
>> Joe
>> 
>> 
>> Joseph Vitale
>> Technology Services Group
>> Mainframe Operating Systems
>> 
>> Pershing Plaza
>> 95 Christopher Columbus Drive
>> Floor 14
>> Jersey City,  N.J.  07302
>> Work  201-395-1509
>> Cell917-903-0102
>> 
>> 
>> The information contained in this e-mail, and any attachment, is 
>> confidential and is intended solely for the use of the intended recipient.
>> Access, copying or re-use of the e-mail or any attachment, or any 
>> information contained therein, by any other person is not authorized. 
>> If you are not the intended recipient please return the e-mail to the 
>> sender and delete it from your computer. Although we attempt to sweep 
>> e-mail and attachments for viruses, we do not guarantee that either 
>> are virus-free and accept no liability for any damage sustained as a result 
>> of viruses.
>> 
>> Please refer to http://disclaimer.bnymellon.com/eu.htm for certain 
>> disclosures relating to European legal entities.
>> 
>> --
>> For LINUX-390 subscribe / signoff / archive access instructions, send 
>> email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
>> visit
>> http://www.marist.edu/htbin/wlvindex?LINUX-390
>> --
>> For more information on Linux on System z, visit 
>> http://wiki.linuxvm.org/
>> 
> 
> 
> 
> --
> Jay Brenneman
> 
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send email 
> to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit http://wiki.linuxvm.org/
> 
> The information contained in this e-mail, and any attachment, is confidential 
> and is intended solely for the use of the intended recipient. Access, copying 
> or re-use of the e-mail or any attachment, or any information contained 
> therein, by any other person is not authorized. If you are not the intended 
> recipient please return the e-mail to the sender and delete it from your 
> computer. Although we attempt to sweep e-mail and attachments for viruses, we 
> do not guarantee that either are virus-free and accept no liability for any 
> damage sustained as a result of viruses. 
> 
> Please refer to http://disclaimer.bnymellon.com/eu.htm for certain 
> disclosures

Re: zKVM installation problem

2015-10-06 Thread Michael Mueller

On Mon, 5 Oct 2015 11:11:40 -0400
Ray Mansell  wrote:

> I'm trying to install zKVM in a virtual machine, but no matter what
> installation options I choose, I always get the following error:
>
> 2015-10-03 14:39:40,900 - controller.controller - INFO - InstallProgress
> screen
> 2015-10-03 14:39:40,901 - controller.controller - INFO - Formatting disks...
> 2015-10-03 14:39:40,901 - controller.controller - INFO - Installing KVM
> for IBM z into disk dasda...
> 2015-10-03 14:39:41,041 - model.installfunctions - INFO - Get repodata_file
> 2015-10-03 14:39:41,088 - model.installfunctions - CRITICAL - Failed
> installSystem
> 2015-10-03 14:39:41,089 - model.installfunctions - CRITICAL -
> EXCEPTION:
> 2015-10-03 14:39:41,089 - model.installfunctions - CRITICAL - local
> variable 's' referenced before assignment
> 2015-10-03 14:39:41,089 - model.installfunctions - CRITICAL -
> Stacktrace:Traceback (most recent call last):
>File "/opt/ibm/kvmibm-installer/model/installfunctions.py", line 357,
> in installSystem
>  installPackages(rootDir, callback)
>File "/opt/ibm/kvmibm-installer/model/installfunctions.py", line 749,
> in installPackages
>  repodata_file = getRepodataFile(repo, logger)
>File "/opt/ibm/kvmibm-installer/model/installfunctions.py", line 548,
> in getRepodataFile
>  d = re.split('([\d\w]+-primary.sqlite.bz2)', s)
> UnboundLocalError: local variable 's' referenced before assignment
>
> 2015-10-03 14:39:41,095 - controller.controller - CRITICAL - ZKVMError:
> [['KVMIBMIN70500', 'Error while installing packages.'], ('INSTALLER',
> 'INSTALLSYSTEM', 'INSTALL_MSG')]
>
> Help? Please?

Ray,

make sure you have copied the repodata folder from the installation image to
your ftp server. Should have the following files:

$ ls -Rl ./repodata
./repodata:
total 2284
-rw--- 1 mimu mimu 410546 Aug  6 12:11
1071bedb0b7dba6b8ed2fae387116e3f2b8160544d2abdad5411fbe8f737ff63-filelists.xml.gz
-rw--- 1 mimu mimu  14151 Aug  6 12:11
3a456231834ea9d32d6a7525ff38fe6246932c2a14d8df1b6cf75b810dc09545-KVMIBM-1.1.0-20150806-comps.xml
-rw--- 1 mimu mimu 517316 Aug  6 12:11
655cf5993b0a15383cfe5224bf2db4d95b3cba0539c3075e5fc57c3cd08ab40e-filelists.sqlite.bz2
-rw--- 1 mimu mimu 771729 Aug  6 12:11
836db89a0f5c266ea3b34d070a26cad34ad39db91a416081bcda615bb8605324-primary.sqlite.bz2
-rw--- 1 mimu mimu  76579 Aug  6 12:11
9fe8a5082cbb90e961d5e597ad6993c6a1f35035bf918b57b3fe1bba822550b8-other.xml.gz
-rw--- 1 mimu mimu  96919 Aug  6 12:11
b08023e34c172ac98447cf816543a2a02d0f9819d29cc40d375e02b37c8d6ce5-other.sqlite.bz2
-rw--- 1 mimu mimu   1706 Aug  6 12:11
d5e91197cddcab057566c403de6c1a71e3e56cec91bc95006c5dde1a69ffcba7-KVMIBM-1.1.0-20150806-comps.xml.gz
-rw--- 1 mimu mimu 398232 Aug  6 12:11
f410070319c7a1fbb90a37e20f85064390db0112a0ceb34f8c84ef4f866e5e4e-primary.xml.gz
-rw--- 1 mimu mimu   3740 Aug  6 12:11 repomd.xml
-r 1 mimu mimu   2599 Aug  6 12:16 TRANS.TBL

By moving them away I can reproduce the error message.

Michael

>
> Ray...
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: DIRM problem

2015-10-06 Thread Mauro Souza

> I'm in the process of setting up DIRMAINT AND RACF to work together so we
can exploit SMAPI.

If your goal is to exploit SMAPI, you don't need RACF. We use XCAT here,
with SMAPI, without RACF, and works nicely.
On Oct 6, 2015 03:23, "Alan Altmark"  wrote:

> On Monday, 10/05/2015 at 01:42 EDT, Bruce Hayden 
> wrote:
> > What do you have for all the configuration variables that start with PW_
> in
> > your CONFIG99 DATADVH file?  The expire days should be set by
> > PW_INTERVAL_FOR_SET= according to the documentation.  I'm guessing it is
> > not the default value or at least greater than zero.
> >
> > But - you say you also have RACF.  In that case, forget all of the PW_
> > settings because RACF is the one that will be managing the passwords.
> You
> > set the password change interval, etc. using the RAC SETROPTS (set RACF
> > options) command.
>
> Nah.  DIRMAINT still keeps track of when passwords were changed via
> DIRMAINT.
>
> Tearing the problem apart...
> DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG
>
> This error is because there is a problem with the PW_INTERVAL_FOR_SET
> statement.  A DIRM ADD, CHNGID, or SETPW command (ADD, in this case)
> attempted to set the password validity interval to a value that is higher
> than the interval from the PW_INTERVAL_FOR_GEN statement (2nd value).  The
> default is 97 days.
>
> There is either a bug in the doc or a bug in the code. PW_INTERVAL_FOR_GEN
> is documented to have to values on it:  The first value specifies the
> number of days a password is valid following one of the commands that set
> the password for a general user, the second value specifies the number of
> days a password is valid for a privileged user.
>
> The code doesn't do that.  It assumes all users are general users as far
> as PW_INTERVAL_FOR_SET is concerned.
>
> I would do a
>DIRM CMS LISTFILE CONFIG* DATADVH *
> to see what configuration files are available.  Then I would look in all
> of them for a PW_INTERVAL_FOR_SET statement.  Not finding any, I would
> simply restart DIRMAINT.  If you comment out a statement, RLDDATA won't
> always work since as far as it's concerned, nothing is overriding the
> existing value.
>
> You can just put a null value on it.
>PW_INTERVAL_FOR_SET=
>
> Alan Altmark
>
> Senior Managing z/VM and Linux Consultant
> Lab Services System z Delivery Practice
> IBM Systems & Technology Group
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: zKVM installation problem

2015-10-06 Thread Philipp Kern


On 2015-10-05 20:26, Grzegorz Powiedziuk wrote:

I’ve seen weird python errors similar to these ones (unfortunately I
didn’t keep traces to compare) in some linux distribution during the
installation if I had a “dirty disk”.


This isn't a weird Python error. It's a straightforward coding error. 
Without having the code at hand I guess that s is only set in an "if" 
but who knows. It should at least have been initialized with something. 
At least you can just inspect the code given that it's Python.


Kind regards
Philipp Kern

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: DIRM problem

2015-10-06 Thread Shumate, Scott

I have 3 files.

CONFIG DATADVH
CONFIG99 DATADVH
CONFIGSS DATADVH

Out of the 3 files, 2 has PW_INTERVAL_FOR_SET= in it

CONFIG DATADVH has it as PW_INTERVAL_FOR_SET=
CONFIG99 DATADVH has it as PW_INTERVAL_FOR_SET= 90

I committed it out in CONFIG DATADVH did a DIRM RLDD & DIRM RLDC.  It failed 
again with the following

DVHREQ2288I Your ADD request for LXTEST2 at * has been accepted.
DVHPWU3376E Days can not exceed the current password expire value of 0
DVHPWU3376E for user LXTEST2.
DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG
DVHREQ2289E Your ADD request for LXTEST2 at * has failed; with RC =
DVHREQ2289E 3212.

I restarted DIRMAINT and got the same results.

Thanks
Scott

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan 
Altmark
Sent: Tuesday, October 06, 2015 2:21 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: DIRM problem

On Monday, 10/05/2015 at 01:42 EDT, Bruce Hayden 
wrote:
> What do you have for all the configuration variables that start with
> PW_
in
> your CONFIG99 DATADVH file?  The expire days should be set by
> PW_INTERVAL_FOR_SET= according to the documentation.  I'm guessing it
> is not the default value or at least greater than zero.
>
> But - you say you also have RACF.  In that case, forget all of the PW_
> settings because RACF is the one that will be managing the passwords.
You
> set the password change interval, etc. using the RAC SETROPTS (set
> RACF
> options) command.

Nah.  DIRMAINT still keeps track of when passwords were changed via DIRMAINT.

Tearing the problem apart...
DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG

This error is because there is a problem with the PW_INTERVAL_FOR_SET 
statement.  A DIRM ADD, CHNGID, or SETPW command (ADD, in this case) attempted 
to set the password validity interval to a value that is higher than the 
interval from the PW_INTERVAL_FOR_GEN statement (2nd value).  The default is 97 
days.

There is either a bug in the doc or a bug in the code. PW_INTERVAL_FOR_GEN is 
documented to have to values on it:  The first value specifies the number of 
days a password is valid following one of the commands that set the password 
for a general user, the second value specifies the number of days a password is 
valid for a privileged user.

The code doesn't do that.  It assumes all users are general users as far as 
PW_INTERVAL_FOR_SET is concerned.

I would do a
   DIRM CMS LISTFILE CONFIG* DATADVH *
to see what configuration files are available.  Then I would look in all of 
them for a PW_INTERVAL_FOR_SET statement.  Not finding any, I would simply 
restart DIRMAINT.  If you comment out a statement, RLDDATA won't always work 
since as far as it's concerned, nothing is overriding the existing value.

You can just put a null value on it.
   PW_INTERVAL_FOR_SET=

Alan Altmark

Senior Managing z/VM and Linux Consultant Lab Services System z Delivery 
Practice IBM Systems & Technology Group ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

The information in this transmission may contain proprietary and non-public 
information of BB or its affiliates and may be subject to protection under 
the law. The message is intended for the sole use of the individual or entity 
to which it is addressed. If you are not the intended recipient, you are 
notified that any use, distribution or copying of the message is strictly 
prohibited. If you received this message in error, please delete the material 
from your system without reading the content and notify the sender immediately 
of the inadvertent transmission.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: DIRM problem

2015-10-06 Thread Alan Altmark

What does PW_INTERVAL_GEN have?

The ultimate answer is to get the source for DVHSTPWC EXEC from MAINT630, run 
it through EXECUPDT, and then put traces in it.

This is the program that issues the 3376 error.

That's what I would do if I were on site.

Alan Altmark
Senior Managing Consultant
IBM Systems Lab Services


   Shumate, Scott --- Re: [LINUX-390] DIRM problem --- 
From:"Shumate, Scott" To:"" 
Date:Tue, Oct 6, 2015 8:30 AMSubject:Re: [LINUX-390] 
DIRM problem
  
 I have 3 files. CONFIG DATADVH CONFIG99 DATADVH CONFIGSS DATADVH Out of the 3 
files, 2 has PW_INTERVAL_FOR_SET= in it CONFIG DATADVH has it as 
PW_INTERVAL_FOR_SET= CONFIG99 DATADVH has it as PW_INTERVAL_FOR_SET= 90 I 
committed it out in CONFIG DATADVH did a DIRM RLDD & DIRM RLDC. It failed again 
with the following DVHREQ2288I Your ADD request for LXTEST2 at * has been 
accepted. DVHPWU3376E Days can not exceed the current password expire value of 
0 DVHPWU3376E for user LXTEST2. DVHADD3212E Unexpected RC= 3376, from: EXEC 
DVHSTPWC ADD LXTEST2 CONFIG DVHREQ2289E Your ADD request for LXTEST2 at * has 
failed; with RC = DVHREQ2289E 3212. I restarted DIRMAINT and got the same 
results. Thanks Scott -Original Message- From: Linux on 390 Port 
[mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan Altmark Sent: Tuesday, 
October 06, 2015 2:21 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: DIRM problem 
On Monday, 10/05/2015 at 01:42 EDT, Bruce Hayden  wrote: > What do you have for 
all the configuration variables that start with > PW_ in > your CONFIG99 
DATADVH file? The expire days should be set by > PW_INTERVAL_FOR_SET= according 
to the documentation. I'm guessing it > is not the default value or at least 
greater than zero. > > But - you say you also have RACF. In that case, forget 
all of the PW_ > settings because RACF is the one that will be managing the 
passwords. You > set the password change interval, etc. using the RAC SETROPTS 
(set > RACF > options) command. Nah. DIRMAINT still keeps track of when 
passwords were changed via DIRMAINT. Tearing the problem apart... DVHADD3212E 
Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG This error is 
because there is a problem with the PW_INTERVAL_FOR_SET statement. A DIRM ADD, 
CHNGID, or SETPW command (ADD, in this case) attempted to set the password 
validity interval to a value that is higher than the interval from the 
PW_INTERVAL_FOR_GEN statement (2nd value). The default is 97 days. There is 
either a bug in the doc or a bug in the code. PW_INTERVAL_FOR_GEN is documented 
to have to values on it: The first value specifies the number of days a 
password is valid following one of the commands that set the password for a 
general user, the second value specifies the number of days a password is valid 
for a privileged user. The code doesn't do that. It assumes all users are 
general users as far as PW_INTERVAL_FOR_SET is concerned. I would do a DIRM CMS 
LISTFILE CONFIG* DATADVH * to see what configuration files are available. Then 
I would look in all of them for a PW_INTERVAL_FOR_SET statement. Not finding 
any, I would simply restart DIRMAINT. If you comment out a statement, RLDDATA 
won't always work since as far as it's concerned, nothing is overriding the 
existing value. You can just put a null value on it. PW_INTERVAL_FOR_SET= Alan 
Altmark Senior Managing z/VM and Linux Consultant Lab Services System z 
Delivery Practice IBM Systems & Technology Group 
ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 
alan_altm...@us.ibm.com IBM Endicott 
-- For 
LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit 
http://www.marist.edu/htbin/wlvindex?LINUX-390 
-- For more 
information on Linux on System z, visit http://wiki.linuxvm.org/ The 
information in this transmission may contain proprietary and non-public 
information of BB or its affiliates and may be subject to protection under 
the law. The message is intended for the sole use of the individual or entity 
to which it is addressed. If you are not the intended recipient, you are 
notified that any use, distribution or copying of the message is strictly 
prohibited. If you received this message in error, please delete the material 
from your system without reading the content and notify the sender immediately 
of the inadvertent transmission. 
-- For 
LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit 
http://www.marist.edu/htbin/wlvindex?LINUX-390 
-- For more 
information on Linux on System z,

Re: DIRM problem

2015-10-06 Thread Shumate, Scott

But we are required to use RACF in our shop.

Thanks
Scott


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mauro 
Souza
Sent: Tuesday, October 06, 2015 6:45 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: DIRM problem

> I'm in the process of setting up DIRMAINT AND RACF to work together so
> we
can exploit SMAPI.

If your goal is to exploit SMAPI, you don't need RACF. We use XCAT here, with 
SMAPI, without RACF, and works nicely.
On Oct 6, 2015 03:23, "Alan Altmark"  wrote:

> On Monday, 10/05/2015 at 01:42 EDT, Bruce Hayden 
> wrote:
> > What do you have for all the configuration variables that start with
> > PW_
> in
> > your CONFIG99 DATADVH file?  The expire days should be set by
> > PW_INTERVAL_FOR_SET= according to the documentation.  I'm guessing
> > it is not the default value or at least greater than zero.
> >
> > But - you say you also have RACF.  In that case, forget all of the
> > PW_ settings because RACF is the one that will be managing the passwords.
> You
> > set the password change interval, etc. using the RAC SETROPTS (set
> > RACF
> > options) command.
>
> Nah.  DIRMAINT still keeps track of when passwords were changed via
> DIRMAINT.
>
> Tearing the problem apart...
> DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2
> CONFIG
>
> This error is because there is a problem with the PW_INTERVAL_FOR_SET
> statement.  A DIRM ADD, CHNGID, or SETPW command (ADD, in this case)
> attempted to set the password validity interval to a value that is
> higher than the interval from the PW_INTERVAL_FOR_GEN statement (2nd
> value).  The default is 97 days.
>
> There is either a bug in the doc or a bug in the code.
> PW_INTERVAL_FOR_GEN is documented to have to values on it:  The first
> value specifies the number of days a password is valid following one
> of the commands that set the password for a general user, the second
> value specifies the number of days a password is valid for a privileged user.
>
> The code doesn't do that.  It assumes all users are general users as
> far as PW_INTERVAL_FOR_SET is concerned.
>
> I would do a
>DIRM CMS LISTFILE CONFIG* DATADVH * to see what configuration files
> are available.  Then I would look in all of them for a
> PW_INTERVAL_FOR_SET statement.  Not finding any, I would simply
> restart DIRMAINT.  If you comment out a statement, RLDDATA won't
> always work since as far as it's concerned, nothing is overriding the
> existing value.
>
> You can just put a null value on it.
>PW_INTERVAL_FOR_SET=
>
> Alan Altmark
>
> Senior Managing z/VM and Linux Consultant Lab Services System z
> Delivery Practice IBM Systems & Technology Group
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send
> email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/


The information in this transmission may contain proprietary and non-public 
information of BB or its affiliates and may be subject to protection under 
the law. The message is intended for the sole use of the individual or entity 
to which it is addressed. If you are not the intended recipient, you are 
notified that any use, distribution or copying of the message is strictly 
prohibited. If you received this message in error, please delete the material 
from your system without reading the content and notify the sender immediately 
of the inadvertent transmission.

Re: LVM usage

2015-10-06 Thread Grzegorz Powiedziuk

I would like also to mention that when it comes to LVM, it makes much more 
easier to manage such systems especially with FCP involved.
Imagine that you break your multipath config for example and you lose your 
“mpath” names. If you have LVM, you can still boot. LVM will just scan all your 
paths, pick the first (or last - can’t remember) available with a proper label 
and use that to bring up the vg and logical volumes. Without LVM, you will have 
to a lot of work to get system online again. 
There were few others scenarios which I can't remember now, when LVM saved me 
big time or made things a lot easier. 
 
Gregory Powiedziuk



> On Oct 6, 2015, at 3:34 AM, van Sleeuwen, Berry  
> wrote:
> 
> Actually, those were just examples. The Samba and TSM guests have the biggest 
> LVM filesystems. We have a quite a few linux guests, most of them use LVM. 
> Ranging from a small webserver to a couple of oracle database machines with 
> LVM's up to 40G.
> 
> I don’t think it matters if we are talking zVM guests or native linux 
> machines. The usage of LVM depends on what storage is available. Mainframe 
> DASD typically doesn't have the large disksizes so the smaller disks require 
> LVM or any other solution that glues disk together. But even when the storage 
> solution has the required sizes available there can be other reasons for 
> using LVM. We use LVM primarily for two reasons. First of all to glue smaller 
> disks together and secondly to spread IO onto multiple disks.
> 
> We use LVM only for user filesystems. The system data remains on non-LVM 
> disks. Most of the user data is located in /srv that is located in an LVM.
> 
> Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
> Berry van Sleeuwen
> 
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Sergey 
> Korzhevsky
> Sent: Monday, October 05, 2015 5:23 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: LVM usage
> 
> Stories about TSM and Samba are great, but this is one installation for the 
> site and we are speaking in terms of z/VM, right?
> This e-mail and the documents attached are confidential and intended solely 
> for the addressee; it may also be privileged. If you receive this e-mail in 
> error, please notify the sender immediately and destroy it. As its integrity 
> cannot be secured on the Internet, Atos’ liability cannot be triggered for 
> the message content. Although the sender endeavours to maintain a computer 
> virus-free network, the sender does not warrant that this transmission is 
> virus-free and will not be liable for any damages resulting from any virus 
> transmitted. On all offers and agreements under which Atos Nederland B.V. 
> supplies goods and/or services of whatever nature, the Terms of Delivery from 
> Atos Nederland B.V. exclusively apply. The Terms of Delivery shall be 
> promptly submitted to you on your request.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: zKVM installation problem

2015-10-06 Thread Ray Mansell


On 10/6/2015 06:27, Michael Mueller wrote:

On Mon, 5 Oct 2015 11:11:40 -0400
Ray Mansell  wrote:


I'm trying to install zKVM in a virtual machine, but no matter what
installation options I choose, I always get the following error:

2015-10-03 14:39:40,900 - controller.controller - INFO - InstallProgress
screen
2015-10-03 14:39:40,901 - controller.controller - INFO - Formatting disks...
2015-10-03 14:39:40,901 - controller.controller - INFO - Installing KVM
for IBM z into disk dasda...
2015-10-03 14:39:41,041 - model.installfunctions - INFO - Get repodata_file
2015-10-03 14:39:41,088 - model.installfunctions - CRITICAL - Failed
installSystem
2015-10-03 14:39:41,089 - model.installfunctions - CRITICAL -
EXCEPTION:
2015-10-03 14:39:41,089 - model.installfunctions - CRITICAL - local
variable 's' referenced before assignment
2015-10-03 14:39:41,089 - model.installfunctions - CRITICAL -
Stacktrace:Traceback (most recent call last):
File "/opt/ibm/kvmibm-installer/model/installfunctions.py", line 357,
in installSystem
  installPackages(rootDir, callback)
File "/opt/ibm/kvmibm-installer/model/installfunctions.py", line 749,
in installPackages
  repodata_file = getRepodataFile(repo, logger)
File "/opt/ibm/kvmibm-installer/model/installfunctions.py", line 548,
in getRepodataFile
  d = re.split('([\d\w]+-primary.sqlite.bz2)', s)
UnboundLocalError: local variable 's' referenced before assignment

2015-10-03 14:39:41,095 - controller.controller - CRITICAL - ZKVMError:
[['KVMIBMIN70500', 'Error while installing packages.'], ('INSTALLER',
'INSTALLSYSTEM', 'INSTALL_MSG')]

Help? Please?

Ray,

make sure you have copied the repodata folder from the installation image to
your ftp server. Should have the following files:

$ ls -Rl ./repodata
./repodata:
total 2284
-rw--- 1 mimu mimu 410546 Aug  6 12:11
1071bedb0b7dba6b8ed2fae387116e3f2b8160544d2abdad5411fbe8f737ff63-filelists.xml.gz
-rw--- 1 mimu mimu  14151 Aug  6 12:11
3a456231834ea9d32d6a7525ff38fe6246932c2a14d8df1b6cf75b810dc09545-KVMIBM-1.1.0-20150806-comps.xml
-rw--- 1 mimu mimu 517316 Aug  6 12:11
655cf5993b0a15383cfe5224bf2db4d95b3cba0539c3075e5fc57c3cd08ab40e-filelists.sqlite.bz2
-rw--- 1 mimu mimu 771729 Aug  6 12:11
836db89a0f5c266ea3b34d070a26cad34ad39db91a416081bcda615bb8605324-primary.sqlite.bz2
-rw--- 1 mimu mimu  76579 Aug  6 12:11
9fe8a5082cbb90e961d5e597ad6993c6a1f35035bf918b57b3fe1bba822550b8-other.xml.gz
-rw--- 1 mimu mimu  96919 Aug  6 12:11
b08023e34c172ac98447cf816543a2a02d0f9819d29cc40d375e02b37c8d6ce5-other.sqlite.bz2
-rw--- 1 mimu mimu   1706 Aug  6 12:11
d5e91197cddcab057566c403de6c1a71e3e56cec91bc95006c5dde1a69ffcba7-KVMIBM-1.1.0-20150806-comps.xml.gz
-rw--- 1 mimu mimu 398232 Aug  6 12:11
f410070319c7a1fbb90a37e20f85064390db0112a0ceb34f8c84ef4f866e5e4e-primary.xml.gz
-rw--- 1 mimu mimu   3740 Aug  6 12:11 repomd.xml
-r 1 mimu mimu   2599 Aug  6 12:16 TRANS.TBL

By moving them away I can reproduce the error message.

Michael



Aha! Thank you... I have the ISO image on a Windows machine, but the
tool I used to rip its contents truncated all the filenames to 64
characters, so obviously they could not be found. I must look for a new
ISO ripper.

Installation is now proceeding much more smoothly.

Thanks again,
Ray

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: DIRM problem

2015-10-06 Thread Alan Altmark

The directory entry you're adding doesn't have a *DVHOPT comment in it, does it?

I suggest using the debugging technique I described.

Alan Altmark
Senior Managing Consultant
IBM Systems Lab Services


   Shumate, Scott --- Re: [LINUX-390] DIRM problem --- 
From:"Shumate, Scott" To:"" 
Date:Tue, Oct 6, 2015 9:13 AMSubject:Re: [LINUX-390] 
DIRM problem
  
 CONFIG99 DATADVH is committed out. /* PW_INTERVAL_FOR_GEN= 0 0 */ CONFIG 
DATADVH is not committed out. PW_INTERVAL_FOR_GEN= 0 0 Thanks Scott 
-Original Message- From: Linux on 390 Port 
[mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan Altmark Sent: Tuesday, 
October 06, 2015 9:01 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: DIRM problem 
What does PW_INTERVAL_GEN have? The ultimate answer is to get the source for 
DVHSTPWC EXEC from MAINT630, run it through EXECUPDT, and then put traces in 
it. This is the program that issues the 3376 error. That's what I would do if I 
were on site. Alan Altmark Senior Managing Consultant IBM Systems Lab Services 
Shumate, Scott --- Re: [LINUX-390] DIRM problem --- From:"Shumate, Scott" To:"" 
Date:Tue, Oct 6, 2015 8:30 AMSubject:Re: [LINUX-390] DIRM problem I have 3 
files. CONFIG DATADVH CONFIG99 DATADVH CONFIGSS DATADVH Out of the 3 files, 2 
has PW_INTERVAL_FOR_SET= in it CONFIG DATADVH has it as PW_INTERVAL_FOR_SET= 
CONFIG99 DATADVH has it as PW_INTERVAL_FOR_SET= 90 I committed it out in CONFIG 
DATADVH did a DIRM RLDD & DIRM RLDC. It failed again with the following 
DVHREQ2288I Your ADD request for LXTEST2 at * has been accepted. DVHPWU3376E 
Days can not exceed the current password expire value of 0 DVHPWU3376E for user 
LXTEST2. DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 
CONFIG DVHREQ2289E Your ADD request for LXTEST2 at * has failed; with RC = 
DVHREQ2289E 3212. I restarted DIRMAINT and got the same results. Thanks Scott 
-Original Message- From: Linux on 390 Port 
[mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan Altmark Sent: Tuesday, 
October 06, 2015 2:21 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: DIRM problem 
On Monday, 10/05/2015 at 01:42 EDT, Bruce Hayden wrote: > What do you have for 
all the configuration variables that start with > PW_ in > your CONFIG99 
DATADVH file? The expire days should be set by > PW_INTERVAL_FOR_SET= according 
to the documentation. I'm guessing it > is not the default value or at least 
greater than zero. > > But - you say you also have RACF. In that case, forget 
all of the PW_ > settings because RACF is the one that will be managing the 
passwords. You > set the password change interval, etc. using the RAC SETROPTS 
(set > RACF > options) command. Nah. DIRMAINT still keeps track of when 
passwords were changed via DIRMAINT. Tearing the problem apart... DVHADD3212E 
Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG This error is 
because there is a problem with the PW_INTERVAL_FOR_SET statement. A DIRM ADD, 
CHNGID, or SETPW command (ADD, in this case) attempted to set the password 
validity interval to a value that is higher than the interval from the 
PW_INTERVAL_FOR_GEN statement (2nd value). The default is 97 days. There is 
either a bug in the doc or a bug in the code. PW_INTERVAL_FOR_GEN is documented 
to have to values on it: The first value specifies the number of days a 
password is valid following one of the commands that set the password for a 
general user, the second value specifies the number of days a password is valid 
for a privileged user. The code doesn't do that. It assumes all users are 
general users as far as PW_INTERVAL_FOR_SET is concerned. I would do a DIRM CMS 
LISTFILE CONFIG* DATADVH * to see what configuration files are available. Then 
I would look in all of them for a PW_INTERVAL_FOR_SET statement. Not finding 
any, I would simply restart DIRMAINT. If you comment out a statement, RLDDATA 
won't always work since as far as it's concerned, nothing is overriding the 
existing value. You can just put a null value on it. PW_INTERVAL_FOR_SET= Alan 
Altmark Senior Managing z/VM and Linux Consultant Lab Services System z 
Delivery Practice IBM Systems & Technology Group 
ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 
alan_altm...@us.ibm.com IBM Endicott 
-- For 
LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit 
http://www.marist.edu/htbin/wlvindex?LINUX-390 
-- For more 
information on Linux on System z, visit http://wiki.linuxvm.org/ The 
information in this transmission may contain proprietary and non-public 
information of BB or its affiliates and may be subject to protection under 
the law. The message is intended for the sole use of the individual or entity 
to which it is addressed. If

Re: DIRM problem

2015-10-06 Thread Shumate, Scott

CONFIG99 DATADVH is committed out.  /* PW_INTERVAL_FOR_GEN= 
0 0   */
CONFIG   DATADVH is not committed out.  PW_INTERVAL_FOR_GEN= 0 
0  


Thanks
Scott


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan 
Altmark
Sent: Tuesday, October 06, 2015 9:01 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: DIRM problem

What does PW_INTERVAL_GEN have?

The ultimate answer is to get the source for DVHSTPWC EXEC from MAINT630, run 
it through EXECUPDT, and then put traces in it.

This is the program that issues the 3376 error.

That's what I would do if I were on site.

Alan Altmark
Senior Managing Consultant
IBM Systems Lab Services


   Shumate, Scott --- Re: [LINUX-390] DIRM problem --- 
From:"Shumate, Scott" To:"" 
Date:Tue, Oct 6, 2015 8:30 AMSubject:Re: [LINUX-390] 
DIRM problem
  
 I have 3 files. CONFIG DATADVH CONFIG99 DATADVH CONFIGSS DATADVH Out of the 3 
files, 2 has PW_INTERVAL_FOR_SET= in it CONFIG DATADVH has it as 
PW_INTERVAL_FOR_SET= CONFIG99 DATADVH has it as PW_INTERVAL_FOR_SET= 90 I 
committed it out in CONFIG DATADVH did a DIRM RLDD & DIRM RLDC. It failed again 
with the following DVHREQ2288I Your ADD request for LXTEST2 at * has been 
accepted. DVHPWU3376E Days can not exceed the current password expire value of 
0 DVHPWU3376E for user LXTEST2. DVHADD3212E Unexpected RC= 3376, from: EXEC 
DVHSTPWC ADD LXTEST2 CONFIG DVHREQ2289E Your ADD request for LXTEST2 at * has 
failed; with RC = DVHREQ2289E 3212. I restarted DIRMAINT and got the same 
results. Thanks Scott -Original Message- From: Linux on 390 Port 
[mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan Altmark Sent: Tuesday, 
October 06, 2015 2:21 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: DIRM problem 
On Monday, 10/05/2015 at 01:42 EDT, Bruce Hayden  wrote: > What do you have for 
all the configuration variables that start with > PW_ in > your CONFIG99 
DATADVH file? The expire days should be set by > PW_INTERVAL_FOR_SET= according 
to the documentation. I'm guessing it > is not the default value or at least 
greater than zero. > > But - you say you also have RACF. In that case, forget 
all of the PW_ > settings because RACF is the one that will be managing the 
passwords. You > set the password change interval, etc. using the RAC SETROPTS 
(set > RACF > options) command. Nah. DIRMAINT still keeps track of when 
passwords were changed via DIRMAINT. Tearing the problem apart... DVHADD3212E 
Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG This error is 
because there is a problem with the PW_INTERVAL_FOR_SET statement. A DIRM ADD, 
CHNGID, or SETPW command (ADD, in this case) attempted to set the password 
validity interval to a value that is higher than the interval from the 
PW_INTERVAL_FOR_GEN statement (2nd value). The default is 97 days. There is 
either a bug in the doc or a bug in the code. PW_INTERVAL_FOR_GEN is documented 
to have to values on it: The first value specifies the number of days a 
password is valid following one of the commands that set the password for a 
general user, the second value specifies the number of days a password is valid 
for a privileged user. The code doesn't do that. It assumes all users are 
general users as far as PW_INTERVAL_FOR_SET is concerned. I would do a DIRM CMS 
LISTFILE CONFIG* DATADVH * to see what configuration files are available. Then 
I would look in all of them for a PW_INTERVAL_FOR_SET statement. Not finding 
any, I would simply restart DIRMAINT. If you comment out a statement, RLDDATA 
won't always work since as far as it's concerned, nothing is overriding the 
existing value. You can just put a null value on it. PW_INTERVAL_FOR_SET= Alan 
Altmark Senior Managing z/VM and Linux Consultant Lab Services System z 
Delivery Practice IBM Systems & Technology Group 
ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 
alan_altm...@us.ibm.com IBM Endicott 
-- For 
LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit 
http://www.marist.edu/htbin/wlvindex?LINUX-390 
-- For more 
information on Linux on System z, visit http://wiki.linuxvm.org/ The 
information in this transmission may contain proprietary and non-public 
information of BB or its affiliates and may be subject to protection under 
the law. The message is intended for the sole use of the individual or entity 
to which it is addressed. If you are not the intended recipient, you are 
notified that any use, distribution or copying of the message is strictly 
prohibited. If you received this message in error, please delete the material 
from your system without reading the content and notify the sender

Re: DIRM problem

2015-10-06 Thread Bruce Hayden

Don't change CONFIG DATADVH.  Comment the line out of your CONFIG99 DATADVH.

You are enabling Dirmaint with RACF because you want changes made via SMAPI
also changed (added, deleted, whatever) in RACF.  Your goal is not (just)
to exploit SMAPI, your goal is to enable it to work with your system.  And
the requirements for your system require RACF to encrypt passwords, provide
access controls, provide an audit trail, and probably more that a z/VM
system without an ESM (RACF) can't provide.

Of course it is true that you don't need RACF to exploit SMAPI, just like
you don't need RACF to run a production z/VM system.  But I'd like to see a
company security policy that documents the exception that your
virtualization platform (for example) doesn't require encrypted passwords
and enforced password change intervals.

Anyway, I'm starting to sound like Alan Altmark, so see his various posts
on the subject of securing a z/VM system.  If anyone is not paying
attention to them, you should be!

On Tue, Oct 6, 2015 at 8:28 AM, Shumate, Scott  wrote:

> I have 3 files.
>
> CONFIG DATADVH
> CONFIG99 DATADVH
> CONFIGSS DATADVH
>
> Out of the 3 files, 2 has PW_INTERVAL_FOR_SET= in it
>
> CONFIG DATADVH has it as PW_INTERVAL_FOR_SET=
> CONFIG99 DATADVH has it as PW_INTERVAL_FOR_SET= 90
>
> I committed it out in CONFIG DATADVH did a DIRM RLDD & DIRM RLDC.  It
> failed again with the following
>
>
> DVHREQ2288I Your ADD request for LXTEST2 at * has been accepted.
> DVHPWU3376E Days can not exceed the current password expire value of 0
> DVHPWU3376E for user LXTEST2.
> DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG
> DVHREQ2289E Your ADD request for LXTEST2 at * has failed; with RC =
> DVHREQ2289E 3212.
>
>
> I restarted DIRMAINT and got the same results.
>
> Thanks
> Scott
>
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> Alan Altmark
> Sent: Tuesday, October 06, 2015 2:21 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: DIRM problem
>
> On Monday, 10/05/2015 at 01:42 EDT, Bruce Hayden 
> wrote:
> > What do you have for all the configuration variables that start with
> > PW_
> in
> > your CONFIG99 DATADVH file?  The expire days should be set by
> > PW_INTERVAL_FOR_SET= according to the documentation.  I'm guessing it
> > is not the default value or at least greater than zero.
> >
> > But - you say you also have RACF.  In that case, forget all of the PW_
> > settings because RACF is the one that will be managing the passwords.
> You
> > set the password change interval, etc. using the RAC SETROPTS (set
> > RACF
> > options) command.
>
> Nah.  DIRMAINT still keeps track of when passwords were changed via
> DIRMAINT.
>
> Tearing the problem apart...
> DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG
>
> This error is because there is a problem with the PW_INTERVAL_FOR_SET
> statement.  A DIRM ADD, CHNGID, or SETPW command (ADD, in this case)
> attempted to set the password validity interval to a value that is higher
> than the interval from the PW_INTERVAL_FOR_GEN statement (2nd value).  The
> default is 97 days.
>
> There is either a bug in the doc or a bug in the code. PW_INTERVAL_FOR_GEN
> is documented to have to values on it:  The first value specifies the
> number of days a password is valid following one of the commands that set
> the password for a general user, the second value specifies the number of
> days a password is valid for a privileged user.
>
> The code doesn't do that.  It assumes all users are general users as far
> as PW_INTERVAL_FOR_SET is concerned.
>
> I would do a
>DIRM CMS LISTFILE CONFIG* DATADVH *
> to see what configuration files are available.  Then I would look in all
> of them for a PW_INTERVAL_FOR_SET statement.  Not finding any, I would
> simply restart DIRMAINT.  If you comment out a statement, RLDDATA won't
> always work since as far as it's concerned, nothing is overriding the
> existing value.
>
> You can just put a null value on it.
>PW_INTERVAL_FOR_SET=
>
> Alan Altmark
>
> Senior Managing z/VM and Linux Consultant Lab Services System z Delivery
> Practice IBM Systems & Technology Group
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send
> email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit http://wiki.linuxvm.org/
>
>
> The information in this transmission may contain proprietary and
> non-public information of BB or its affiliates and may be subject to
> protection under the law. The message is intended for the sole use of

Re: zKVM installation problem

2015-10-06 Thread Ray Mansell


On 10/6/2015 06:54, Philipp Kern wrote:

On 2015-10-05 20:26, Grzegorz Powiedziuk wrote:

I’ve seen weird python errors similar to these ones (unfortunately I
didn’t keep traces to compare) in some linux distribution during the
installation if I had a “dirty disk”.


This isn't a weird Python error. It's a straightforward coding error. 
Without having the code at hand I guess that s is only set in an "if" 
but who knows. It should at least have been initialized with 
something. At least you can just inspect the code given that it's Python.


Kind regards
Philipp Kern


Yes, I had looked at the source and indeed 's' is only set inside an 
'if', hence that particular error. However, as you will have seen in 
other responses, my actual problem appears to be with the Windows CDFS 
restricting (well, truncating) file names to 64 characters. I need to do 
some reading to find out if there's a way around that. In the meantime, 
a suitable set of 'rename' commands seems to have done the trick.


Ray

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: zKVM on zpdt

2015-10-06 Thread Mark Post

>>> On 10/6/2015 at 10:51 AM, Carsten Otte  wrote: 
> Hi Tito,
> 
> I am sorry that this time I don't have a workaround. The installer code
> assumes diag 308 IPL functions to be available, however it is'nt on zPDT. I
> believe this should be fixed in the installer. The Linux kernel propagates
> the error to the script, and it fails to handle it.

So, is it safe to say that IBM didn't test this on zPDT and that IBM doesn't 
claim it is supported on zPDT?  Or that it positively is _not_ supported on 
zPDT?  Having such a public statement might save others from some grief.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: How to force crash dump from hung Red Hat guest

2015-10-06 Thread Pedro Henrique dos Santos Principeza

Hi.

Log into the hung guest on VM and run

#CP VMDUMP

Wait for the completion of the comand, and FORCE LOGOFF the Guest.

When it comes back, use vmur Linux command to retrieve the DUMP from the VM
SPOOL, and vmconvert to make it readable by crash.

Be sure you have enough space on VM SPOOL to receive the VMDUMP output; at
least the Guest's memory size in there.

Hope that helps.

Pedro Principeza
IBM Linux Support

> On 6 de out de 2015, at 12:55, Vitale, Joseph
 wrote:
>
> Hello,
>
> Running  Red Hat 6.6  under zVM 6.3.  I had a guest hang and unable to
issue linux commands to force a kernel crash dump( echo c
> /proc/sysrq-trigger ).
>
> Any suggestions how that can be accomplished?
>
> Thanks
> Joe
>
>
> Joseph Vitale
> Technology Services Group
> Mainframe Operating Systems
>
> Pershing Plaza
> 95 Christopher Columbus Drive
> Floor 14
> Jersey City,  N.J.  07302
> Work  201-395-1509
> Cell917-903-0102
>
>
> The information contained in this e-mail, and any attachment, is
confidential and is intended solely for the use of the intended recipient.
Access, copying or re-use of the e-mail or any attachment, or any
information contained therein, by any other person is not authorized. If
you are not the intended recipient please return the e-mail to the sender
and delete it from your computer. Although we attempt to sweep e-mail and
attachments for viruses, we do not guarantee that either are virus-free and
accept no liability for any damage sustained as a result of viruses.
>
> Please refer to http://disclaimer.bnymellon.com/eu.htm for certain
disclosures relating to European legal entities.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: zKVM on zpdt

2015-10-06 Thread Christian Borntraeger

Am 06.10.2015 um 18:32 schrieb Mark Post:
 On 10/6/2015 at 10:51 AM, Carsten Otte  wrote: 
>> Hi Tito,
>>
>> I am sorry that this time I don't have a workaround. The installer code
>> assumes diag 308 IPL functions to be available, however it is'nt on zPDT. I
>> believe this should be fixed in the installer. The Linux kernel propagates
>> the error to the script, and it fails to handle it.
> 
> So, is it safe to say that IBM didn't test this on zPDT and that IBM doesn't
> claim it is supported on zPDT?  Or that it positively is _not_ supported on 
> zPDT?  Having such a public statement might save others from some grief.
> 


zKVM is supported/tested on zEC12 and zBC12 and z13.
see
http://www-03.ibm.com/systems/z/solutions/virtualization/kvm/
and click on announcement letter.

When you read between the lines "Can co-exist with z/VM virtualization
environments, Linux on z Systems, z/OS®, z/VSE®, and z/TPF in different
LPARs." this also implies that zKVM is supposed to run in LPAR.

Christian

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: How to force crash dump from hung Red Hat guest

2015-10-06 Thread Robert J Brenneman

from the guest's console issue #CP VMDUMP to trigger a CP managed dump of
the virtual machine. This dumps to spool space and it shows up in the
guest's rdr device. You can then 'vmur receive --convert 
/path/to/where/dump/goes' to import the vmcore to the Linux file system
when you IPL after the dump completes.

Make sure you have enough spool space to contain however much virtual
memory the guest is defined with. Also make sure you have time - a VMDUMP
of a 16 GB virtual machine can take on the order of 30 minutes - dumping to
spool is slow but it will save your bacon when the kdump function does not
work for whatever reason.

http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdt/lgdt_c_intro.html

On Tue, Oct 6, 2015 at 11:41 AM, Vitale, Joseph  wrote:

> Hello,
>
> Running  Red Hat 6.6  under zVM 6.3.  I had a guest hang and unable to
> issue linux commands to force a kernel crash dump( echo c >
> /proc/sysrq-trigger ).
>
> Any suggestions how that can be accomplished?
>
> Thanks
> Joe
>
>
> Joseph Vitale
> Technology Services Group
> Mainframe Operating Systems
>
> Pershing Plaza
> 95 Christopher Columbus Drive
> Floor 14
> Jersey City,  N.J.  07302
> Work  201-395-1509
> Cell917-903-0102
>
>
> The information contained in this e-mail, and any attachment, is
> confidential and is intended solely for the use of the intended recipient.
> Access, copying or re-use of the e-mail or any attachment, or any
> information contained therein, by any other person is not authorized. If
> you are not the intended recipient please return the e-mail to the sender
> and delete it from your computer. Although we attempt to sweep e-mail and
> attachments for viruses, we do not guarantee that either are virus-free and
> accept no liability for any damage sustained as a result of viruses.
>
> Please refer to http://disclaimer.bnymellon.com/eu.htm for certain
> disclosures relating to European legal entities.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>



--
Jay Brenneman

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: How to force crash dump from hung Red Hat guest

2015-10-06 Thread Christian Borntraeger

Am 06.10.2015 um 17:41 schrieb Vitale, Joseph:
> Hello,
>
> Running  Red Hat 6.6  under zVM 6.3.  I had a guest hang and unable to issue 
> linux commands to force a kernel crash dump( echo c > /proc/sysrq-trigger ).
>
> Any suggestions how that can be accomplished?
>

If kdump is setup properly, then a PSW restart should do the trick.
On HMC/LPAR->recovery->PSW restart, on your z/VM the CP command it is #cp 
system restart

You can also setup the z/VM watchdog to do that.


A pretty good overview is here:
http://events.linuxfoundation.org/sites/events/files/eeus13_holzheu.pdf

Christian

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: zKVM on zpdt

How to force crash dump from hung Red Hat guest

Re: How to force crash dump from hung Red Hat guest

Re: LVM usage

Re: DIRM problem

Re: How to force crash dump from hung Red Hat guest - Thank You all

Re: How to force crash dump from hung Red Hat guest

LVM usage - Thank you very much!

Re: How to force crash dump from hung Red Hat guest

Re: zKVM installation problem

Re: DIRM problem

Re: zKVM installation problem

Re: DIRM problem

Re: DIRM problem

Re: DIRM problem

Re: LVM usage

Re: zKVM installation problem

Re: DIRM problem

Re: DIRM problem

Re: DIRM problem

Re: zKVM installation problem

Re: zKVM on zpdt

Re: How to force crash dump from hung Red Hat guest

Re: zKVM on zpdt

Re: How to force crash dump from hung Red Hat guest

Re: How to force crash dump from hung Red Hat guest

26 matches

Site Navigation

Mail list logo

Footer information