George,
Yes, I just saw the same behavior. Here's what I did:
-) CPFMTXA'd a 3390-3
-) Added it to DirMaint and attached it to SYSTEM
-) Defined it as a minidisk (400) to a Linux machine (0 END), shut down,
logged off, logged back on and booted Linux
-) Logged on Linux and:
# *lsdasd*
Bus-ID Status Name Device Type BlkSz Size Blocks
==============================================================================
0.0.0100 active dasda 94:0 ECKD 4096 6831MB 1748880
0.0.0200 active dasdb 94:4 ECKD 4096 210MB 54000
0.0.0400 n/f dasdc 94:8 ECKD
# *dasdfmt -b 4096 -k -f /dev/dasdc*
dasdfmt: VOLSER not found on device /dev/dasdc
-) Then I kept going and did a dasdfmt with the -l flag and the correct
volser - this succeeded
-) Then I re-ran dasdfmt with the -k flag - this also succeeded.
So it looks like dasdfmt is not recognizing a volser initialized by
CPFMTXA, but is recognizing one formatted by itself. This arguably sounds
like a bug to me.
-Mike MacIsaac
On Mon, Nov 3, 2014 at 1:25 PM, Shedlock, George <
[email protected]> wrote:
> We are going a little bit crazy trying to figure out a process to
> initialize PAV capable volumes for our zLinux guests.
>
>
> Because we assign disk packs to only one guest we are using the full-pack
> minidisk method of enabling HyperPAV (per page 469 in “The Virtualization
> Cookbook for IBM z/VM 6.3, RHEL 6.4, and SLES 11 SP3”). The problem that
> we’re having is how to hand off the task of initializing the disk volumes
> for zLinux with as little chance for error as possible. I don’t want to
> have our Linux/Unix admins to have to retype the volsers that we’ve already
> assigned to the disks. The chances of a finger check are too great and any
> errors are a significant problem since we depend (as does zVM) on volsers
> being unique across the system.
>
> When we create the guest we format and label the volumes using ICKDSF.
>
> According to the Cookbook one of the first steps in making the disk
> available to zLinux is to run a dasdfmt command against the disk.
>
> According to “Device Drivers, Features, and Commands on Red Hat Enterprise
> Linux 7”, dasdfmt has an option –k
>
> -k or --keep_volser
> keeps the volume serial number when writing the volume label (see VOLSER).
> Keeping the volume serial number is useful, for example, if the volume
> serial
> number was written with a z/VM tool and should not be overwritten.
>
> However, whenever we try to run dasdfmt with that option we get the
> following error
>
> [root@dcvml29 ~]# dasdfmt -b 4096 -y -v -k -f /dev/dasdf
> dasdfmt: VOLSER not found on device /dev/dasdf
>
> I’ve tried various kinds of formats
>
> CPVOL FMT MODE(ESA) UNIT(7625) VFY(0X0400) VOLID(VH2905) -
> RANGE(0,10016)
>
> INIT UNIT(7625) VFY(VH2905) VOLID(VH2905) -
> CYLRANGE(0,10016) -
> PURGE NOVALIDATE VTOC(000,01,14) INDEX(015,00,15)
>
> And using CPFMTXA but nothing I do writes a VOLSER that RedHat will find
> on the volume.
>
> The Cookbook implies (around that same page) but doesn’t come out directly
> to say that –k doesn’t work as designed. Do you know of any way that we
> can format a DASD volume on zVM and have the VOLSER be acceptable to zLinux?
>
> Any insights are most appreciated.
>
>
> George Shedlock Jr
>
>
> 10300 Ormsby Park Place
> [email protected]
> Louisville, KY 40223 T +1 502 560
> 3541
> http://intranet.ds.global/technology/
>
>
>
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] 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/
