Re: initializing z/Linux disks
On Friday, 03/26/2010 at 12:26 EDT, "Schuh, Richard" wrote: > As evidenced by the statements in the post repeated below, there is discussion > of the offset from real cylinder 0 to real cylinder 1. That implies a protected > cylinder 0 and necessitates CCW translation, does it not? As you stated, it is > slower, but not as much slower as it was in VM/370 Release x (you supply the > value for x). With few exceptions, all I/O goes through CCW translation. Non-fullpack minidisks go through cylinder translation and limit checking. "Fast CCW translation" was a VM/XA invention, I think, wherein dasd channel programs that don't require excessive CP "handling" can take an expedited path through the translation code. > The whole discussion seems to have been about protecting real cylinder 0, and > whether the overhead involved in doing so would be too onerous. The sentiment I > get from the posts is that (a) it is not too much of a burden, and (b) the > protection afforded by protecting the cylinder is well worth the price. The > only way to know for certain if that is true for you is to experience a failure > due to not protecting the cylinder and see what it takes to recover. Or you > could take out an insurance policy by protecting the volume labels. It is a > question of risk vs. reward. You said it better than I did. CCW translation speed is a red herring and only serves to distract from the far more important system management issues: It's ok to let guests play with cylinder zero as long as you can tolerate mangled labels (Backup/Restore/DR?) and you take the steps needed to protect your system and your users from malicious guests. (All unprivileged guests are considered to be Evil, doing their best to spread mayhem and Corruption. Fortunately, z/VM is up to the task.) Alan Altmark z/VM Development IBM Endicott
Re: initializing z/Linux disks
On Friday, 03/26/2010 at 12:45 EDT, RPN01 wrote:
> Ah, but while that was true of a ?real? 3390, is that also now true of
emulated
> 3390?s which are split across varying numbers of essentially SCSI disks?
A
> single 3390 mod 27 might be split up over several 9 gig physical disks
in order
> to implement the emulation. Is the controller smart enough to be able to
start
> an I/O to each, even though the I/O?s were sent to the same 3390
address?
>
> The waters get muddier every day
I'll agree with Mark that isn't very muddy at all. A "volume" has been an
abstract concept for quite a while now; controllers can do whatever they
want and it doesn't affect the rules for SSCH-style I/O. The controller's
goal is to give Device End back to the channel as quickly as possible once
the data is in a safe place (usually non-volatile cache) awaiting final
disposition.
PAV does not allow multiple I/Os to the same subchannel. Rather, it
creates additional "alias" subchannels ("exposures" in ancient parlance)
that map to the same volume. I/O to each subchannel follows the normal
I/O rules: you can't start another one until the current one finishes.
Very much like shared dasd on separate chpids, but done on a single chpid
instead. For guests that understand PAV, you can dedicate the base and
alias subchannels to the guest and it will discover and handle it.
Alan Altmark
z/VM Development
IBM Endicott
Re: initializing z/Linux disks
But just to push things a bit further, isn't PAV the key to getting into the rat's nest successfully? If a volume has PAV aliases, then CP can start more than one I/O on the volume at a time. And, if it is sufficiently broken into smaller minidisks, then Linux can take advantage of the PAV paths to the 3390 volume through the PAV aliases and the physical I/O's will be divided up among the emulating disks as appropriate. Since my head is beginning to hurt (and yours as well, now) I'll leave it alone at this point. :D -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 3/26/10 11:55 AM, "Mark Post" wrote: On 3/26/2010 at 12:44 PM, RPN01 wrote: >> Is the controller smart enough to >> be able to start an I/O to each, even though the I/O*s were sent to the same >> 3390 address? > > It might be, but CP and Linux are not, so the waters aren't all that muddy > after all. We really don't want to try to look behind the illusion that > storage arrays present to the CEC. That's a real rat's nest that would be too > difficult to keep up with over time, which is why the illusion is presented in > the first place. > > > Mark Post
Re: initializing z/Linux disks
>>> On 3/26/2010 at 12:44 PM, RPN01 wrote: > Is the controller smart enough to > be able to start an I/O to each, even though the I/O*s were sent to the same > 3390 address? It might be, but CP and Linux are not, so the waters aren't all that muddy after all. We really don't want to try to look behind the illusion that storage arrays present to the CEC. That's a real rat's nest that would be too difficult to keep up with over time, which is why the illusion is presented in the first place. Mark Post
Re: initializing z/Linux disks
Ah, but while that was true of a ³real² 3390, is that also now true of emulated 3390¹s which are split across varying numbers of essentially SCSI disks? A single 3390 mod 27 might be split up over several 9 gig physical disks in order to implement the emulation. Is the controller smart enough to be able to start an I/O to each, even though the I/O¹s were sent to the same 3390 address? The waters get muddier every day -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 3/25/10 1:43 PM, "Kris Buelens" wrote: > There is maybe some misunderstanding: (leaving out PAV a while) a device can > handle only 1 IO at a time, guests know that, CP too. So indeed a linux will > not send a new IO if the previous one to that disk hasn't ended yet, the guets > will queue it. With several guests with minidisks on the same disk, CP will > queue the requests. Multipathing doesn't change that. > Multipathing helps in cases where the device is not busy, but the channel or > control unit is. > > PAV simplified: with PAV, you make appear a single disk as if it were many > disks, but for each PAV address the old rule is still valid: one IO at a time. > If you guest is PAV aware, it can also avoid queuing, if not, putting many > guests on the same volume and let CP exploit PAV can improve IO rates. > > 2010/3/25 RPN01 >> Another point I¹ve not seen mentioned, and I¹m not sure if it¹s true or >> not... >> >> Given a dedicated volume to a Linux guest, won¹t the guest start only one I/O >> to the device at a time, and wait for it to complete? If you break up a >> larger volume into several minidisks (like a mod 27 into mod 9¹s) aren¹t you >> allowing the z/VM multipathing to do its job more efficiently, even if you >> give all the smaller volumes to the same Linux guest? >> >> Like I said, I may be totally off base, but this is the impression I¹ve >> had...
Re: initializing z/Linux disks
Alan Altmark said: "Mike said "minidisk rather than a dedicated full disk." Since the context of prior posts was full-pack minidisks (FPMD), I applied the same qualifier to Mike's use of "minidisk". I'm not going to try to compare the CCW translation costs of a non-FPMD to a dedicated device other than to say that it's slower as there's more to do. "CCW translation is the same for FPMD as for a dedicated device. "Alan Altmark z/VM Development" As evidenced by the statements in the post repeated below, there is discussion of the offset from real cylinder 0 to real cylinder 1. That implies a protected cylinder 0 and necessitates CCW translation, does it not? As you stated, it is slower, but not as much slower as it was in VM/370 Release x (you supply the value for x). The whole discussion seems to have been about protecting real cylinder 0, and whether the overhead involved in doing so would be too onerous. The sentiment I get from the posts is that (a) it is not too much of a burden, and (b) the protection afforded by protecting the cylinder is well worth the price. The only way to know for certain if that is true for you is to experience a failure due to not protecting the cylinder and see what it takes to recover. Or you could take out an insurance policy by protecting the volume labels. It is a question of risk vs. reward. RS Date: Wed, 24 Mar 2010 15:50:58 -0500 Reply-To: The IBM z/VM Operating System Sender: The IBM z/VM Operating System From: "Ward, Mike S" Subject: Re: initializing z/Linux disks In-Reply-To: A Content-Type: text/plain; charset="us-ascii" 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?
Re: initializing z/Linux disks
On Thursday, 03/25/2010 at 11:45 EDT, RPN01 wrote: > Another point I?ve not seen mentioned, and I?m not sure if it?s true or not... > > Given a dedicated volume to a Linux guest, won?t the guest start only one I/O > to the device at a time, and wait for it to complete? If you break up a larger > volume into several minidisks (like a mod 27 into mod 9?s) aren?t you allowing > the z/VM multipathing to do its job more efficiently, even if you give all the > smaller volumes to the same Linux guest? > > Like I said, I may be totally off base, but this is the impression I?ve had... Yes, PAV support allows CP to do (in your example) multiple to the same volume, but there will still be only one I/O per minidisk. (HyperPAVs work only on full-pack minidisks.) Alan Altmark z/VM Development IBM Endicott
Re: initializing z/Linux disks
On Thursday, 03/25/2010 at 12:11 EDT, "Schuh, Richard" wrote: > With it not being a full-pack as Mike mentioned in his post, there would always > have to be CCW translation, would there not? The question is whether that is a > significant hit compared to the full pack including Cyl 0. Considering that, in > the olden days, CP overhead was quite high compared to today, the performance > hit, while there, might not be sufficient to be a cause of concern. Mike said "minidisk rather than a dedicated full disk." Since the context of prior posts was full-pack minidisks (FPMD), I applied the same qualifier to Mike's use of "minidisk". I'm not going to try to compare the CCW translation costs of a non-FPMD to a dedicated device other than to say that it's slower as there's more to do. CCW translation is the same for FPMD as for a dedicated device. Alan Altmark z/VM Development IBM Endicott
Re: initializing z/Linux disks
There is maybe some misunderstanding: (leaving out PAV a while) a device can handle only 1 IO at a time, guests know that, CP too. So indeed a linux will not send a new IO if the previous one to that disk hasn't ended yet, the guets will queue it. With several guests with minidisks on the same disk, CP will queue the requests. Multipathing doesn't change that. Multipathing helps in cases where the device is not busy, but the channel or control unit is. PAV simplified: with PAV, you make appear a single disk as if it were many disks, but for each PAV address the old rule is still valid: one IO at a time. If you guest is PAV aware, it can also avoid queuing, if not, putting many guests on the same volume and let CP exploit PAV can improve IO rates. 2010/3/25 RPN01 > Another point I’ve not seen mentioned, and I’m not sure if it’s true or > not... > > Given a dedicated volume to a Linux guest, won’t the guest start only one > I/O to the device at a time, and wait for it to complete? If you break up a > larger volume into several minidisks (like a mod 27 into mod 9’s) aren’t you > allowing the z/VM multipathing to do its job more efficiently, even if you > give all the smaller volumes to the same Linux guest? > > Like I said, I may be totally off base, but this is the impression I’ve > had... > > -- > Robert P. Nix Mayo Foundation.~. > RO-OE-5-55 200 First Street SW/V\ > 507-284-0844 Rochester, MN 55905 /( )\ > -^^-^^ > "In theory, theory and practice are the same, but > in practice, theory and practice are different." > > > > On 3/24/10 2:38 PM, "Scott Rohling" wrote: > > I would not recommend using DEDICATE -- why would you do that rather than > use minidisks? What you need to be aware of is that if you DEDICATE -- > Linux will label the DASD -- and that's what you'll see at the z/VM level -- > and are likely to see duplicate labels. (to things like 0x0200 and 0x0300, > etc...).Also - if you dedicate - you can't use things like DIRMAINT do > manage your dasd and keep things in pools, etc -- you have to manage it all > yourself. > > On Wed, Mar 24, 2010 at 11:53 AM, Martin, Terry R. (CMS/CTR) (CTR) < > terry.mar...@cms.hhs.gov> 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. > > We back up our z/Linux guests on the z/OS side with DFDSS. > > My question is since when we Kick Start the new z/Linux guest and it > initializes the DASD during this process is there any compelling reason for > me to initialize the DASD up front before the guest is Kick Started for the > first time basically doing a double INIT? > > 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? > > 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? > > > *Thank You, > > Terry Martin > Lockheed Martin - Citic > z/OS and z/VM Performance Tuning and Operating Systems Support > Office - 443 348-2102 > Cell - 443 632-4191 > > * > > > > -- Kris Buelens, IBM Belgium, VM customer support
Re: initializing z/Linux disks
> You know the old virtualization saying, "Never depend on the kindness > of > guests." > > Alan Altmark One might be entertaining angels unaware...8-)
Re: initializing z/Linux disks
Alan, With it not being a full-pack as Mike mentioned in his post, there would always have to be CCW translation, would there not? The question is whether that is a significant hit compared to the full pack including Cyl 0. Considering that, in the olden days, CP overhead was quite high compared to today, the performance hit, while there, might not be sufficient to be a cause of concern. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark > Sent: Wednesday, March 24, 2010 8:08 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: initializing z/Linux disks > > On Wednesday, 03/24/2010 at 04:51 EDT, "Ward, Mike S" > > wrote: > > 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? > > Back in the native-mode days, there would be I/O assist for > dedicated devices that wouldn't be provided to a full-pack > minidisk. In an LPAR, the I/O assist isn't available to CP > (LPAR is using it), so CP is already handling the guest I/O. > Eric or Steve will have the definitive answer, but I > speculate that full-pack minidisks and dedicated dasd > generally take the same shortcuts for geometry issues. E.g. > no need to modify cylinder numbers. > > I'm guessing one of big differences, however, is the lack of > minidisk cache (MDC) for dedicated devices. In some cases > that's a help and others a hinderance. If it hurts, we give > you the ability to turn off MDC for a minidisk. > > Alan Altmark > z/VM Development > IBM Endicott >
Re: initializing z/Linux disks
Another point I¹ve not seen mentioned, and I¹m not sure if it¹s true or not... Given a dedicated volume to a Linux guest, won¹t the guest start only one I/O to the device at a time, and wait for it to complete? If you break up a larger volume into several minidisks (like a mod 27 into mod 9¹s) aren¹t you allowing the z/VM multipathing to do its job more efficiently, even if you give all the smaller volumes to the same Linux guest? Like I said, I may be totally off base, but this is the impression I¹ve had... -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 3/24/10 2:38 PM, "Scott Rohling" wrote: > I would not recommend using DEDICATE -- why would you do that rather than use > minidisks? What you need to be aware of is that if you DEDICATE -- Linux > will label the DASD -- and that's what you'll see at the z/VM level -- and are > likely to see duplicate labels. (to things like 0x0200 and 0x0300, > etc...). Also - if you dedicate - you can't use things like DIRMAINT do > manage your dasd and keep things in pools, etc -- you have to manage it all > yourself. > > On Wed, Mar 24, 2010 at 11:53 AM, Martin, Terry R. (CMS/CTR) (CTR) > 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. >> >> We back up our z/Linux guests on the z/OS side with DFDSS. >> >> My question is since when we Kick Start the new z/Linux guest and it >> initializes the DASD during this process is there any compelling reason for >> me to initialize the DASD up front before the guest is Kick Started for the >> first time basically doing a double INIT? >> >> 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? >> >> 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? >> >> >> Thank You, >> >> Terry Martin >> Lockheed Martin - Citic >> z/OS and z/VM Performance Tuning and Operating Systems Support >> Office - 443 348-2102 >> Cell - 443 632-4191 >> >> > >
Re: initializing z/Linux disks
On Wednesday, 03/24/2010 at 04:31 EDT, David Boyes wrote: > On 3/24/10 3:40 PM, "Alan Altmark" wrote: > > > When giving guests access to real cyl 0, I suggest: > > 1. If using a full-pack mindisk, use the DEVNO version instead of volser. > > That way it doesn't matter if the guest changes the label. > > Doesn't that also bind you to specific device addresses? Yes, and that's the point; the guest is tied to a specific spinning entity. It's a Good Thing. If you want to change the association, change it. If the guest changes the volser, then MDISK won't be created the next time the user logs on. You know the old virtualization saying, "Never depend on the kindness of guests." Alan Altmark z/VM Development IBM Endicott
Re: initializing z/Linux disks
Thanks all for the information. As far as DEDICATING the volume is concerned I thought that the I/O overhead was cheaper that is why I was wondering about this. I am fine with doing the way I have always done it (MDISK) but someone had suggested this to me and I wanted to find out more about the pros and cons. In terms of the INIT I just thought since z/Linux was doing the Initialization at Kick Start time in my case that it did not make sense to init the DASD twice. I did not think about Cyl0. Thanks again for all the help as always it has been enlightening! Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Wednesday, March 24, 2010 3:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: initializing z/Linux disks Terry -- You have to init the DASD when using minidisks- using CPFMTXA to put a label on -- and you also want to format cylinder 0 to ensure it's seen as a CP volume. When the zLinux guest does an 'init' -- it is doing a format of the whole disk - not just an 'init' and label. You can preformat minidisks in Linux format if you want to avoid the time Linux takes to do it at kickstart... if that's what you're looking for. I would not recommend using DEDICATE -- why would you do that rather than use minidisks? What you need to be aware of is that if you DEDICATE -- Linux will label the DASD -- and that's what you'll see at the z/VM level -- and are likely to see duplicate labels. (to things like 0x0200 and 0x0300, etc...).Also - if you dedicate - you can't use things like DIRMAINT do manage your dasd and keep things in pools, etc -- you have to manage it all yourself. I'm not sure how DFDSS reacts to Linux formatted volumes, offhand .. it does fine with CPVOL volumes and minidisks. Anyway - I'm not a fan of dedicate's - as you can tell ;-) Scott Rohling On Wed, Mar 24, 2010 at 11:53 AM, Martin, Terry R. (CMS/CTR) (CTR) wrote: Error! Filename not specified. 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. We back up our z/Linux guests on the z/OS side with DFDSS. My question is since when we Kick Start the new z/Linux guest and it initializes the DASD during this process is there any compelling reason for me to initialize the DASD up front before the guest is Kick Started for the first time basically doing a double INIT? 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? 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? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 Error! Filename not specified.
Re: initializing z/Linux disks
On Wednesday, 03/24/2010 at 04:51 EDT, "Ward, Mike S" wrote: > 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? Back in the native-mode days, there would be I/O assist for dedicated devices that wouldn't be provided to a full-pack minidisk. In an LPAR, the I/O assist isn't available to CP (LPAR is using it), so CP is already handling the guest I/O. Eric or Steve will have the definitive answer, but I speculate that full-pack minidisks and dedicated dasd generally take the same shortcuts for geometry issues. E.g. no need to modify cylinder numbers. I'm guessing one of big differences, however, is the lack of minidisk cache (MDC) for dedicated devices. In some cases that's a help and others a hinderance. If it hurts, we give you the ability to turn off MDC for a minidisk. Alan Altmark z/VM Development IBM Endicott
Re: initializing z/Linux disks
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:ib...@listserv.uark.edu] On Behalf Of Ward, Mike S Sent: Wednesday, March 24, 2010 1:51 PM To: IBMVM@LISTSERV.UARK.EDU 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:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes Sent: Wednesday, March 24, 2010 1:40 PM To: IBMVM@LISTSERV.UARK.EDU 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:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Wednesday, March 24, 2010 11:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] initializing z/Linux disks On 3/24/10 1:53 PM, "Martin, Terry R. (CMS/CTR) (CTR)" 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
Re: initializing z/Linux disks
When you subscribed to the listserver, you would have received an email that contained this sentence: You may leave the list at any time by sending a "SIGNOFF IBMVM" command tolists...@listserv.uark.edu. On 03/24/2010 03:53 PM, Baxter, Justen wrote: How do I sign off of this particular listserv? Thanks, Justen Justen Baxter Technical Recruiter Washington DC/Baltimore Region Compuware Corporation 703-749-8555 justen.bax...@compuware.com -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2010 - Apr 9-13, 2010 Covington, KY
Re: initializing z/Linux disks
How do I sign off of this particular listserv? Thanks, Justen Justen Baxter Technical Recruiter Washington DC/Baltimore Region Compuware Corporation 703-749-8555 justen.bax...@compuware.com The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ward, Mike S Sent: Wednesday, March 24, 2010 4:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: 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:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes Sent: Wednesday, March 24, 2010 1:40 PM To: IBMVM@LISTSERV.UARK.EDU 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:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Wednesday, March 24, 2010 11:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] initializing z/Linux disks On 3/24/10 1:53 PM, "Martin, Terry R. (CMS/CTR) (CTR)" 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&#x
Re: 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:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes Sent: Wednesday, March 24, 2010 1:40 PM To: IBMVM@LISTSERV.UARK.EDU 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:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Wednesday, March 24, 2010 11:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] initializing z/Linux disks On 3/24/10 1:53 PM, "Martin, Terry R. (CMS/CTR) (CTR)" 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.
Re: initializing z/Linux disks
On 3/24/10 4:20 PM, "Marcy Cortes" wrote: > >> why would you do that rather than use minidisks >> Just curious, if XRC is wanted, VM doesn't timestamp I/Os, but linux does? If >> you use dedicates, isn't the data movers happier? > > only a wee bit happier for the cyl 0 VM writes on. Linux will still timestamp > on minidisks. and if you need VM timestamped, call IBM. Call them anyway. If VM is going to be a strategic player in whatever IBM dreams up for GDPSng, it's going to have to play by the rules...
Re: initializing z/Linux disks
On 3/24/10 3:40 PM, "Alan Altmark" wrote: > When giving guests access to real cyl 0, I suggest: > 1. If using a full-pack mindisk, use the DEVNO version instead of volser. > That way it doesn't matter if the guest changes the label. Doesn't that also bind you to specific device addresses? > 2. Use the various xxx_AT_IPL options in SYSTEM CONFIG to control the > RDEVs that your system will use for CP-owned and user volumes listed in > SYSTEM CONFIG. Once the system is up, have AUTOLOG1 bring any remaining > dasd volumes online. The purpose of these actions is to prevent CP from > grabbing the wrong volume at IPL. Also good comment.
Re: initializing z/Linux disks
> why would you do that rather than use minidisks > Just curious, if XRC is wanted, VM doesn't timestamp I/Os, but linux does? > If you use dedicates, isn't the data movers happier? only a wee bit happier for the cyl 0 VM writes on. Linux will still timestamp on minidisks. and if you need VM timestamped, call IBM. marcy
Re: initializing z/Linux disks
>> z/OS duke that one out, and let Linux get on with doing useful stuff. >When giving guests access to real cyl 0, I suggest: >1. If using a full-pack mindisk, use the DEVNO version instead of volser. >That way it doesn't matter if the guest changes the label. Unless you use mirroring and move to the secondaries and get a new address. GDPS doc says use volser. :) Marcy
Re: initializing z/Linux disks
> why would you do that rather than use minidisks Just curious, if XRC is wanted, VM doesn't timestamp I/Os, but linux does? If you use dedicates, isn't the data movers happier? > like 0x0200 and 0x0300 You can use CDL and specify the volume label; dasdfmt -p -b 4096 -l LNX012 -dcdl -f /dev/dasdd and DFDSS and VM are happy. You may need to redo the CPFMTXA to use it as a volume to contain minidisk, but mount it on zOS, and use DFDSS to backup as a CPVOL. kickstart does not do the "-l" flag on dasdfmt, or I have not been able to find a way for it to do it, so volsers like 0x0200 and 0x0300 are the outcome. Thanks From: Scott Rohling To: IBMVM@LISTSERV.UARK.EDU Date: 03/24/2010 02:39 PM Subject: Re: initializing z/Linux disks Sent by: The IBM z/VM Operating System Terry -- You have to init the DASD when using minidisks- using CPFMTXA to put a label on -- and you also want to format cylinder 0 to ensure it's seen as a CP volume. When the zLinux guest does an 'init' -- it is doing a format of the whole disk - not just an 'init' and label. You can preformat minidisks in Linux format if you want to avoid the time Linux takes to do it at kickstart... if that's what you're looking for. I would not recommend using DEDICATE -- why would you do that rather than use minidisks? What you need to be aware of is that if you DEDICATE -- Linux will label the DASD -- and that's what you'll see at the z/VM level -- and are likely to see duplicate labels. (to things like 0x0200 and 0x0300, etc...).Also - if you dedicate - you can't use things like DIRMAINT do manage your dasd and keep things in pools, etc -- you have to manage it all yourself. I'm not sure how DFDSS reacts to Linux formatted volumes, offhand .. it does fine with CPVOL volumes and minidisks. Anyway - I'm not a fan of dedicate's - as you can tell ;-) Scott Rohling On Wed, Mar 24, 2010 at 11:53 AM, Martin, Terry R. (CMS/CTR) (CTR) < terry.mar...@cms.hhs.gov> 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. We back up our z/Linux guests on the z/OS side with DFDSS. My question is since when we Kick Start the new z/Linux guest and it initializes the DASD during this process is there any compelling reason for me to initialize the DASD up front before the guest is Kick Started for the first time basically doing a double INIT? 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? 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? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: initializing z/Linux disks
>>> On 3/24/2010 at 03:38 PM, Scott Rohling wrote: > I'm not sure how DFDSS reacts to Linux formatted volumes, offhand .. it > does fine with CPVOL volumes and minidisks. It looks like a regular OS volume with no free space on it. That was the whole reason the CDL was invented back in the early 2.4 kernels. Like you, however, I don't normally recommend using DEDICATEd DASD volumes. Mark Post
Re: initializing z/Linux disks
On Wednesday, 03/24/2010 at 03:22 EDT, David Boyes wrote: > On 3/24/10 2:40 PM, "Marcy Cortes" wrote: > > > You can DEDICATE by label rather than by real address. > > But I still don't like Linux having cyl 0 :) > > Nice to know. I'd missed that in the help files. Still, safer to let CP and > z/OS duke that one out, and let Linux get on with doing useful stuff. When giving guests access to real cyl 0, I suggest: 1. If using a full-pack mindisk, use the DEVNO version instead of volser. That way it doesn't matter if the guest changes the label. 2. Use the various xxx_AT_IPL options in SYSTEM CONFIG to control the RDEVs that your system will use for CP-owned and user volumes listed in SYSTEM CONFIG. Once the system is up, have AUTOLOG1 bring any remaining dasd volumes online. The purpose of these actions is to prevent CP from grabbing the wrong volume at IPL. Alan Altmark z/VM Development IBM Endicott
Re: initializing z/Linux disks
Terry -- You have to init the DASD when using minidisks- using CPFMTXA to put a label on -- and you also want to format cylinder 0 to ensure it's seen as a CP volume. When the zLinux guest does an 'init' -- it is doing a format of the whole disk - not just an 'init' and label. You can preformat minidisks in Linux format if you want to avoid the time Linux takes to do it at kickstart... if that's what you're looking for. I would not recommend using DEDICATE -- why would you do that rather than use minidisks? What you need to be aware of is that if you DEDICATE -- Linux will label the DASD -- and that's what you'll see at the z/VM level -- and are likely to see duplicate labels. (to things like 0x0200 and 0x0300, etc...).Also - if you dedicate - you can't use things like DIRMAINT do manage your dasd and keep things in pools, etc -- you have to manage it all yourself. I'm not sure how DFDSS reacts to Linux formatted volumes, offhand .. it does fine with CPVOL volumes and minidisks. Anyway - I'm not a fan of dedicate's - as you can tell ;-) Scott Rohling On Wed, Mar 24, 2010 at 11:53 AM, Martin, Terry R. (CMS/CTR) (CTR) < terry.mar...@cms.hhs.gov> 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. > > > > We back up our z/Linux guests on the z/OS side with DFDSS. > > > > My question is since when we Kick Start the new z/Linux guest and it > initializes the DASD during this process is there any compelling reason for > me to initialize the DASD up front before the guest is Kick Started for the > first time basically doing a double INIT? > > > > 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? > > > > 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? > > > > > > *Thank You,* > > * * > > *Terry Martin* > > *Lockheed Martin - Citic* > > *z/OS and z/VM Performance Tuning and Operating Systems Support* > > *Office - 443 348-2102* > > *Cell - 443 632-4191* > > * * > > *[image: cid:image001.jpg@01C97FB5.5EAFD6C0]*** > > >
Re: initializing z/Linux disks
On 3/24/10 2:40 PM, "Marcy Cortes" wrote: > You can DEDICATE by label rather than by real address. > But I still don't like Linux having cyl 0 :) Nice to know. I'd missed that in the help files. Still, safer to let CP and z/OS duke that one out, and let Linux get on with doing useful stuff.
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:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Wednesday, March 24, 2010 11:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] initializing z/Linux disks On 3/24/10 1:53 PM, "Martin, Terry R. (CMS/CTR) (CTR)" 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
Re: initializing z/Linux disks
On 3/24/10 1:53 PM, "Martin, Terry R. (CMS/CTR) (CTR)" 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
Re: initializing z/Linux disks
The disks are formatted during the Kick Start not sure if there is a choice there to init or not during the Kick Start process Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Wednesday, March 24, 2010 2:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: initializing z/Linux disks Use LXFMT from z/VM, no need to reformat the disk under Linux. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. >From an earlier post: Date: Mon, 28 Jan 2008 15:50:31 -0500 Reply-To: r...@vsoftsys.com Sender: The IBM z/VM Operating System From: Rick Bourgeois Organization: VSSI Subject: Free CMS utilities for Linux and Tape Comments: To: Linux on 390 Port Content-Type: text/plain; charset="us-ascii" Hi all, We have just made available on our website www.vsoftsys.com three free CMS utilities. LXFMT V2.1: LXFMT is a CMS utility that provides the functions of both the DASDFMT and FDASD Linux utilities. LXFMT can be used for ECKD and FBA devices. TBROWSE: TBROWSE is a CMS utility that allows you scan a real or virtual tape in a full screen browse like format. TAPSENSE: TAPSENSE displays sense information for an attached real or defined virtual tape drive. Using the current CSL-WAVV comments on the Linux-390 list of give to get I have included the following as general information. Please feel free to ignore it as we had planned to make these utilities available anyway. An earlier version of our LXFMT utility was made available on the Sinenomine.net website last year. While at our website feel free to browse information on our VM virtualization products VTAPE (Virtual TAPE) and VPARS (Virtual Private Active Record Shadowing for TPF and Linux). I will be presenting technical information on both VPARS and VTAPE at SHARE in Orlando, Session 9155 Tuesday 2/26 at 8am and a Vendor Session Wednesday 2/27 at 4:30pm in Laredo 1. We will also be available at booth 322 at the SHARE Technology Expo with demos, I hope (if all the internet stuff works to get to our mainframe ;-). Our FLEX-ES laptop expired 2/2007 making us dependant on the internet for demos ;-(. We will also be at WAVV in Chattanooga in April. Having been a member of SHARE since the early 1970's but not attending in several years I look forward to renewing many old friendships, making new ones and thanking the VM Group members for my Knighthood at the last SHARE. Thanks and best regards, Sir Rick of PARS Rick Bourgeois r...@vsoftsys.com Virtual Software Systems, Inc. www.vsoftsys.com 770-781-3200 "Martin, Terry R. (CMS/CTR) (CTR)" Sent by: "The IBM z/VM Operating System" 03/24/2010 12:53 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject initializing z/Linux disks 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. We back up our z/Linux guests on the z/OS side with DFDSS. My question is since when we Kick Start the new z/Linux guest and it initializes the DASD during this process is there any compelling reason for me to initialize the DASD up front before the guest is Kick Started for the first time basically doing a double INIT? 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? 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? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone oth
Re: initializing z/Linux disks
Use LXFMT from z/VM, no need to reformat the disk under Linux. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. >From an earlier post: Date: Mon, 28 Jan 2008 15:50:31 -0500 Reply-To: r...@vsoftsys.com Sender: The IBM z/VM Operating System From: Rick Bourgeois Organization: VSSI Subject: Free CMS utilities for Linux and Tape Comments: To: Linux on 390 Port Content-Type: text/plain; charset="us-ascii" Hi all, We have just made available on our website www.vsoftsys.com three free CMS utilities. LXFMT V2.1: LXFMT is a CMS utility that provides the functions of both the DASDFMT and FDASD Linux utilities. LXFMT can be used for ECKD and FBA devices. TBROWSE: TBROWSE is a CMS utility that allows you scan a real or virtual tape in a full screen browse like format. TAPSENSE: TAPSENSE displays sense information for an attached real or defined virtual tape drive. Using the current CSL-WAVV comments on the Linux-390 list of give to get I have included the following as general information. Please feel free to ignore it as we had planned to make these utilities available anyway. An earlier version of our LXFMT utility was made available on the Sinenomine.net website last year. While at our website feel free to browse information on our VM virtualization products VTAPE (Virtual TAPE) and VPARS (Virtual Private Active Record Shadowing for TPF and Linux). I will be presenting technical information on both VPARS and VTAPE at SHARE in Orlando, Session 9155 Tuesday 2/26 at 8am and a Vendor Session Wednesday 2/27 at 4:30pm in Laredo 1. We will also be available at booth 322 at the SHARE Technology Expo with demos, I hope (if all the internet stuff works to get to our mainframe ;-). Our FLEX-ES laptop expired 2/2007 making us dependant on the internet for demos ;-(. We will also be at WAVV in Chattanooga in April. Having been a member of SHARE since the early 1970's but not attending in several years I look forward to renewing many old friendships, making new ones and thanking the VM Group members for my Knighthood at the last SHARE. Thanks and best regards, Sir Rick of PARS Rick Bourgeois r...@vsoftsys.com Virtual Software Systems, Inc. www.vsoftsys.com 770-781-3200 "Martin, Terry R. (CMS/CTR) (CTR)" Sent by: "The IBM z/VM Operating System" 03/24/2010 12:53 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject initializing z/Linux disks 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. We back up our z/Linux guests on the z/OS side with DFDSS. My question is since when we Kick Start the new z/Linux guest and it initializes the DASD during this process is there any compelling reason for me to initialize the DASD up front before the guest is Kick Started for the first time basically doing a double INIT? 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? 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? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: initializing z/Linux disks
I have meant to bring this up to the list before now, but since you mention it... I use the "clone a golden image" methodology. I've used DDR, which always works, and I've used dasdfmt and dd, which sometimes results in an unstable system. I can't pin it down exactly, but I think it happens when I repurpose minidisks that have had Linux filesystems on them previously. The first symptom I see is segmentation faults in YaST. When I CPFMTXA the minidisk before using the dasdfmt and dd cloning method, I don't have the problem. Therefore, I always CPFMTXA the dasd first. Terry, I would not use DEDICATE. I like to preserve cyl 0 because I know z/VM and z/OS understand it. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Wednesday, March 24, 2010 1:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: initializing z/Linux disks 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. We back up our z/Linux guests on the z/OS side with DFDSS. My question is since when we Kick Start the new z/Linux guest and it initializes the DASD during this process is there any compelling reason for me to initialize the DASD up front before the guest is Kick Started for the first time basically doing a double INIT? 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? 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? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 cid:image001.jpg@01C97FB5.5EAFD6C0
