Also, if you have dasd that is EMIFd to n LPARS, how do you know (a) whether a disk is spare or in use if all of the dasd have volsers ZLnnnn, and (b) if in use, by which LPAR? IO can see using VMnnnn as an indicator that a volume has not yet been deployed, but once it has, it needs to be labeled using another convention. Since we seem to replace our DASD farm every 2 or 3 years, device number has no place in the scheme other than to denote a spare volume.
Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Michael MacIsaac Sent: Friday, August 27, 2010 5:31 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLID's > That is absolutely the wrong thing to do. Is it so black and white? Our team has been using this convention for a number of years and it has worked fine for us. However, I will admit we have never been asked to migrate to a new disk array. I believe the main argument for not using the rdevs in the volser is that after migration, the volsers will be wrong (e.g. migrate VM2222 at rdev 2222 to a new DASD at rdev 4444 and the volser convention is now wrong - the DASD at 4444 now has a volser of VM2222). I understand that changing the volsers throughout the (perhaps) many z/VM systems would be labor-intensive and perhaps error prone (e.g. clipping the VM2222 to VM4444 and then making sure that all references to VM2222 are updated correctly). I agree that allowing this would break the convention and then things would become very confusing. But, is there not a model whereby the new DASD can have the same rdev range as the old DASD? For example: 1) Put the new DASD online assigning it a temporary range of rdevs (e.g. 4444) 2) FLASHCOPY/DDR the old DASD to the new DASD (e.g. 2222 => 4444, and every other DASD in a z/VM LPAR) 3) Reassign the new DASD the old DASD's address ranges, and take the old DASD offline 4) Restart the LPAR. This should work on paper, but I may be missing something obvious. Yes, it would require more interaction with "the hardware guys". Has anyone used this model? I'm just trying to understand and appreciate the wisdom of the community, where many have much more experience as sysadmins than I. Thanks. "Mike MacIsaac" <mike...@us.ibm.com> (845) 433-7061
