Mike, That is essentially what we did here. We have a rexx exec that finds unused disk volumes in the VM world, formats them, builds a new VM directory entry in Dirmaint and then xautologs the system. The system built consists of a base set of disk volumes that are a "gold" image and adds a variable bunch of extra volumes for guest-specific user files.
When the new guest is logged on, the variable dasd is formatted with dasdfmt with the -k option to keep the volumes with the same volser. We found the same thing here...format once with the -l option works fine, format the second time with -k and also works. BUT, format the first time with -k and it fails. George -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Michael MacIsaac Sent: Monday, November 03, 2014 3:06 PM To: [email protected] Subject: Re: dasdfmt problem when building a new Red Hat guest 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 > https://urldefense.proofpoint.com/v2/url?u=http-3A__intranet.ds.global > _technology_&d=AAIFaQ&c=9g4MJkl2VjLjS6R4ei18BA&r=uB-ntpnDBFIYIPKAN9MV- > x-FvB91uC-npAN6JlAJjjI&m=dIad749vxEq1VuKlFDZ-xuvTTCkaRM5_u_dBsmCcvrU&s > =pp-Z-I94XtzSbArHP5CLSLgUYUhPhmL3LhewcLrO-MI&e= > > > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit https://urldefense.proofpoint.com/v2/url?u=http-3A__www.marist.edu_htbin_wlvindex-3FLINUX-2D390&d=AAIFaQ&c=9g4MJkl2VjLjS6R4ei18BA&r=uB-ntpnDBFIYIPKAN9MV-x-FvB91uC-npAN6JlAJjjI&m=dIad749vxEq1VuKlFDZ-xuvTTCkaRM5_u_dBsmCcvrU&s=ijgBK9dMgVEuJSxBPbKDwcZBwBQlLCPxD6oL0LPLo3U&e= ---------------------------------------------------------------------- For more information on Linux on System z, visit https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.linuxvm.org_&d=AAIFaQ&c=9g4MJkl2VjLjS6R4ei18BA&r=uB-ntpnDBFIYIPKAN9MV-x-FvB91uC-npAN6JlAJjjI&m=dIad749vxEq1VuKlFDZ-xuvTTCkaRM5_u_dBsmCcvrU&s=PNAq9e87N08C3iNpLjGW6Jv49opp_Q6sVGNOm-Xqwlg&e=
