I would imagine there is some and IBM might have an clear answer there, but the managability might make it worth it in complex shops. I think it definitely would here. The granularity is important too. I'd hate to give folks 24G when they only need 500M more.
Marcy "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Ward, Mike S Sent: Wednesday, March 24, 2010 1:51 PM To: [email protected] Subject: Re: [IBMVM] initializing z/Linux disks I thought there was overhead in specifying it as a minidisk rather than a dedicated full disk. The overhead would be in the translation of the I/O addresses and such. You know like linux reading cyl 0 when it's really cyl 1 etc.... Is there still that type of overhead in VM? -----Original Message----- From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Marcy Cortes Sent: Wednesday, March 24, 2010 1:40 PM To: [email protected] Subject: Re: initializing z/Linux disks You can DEDICATE by label rather than by real address. But I still don't like Linux having cyl 0 :) Marcy "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of David Boyes Sent: Wednesday, March 24, 2010 11:20 AM To: [email protected] Subject: Re: [IBMVM] initializing z/Linux disks On 3/24/10 1:53 PM, "Martin, Terry R. (CMS/CTR) (CTR)" <[email protected]> wrote: > > Hi > > I have a question. What I have been doing up to this point for a new z/Linux > guest build is, not necessarily in this order and does not necessarily include > all steps but, > > Crave out the DASD for the z/Linux guest > > Init the DASD using CPFMTXA putting a label on the disk > > Setting up the Directory entry for the new guest, which includes specifying > the MDISK for all of the DASD for the guest. Unless you are giving the guest the real cyl 0, you need to do the format for at least real cyl 0 with ICKDSF (what CPFMTXA runs under the covers) to put a real volume id on the pack. I find that even if you are giving the guest the real cyl 0, the extra step of running DSF on the entire real volume eliminates any past uses that may confuse system operation later on (think about what would happen if you "accidentally" gave a guest what used to be a VM paging pack, and forgot to clip the allocation bitmap to remove the page space. Bad Things Ensue. Kickstart and VM paging space are NOT compatible. Things Go Boom. Trust Me.) So, if you are giving the guest the full physical volume, you don't HAVE to do the DSF run, but it's an extra safety measure that it doesn't cost much to do, and you'll be grateful for if you ever need it. > If not I assume then I would replace the MDISK statements in the Directory > entry with DEDICATE statements for each one of the DISKS. We do not share DASD > between guests here so what is defined to the guest belongs to that guest > only. Is there anything to be aware of by changing to DEDICATE statements from > MDISK statements? DEDICATEs tie you very firmly to specific physical configurations. Does your DR configuration have exactly the same device addresses for real devices? If not, then you'll have to update the directory when you move to to DR vs just changing volume labels which aren't bound to specific device addresses. You can do search/replace in both cases, but it's a lot easier to relabel packs when you restore your stuff on them than have to screw around with addresses, especially if it's a REAL emergency and you may not get your normal DR configuration because of a sudden influx of companies needing DR. > My only concern is with the DFDSS backups that I do on the z/OS for the > guests. I am not sure if it matters or not to DFDSS whether the pack was > initialized via CPFMTXA or z/Linux during the kick start process? It shouldn't, but why introduce another variable? CP and z/OS have been getting along well for decades now. It's a one-time step, and it doesn't take that much longer. You can also shortcut the process (if you have Flashcopy) by keeping a blank formatted volume around, flashcopy it to the new disks, and then just run DSF on cyl 0 to relabel the pack. That's almost instantaneous, and you get the best of both worlds. -- db ========================== This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
