Re: OSA rdev and vdev requirements for Linux guests.
>>> On Fri, Apr 25, 2008 at 7:58 AM, in message <[EMAIL PROTECTED]>, "Gentry, Stephen" <[EMAIL PROTECTED]> wrote: -snip- > In a previous IFL/Linux/POC, we set up a Linux running UDB. We wanted to > allow access to that Linux from two sources: existing mainframe apps. > and apps. running on WAS (IBM web app. server). I set up a virtual lan > (hiper-sockets and such) for the apps on the mainframe to get to UDB. > For the WAS part, I used 3 addresses from an OSA card, DEDICATED those > to the Linux/UDB guest. This allowed WAS to avoid going through the VM > TCPIP stack and through the virtual lan to get to UDB, in essence > reducing the length of the path taken to get to UDB. Network traffic on a VSWITCH doesn't go through z/VM's TCP/IP stack, just CP. (Unless you deliberately configure your virtual network to do so.) The main reason you have a TCP/IP "controller" is to handle the actual OSA hardware. TCP/IP already had all that code built in, so there wasn't a good reason to duplicate it or rewrite it just to manage the hardware the VSWITCH needs to get "outside." Mark Post
Re: OSA rdev and vdev requirements for Linux guests.
"the mind is the 2nd thing to go and I don't remember the first". Is the quote of a previous quote a 2nd level quote? Anyway, I remember what I was trying to do with the OSA. I didn't really attach the OSA card to Linux. However, my original question did bring out a good discussion. In a previous IFL/Linux/POC, we set up a Linux running UDB. We wanted to allow access to that Linux from two sources: existing mainframe apps. and apps. running on WAS (IBM web app. server). I set up a virtual lan (hiper-sockets and such) for the apps on the mainframe to get to UDB. For the WAS part, I used 3 addresses from an OSA card, DEDICATED those to the Linux/UDB guest. This allowed WAS to avoid going through the VM TCPIP stack and through the virtual lan to get to UDB, in essence reducing the length of the path taken to get to UDB. It all worked. Good idea? Not so good an idea? Steve G. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, April 24, 2008 11:24 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: OSA rdev and vdev requirements for Linux guests. On Thursday, 04/24/2008 at 10:27 EDT, "Gentry, Stephen" <[EMAIL PROTECTED]> wrote: > Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux > guest? > Seriously, why shouldn't this be done? Off the top of my head: (a) Security. You now limit what can be done with the OSA since you give it to a guest to use. You wouldn't want to share it with other guests (IMO). Do you know what low-level functions are available in the OSA? Me neither, but a virtual NIC is designed to prevent a guest from doing things you don't want it to do or limiting the scope of what it does. And I certainly wouldn't even THINK about letting a guest have arbitrary access to all your VLANs unless it is supposed to have that access. (b) High availability. If a guest is handling the OSA, then the guest must handle any OSA, cable, or switch errors or device outages. The VSWITCH handles that transparently for all guests using the VSWITCH. What if you have 5 guests that need OSAs? Each would need a backup as well. (c) Utilization. Who is using the OSA when this guest isn't? Does it sit idle? A VSWITCH operates an OSA on behalf of multiple guests. Alan Altmark z/VM Development IBM Endicott
Re: OSA rdev and vdev requirements for Linux guests.
Alan Altmark wrote:
> Amen to that. VM TCP/IP doesn't get any more of a free pass than any
> other guest and gets all the benefits VSWITCH can provide.
>
> The only question you need to be able to answer is: What is your
alternate
> logon path if VM TCP/IP OR the VSWITCH is down? You need to have
> emergency automation, OSA-ICC or HMC 3270.
> WARNING: THE OSAs ARE NOW IN THE POSESSION OF VM TCP/IP
>ONLY TELNET IS AVAILABLE. ACCESS IS RESTRICTED TO
>MAINT, OPERATOR, AND SUPER-SECRET USERID CHUCKIE.
>YOU HAVE -- 15 -- MINUTES UNTIL SYSTEM SHUTDOWN.
>STOP SHUTDOWN MY SUCCESSFULLY LOGGING ON AND
>ISSUING "SMSG MOTHER CANCEL".
>
Well, my legacy systems still run VTAM (with redundant OSAs and FICON CTC
paths to the z/OS CMC's), and I also interconnect them all with PVM. If
either VTAM or TCPIP is alive on any system, I can probably get to any
other.
On my Linux-hosting systems, I have both a TCPIP and a TCPIP2 stack. TCPIP
has a VSWITCH connection, and redundant FICON CTCs (through different
directors) connected to the IFL and z/OS LPARs on a CEC in our other
datacenter, as well as hipersocket connections to z/OS systems on the same
CEC (BTW, the OSAs on the z/OS systems need to be defined as PRIROUTERs if
they're going to provide a path to your IFLs if everything else is down).
Need to run MPROUTE here, of course, and setting appropriate COST0 factors
can get tricky.
TCPIP2 is my trusty "back door", and can be set up with a hipersocket, CTC,
VSWITCH, or OSA connection (whichever suits your configuration the best).
Nothing fancy. You just want it to work WHEN YOU REALLY NEED IT, like when
you need to work on the primary stack machine, or in spite of all your
fancy configuration efforts the darn thing goes down anyway. :-( I run
limitted services on it - just telnet and FTP. And OSASF, again just in
case.
True story: Our z/OS systems TCPIP's are configured with two OSAs
(different than the OSAs used by the IFL's) and use VIPA for high
availability. They were upgraded to z/OS 1.7 a while back and there was a
bug (a combination of software and microcode problems, IIRC) that caused
BOTH OSA connections to drop (and could not be restarted). For two days no
one noticed! Why? Because OSPF had dutifully rerouted traffic to the z/OS
system through the IFL's VSWITCH and across the hipersocket link. And if
that VM system had been down, the z/OS traffic would have been routed to
the VSWITCH of the IFL in the other datacenter and across the FICON CTC
link. Cool, no? We continued to run that way until the following weekend,
when the z/OS folks could schedule a planned outage to fix their problem.
And that's another reason why we're killing our IFLs. (:{
Mark Wheeler, 3M Company
Re: OSA rdev and vdev requirements for Linux guests.
My friend Mark worte: >Even on my legacy VM systems (no Linux guests at all) I define a VSWITCH with two OSAs (connected to different real switches), and the only thing attached to the VSWITCH is the TCPIP virtual machine. Prior to VSWITCH the TCPIP machine attached to both OSAs and VIPA provided for high availability. I don't need MPROUTE any more, just simple static routing. Much easier to support. And someday we'll have layer 2 VM stack and all the OSA's in LACP mode happily sharing the workload over that whole farm of OSAs we have laying around. Then we can say we're done and Chuckie can retire. Wait, he's way too young. We'll find something else interesting for him to do. 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."
Re: OSA rdev and vdev requirements for Linux guests.
On Thursday, 04/24/2008 at 11:44 EDT, Mark Wheeler <[EMAIL PROTECTED]> wrote: > Even on my legacy VM systems (no Linux guests at all) I define a VSWITCH > with two OSAs (connected to different real switches), and the only thing > attached to the VSWITCH is the TCPIP virtual machine. Prior to VSWITCH the > TCPIP machine attached to both OSAs and VIPA provided for high > availability. I don't need MPROUTE any more, just simple static routing. > Much easier to support. Amen to that. VM TCP/IP doesn't get any more of a free pass than any other guest and gets all the benefits VSWITCH can provide. The only question you need to be able to answer is: What is your alternate logon path if VM TCP/IP OR the VSWITCH is down? You need to have emergency automation, OSA-ICC or HMC 3270. WARNING: THE OSAs ARE NOW IN THE POSESSION OF VM TCP/IP ONLY TELNET IS AVAILABLE. ACCESS IS RESTRICTED TO MAINT, OPERATOR, AND SUPER-SECRET USERID CHUCKIE. YOU HAVE -- 15 -- MINUTES UNTIL SYSTEM SHUTDOWN. STOP SHUTDOWN MY SUCCESSFULLY LOGGING ON AND ISSUING "SMSG MOTHER CANCEL". Alan Altmark z/VM Development IBM Endicott
Re: OSA rdev and vdev requirements for Linux guests.
The IBM z/VM Operating System wrote on 04/24/2008 10:23:39 PM: > On Thursday, 04/24/2008 at 10:27 EDT, "Gentry, Stephen" > <[EMAIL PROTECTED]> wrote: > > Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux > > guest? > > Seriously, why shouldn't this be done? > Alan Altmark wrote: > Off the top of my head: > > (b) High availability. If a guest is handling the OSA, then the guest > must handle any OSA, cable, or switch errors or device outages. The > VSWITCH handles that transparently for all guests using the VSWITCH. What > if you have 5 guests that need OSAs? Each would need a backup as well. Even on my legacy VM systems (no Linux guests at all) I define a VSWITCH with two OSAs (connected to different real switches), and the only thing attached to the VSWITCH is the TCPIP virtual machine. Prior to VSWITCH the TCPIP machine attached to both OSAs and VIPA provided for high availability. I don't need MPROUTE any more, just simple static routing. Much easier to support. Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- "I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go." Rachel Joy Scott
Re: OSA rdev and vdev requirements for Linux guests.
On Thursday, 04/24/2008 at 10:27 EDT, "Gentry, Stephen" <[EMAIL PROTECTED]> wrote: > Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux > guest? > Seriously, why shouldn't this be done? Off the top of my head: (a) Security. You now limit what can be done with the OSA since you give it to a guest to use. You wouldn't want to share it with other guests (IMO). Do you know what low-level functions are available in the OSA? Me neither, but a virtual NIC is designed to prevent a guest from doing things you don't want it to do or limiting the scope of what it does. And I certainly wouldn't even THINK about letting a guest have arbitrary access to all your VLANs unless it is supposed to have that access. (b) High availability. If a guest is handling the OSA, then the guest must handle any OSA, cable, or switch errors or device outages. The VSWITCH handles that transparently for all guests using the VSWITCH. What if you have 5 guests that need OSAs? Each would need a backup as well. (c) Utilization. Who is using the OSA when this guest isn't? Does it sit idle? A VSWITCH operates an OSA on behalf of multiple guests. Alan Altmark z/VM Development IBM Endicott
Re: OSA rdev and vdev requirements for Linux guests.
> Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux > guest? Ties a guest to a particular piece of hardware (failure point), and forces the guest to handle all the recovery, ARP management, etc. Having CP do it for multiple guests is a much more resource efficient approach. It also ultimately uses up a lot more OSA port triplets, which aren't free. A couple 10G cards aren't cheap, but they're cheaper than multiple 1G cards, and you'll get better utilization out of the 10G cards. You also get a better chance to move any network processing outside the Z box -- 10G cards in switches tend to have LOTS of horsepower, and they're way, WAY cheaper than an IFL. > Seriously, why shouldn't this be done? Consumes lots of memory in each guest (16M per OSA is the default, I think). Also forces the guest to be dispatched more often to handle all the I/O (particularly noticeable when using layer 2 where the guest has to handle ARP and other stuff). It's also a lot more management-intensive to have to figure out all that port mapping in the first place, and then figure it out again in a DR situation where the hardware is different. With VSWITCH, you change it in one place and it's done for all the guests on that VSWITCH whether you have 1 or 100.
Re: OSA rdev and vdev requirements for Linux guests.
Right, for redundancy, you'd want to have 2 different OSAs cards - each on a different physical switch. We have lost OSA cards here & physical switches go down too (planned and unplanned). The vswitch will provide failover for all of the Linux servers. Dedicating OSA addresses and having failover would require 6 addresses per guest and some sort of dynamic routing protocol on them to redirect traffic should an interface be down. There is overhead in that too. Attaching real addresses also makes provisioning new guests a bigger challenge. And there is the UCB shortage issue here... So yeah, IMHO, if you have more the one Linux guest, vswitch is the way to go. Marcy Cortes "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 Brian Nielsen Sent: Thursday, April 24, 2008 9:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] OSA rdev and vdev requirements for Linux guests. VSWITCHes are very nice for isolating the Linux guests from external VLAN= requirements. The Linux guests can be VLAN unaware and the VSWITCH handles tagging and untagging all the frames. They are also very nice for failover to an alternate OSA. No need to burden the Linux guests with that. Additionally, using VSWITCHes removes the need to hunt through the directory (or other documentation) for an unused real address. Can it be done with real OSA's, yeah, but VSWITCHes make life much, much = easier. I wish a VSWITCH could connect to a Hypersocket as it's RDEV. = *THAT* would make life really good. Brian Nielsen On Thu, 24 Apr 2008 07:51:34 -0400, Gentry, Stephen <[EMAIL PROTECTED]> wrote: >Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux >guest? >Seriously, why shouldn't this be done? >Steve G. > >-Original Message- >From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On >Behalf Of Marcy Cortes >Sent: Thursday, April 24, 2008 12:30 AM >To: IBMVM@LISTSERV.UARK.EDU >Subject: Re: OSA rdev and vdev requirements for Linux guests. > >Wait, what are you doing attaching osa's to Linux? >VSWITCH! > >Seriously, I think you use a lot more storage on the Linux guest and >make him less likely to be idle. > >Marcy Cortes > >"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 Mike Walter >Sent: Wednesday, April 23, 2008 9:25 PM >To: IBMVM@LISTSERV.UARK.EDU >Subject: [IBMVM] OSA rdev and vdev requirements for Linux guests. > >Way back when, in the olden days, I seem to remember that the first OSA >address of a triplet used by Linux guests had to be an even address. > >But then there are also vague memories of more recent information that >as long as the first OSA vdev of a triplet seen by a guest is even, it >does not matter if its rdev is odd. Is that true, or have I been >sneaking sips of Adam's cough medicine? > >If the first vdev of the triplet being even is all that matters, do all >the rdevs have to be in ascending sequential order? > >Or could we harvest all those lone, odd-numbered OSA rdevs? E.g. >"7000,= >7001, 7002" used, reclaim the abandoned 7003 rdev to be assigned as an >even-numbered vdev, "7004, 7005, 7006" used, reclaim the abandoned 7007 >rdev to be assigned as an even-numbered vdev, etc.)? > >And... where is this documented that I obviously overlooked? Of course >if a restriction were removed, where would one find it documented >except= >in old manuals and folklore? :-) > >Mike Walter >Hewitt Associates >Any opinions expressed herein are mine alone and do not necessarily >represent the opinions or policies of Hewitt Associates. > > > > > > > > >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
Re: OSA rdev and vdev requirements for Linux guests.
VSWITCHes are very nice for isolating the Linux guests from external VLAN requirements. The Linux guests can be VLAN unaware and the VSWITCH handles tagging and untagging all the frames. They are also very nice for failover to an alternate OSA. No need to burden the Linux guests with that. Additionally, using VSWITCHes removes the need to hunt through the directory (or other documentation) for an unused real address. Can it be done with real OSA's, yeah, but VSWITCHes make life much, much easier. I wish a VSWITCH could connect to a Hypersocket as it's RDEV. *THAT* would make life really good. Brian Nielsen On Thu, 24 Apr 2008 07:51:34 -0400, Gentry, Stephen <[EMAIL PROTECTED]> wrote: >Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux >guest? >Seriously, why shouldn't this be done? >Steve G. > >-Original Message- >From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On >Behalf Of Marcy Cortes >Sent: Thursday, April 24, 2008 12:30 AM >To: IBMVM@LISTSERV.UARK.EDU >Subject: Re: OSA rdev and vdev requirements for Linux guests. > >Wait, what are you doing attaching osa's to Linux? >VSWITCH! > >Seriously, I think you use a lot more storage on the Linux guest and >make him less likely to be idle. > >Marcy Cortes > >"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 Mike Walter >Sent: Wednesday, April 23, 2008 9:25 PM >To: IBMVM@LISTSERV.UARK.EDU >Subject: [IBMVM] OSA rdev and vdev requirements for Linux guests. > >Way back when, in the olden days, I seem to remember that the first OSA >address of a triplet used by Linux guests had to be an even address. > >But then there are also vague memories of more recent information that >as long as the first OSA vdev of a triplet seen by a guest is even, it >does not matter if its rdev is odd. Is that true, or have I been >sneaking sips of Adam's cough medicine? > >If the first vdev of the triplet being even is all that matters, do all >the rdevs have to be in ascending sequential order? > >Or could we harvest all those lone, odd-numbered OSA rdevs? E.g. "7000, >7001, 7002" used, reclaim the abandoned 7003 rdev to be assigned as an >even-numbered vdev, "7004, 7005, 7006" used, reclaim the abandoned 7007 >rdev to be assigned as an even-numbered vdev, etc.)? > >And... where is this documented that I obviously overlooked? Of course >if a restriction were removed, where would one find it documented except >in old manuals and folklore? :-) > >Mike Walter >Hewitt Associates >Any opinions expressed herein are mine alone and do not necessarily >represent the opinions or policies of Hewitt Associates. > > > > > > > > >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: OSA rdev and vdev requirements for Linux guests.
Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux guest? Seriously, why shouldn't this be done? Steve G. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, April 24, 2008 12:30 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: OSA rdev and vdev requirements for Linux guests. Wait, what are you doing attaching osa's to Linux? VSWITCH! Seriously, I think you use a lot more storage on the Linux guest and make him less likely to be idle. Marcy Cortes "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 Mike Walter Sent: Wednesday, April 23, 2008 9:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] OSA rdev and vdev requirements for Linux guests. Way back when, in the olden days, I seem to remember that the first OSA address of a triplet used by Linux guests had to be an even address. But then there are also vague memories of more recent information that as long as the first OSA vdev of a triplet seen by a guest is even, it does not matter if its rdev is odd. Is that true, or have I been sneaking sips of Adam's cough medicine? If the first vdev of the triplet being even is all that matters, do all the rdevs have to be in ascending sequential order? Or could we harvest all those lone, odd-numbered OSA rdevs? E.g. "7000, 7001, 7002" used, reclaim the abandoned 7003 rdev to be assigned as an even-numbered vdev, "7004, 7005, 7006" used, reclaim the abandoned 7007 rdev to be assigned as an even-numbered vdev, etc.)? And... where is this documented that I obviously overlooked? Of course if a restriction were removed, where would one find it documented except in old manuals and folklore? :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. 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: OSA rdev and vdev requirements for Linux guests.
Yes, the "other bank formerly based in SF" posted this before. Here it
is again:
Guest RDev VDev
GUEST1DC00 DC00
GUEST1DC01 DC01
GUEST1DC0A DC02
GUEST2DC02 DC00
GUEST2DC03 DC01
GUEST2DC0B DC02
GUEST3DC04 DC00
GUEST3DC05 DC01
GUEST3DC0C DC02
GUEST4DC06 DC00
GUEST4DC07 DC01
GUEST4DC0D DC02
GUEST5DC08 DC00
GUEST5DC09 DC01
GUEST5DC0E DC02
Dennis O'Brien
"A society that gets rid of all its troublemakers goes downhill." --
Robert A. Heinlein
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Marcy Cortes
Sent: Wednesday, April 23, 2008 21:43
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] OSA rdev and vdev requirements for Linux guests.
Well, I know all about moving cheeses here :)
But how would those Internet security people know? :) I dare them to
find that vswitch!
Some one here long ago and far away (I'm pretty sure it was the other
bank formerly based in SF), posted his scheme of reclaiming. Yes, you
can use non-sequentials.
No doubt Alan will respond before too long with the real location of the
doc. I don't think he ever sleeps.
Marcy Cortes
"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 Mike Walter
Sent: Wednesday, April 23, 2008 9:36 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] OSA rdev and vdev requirements for Linux guests.
VSWITCH is the answer, of course.
But that's the next great leap through our company Internet Security
group. Baby steps first. We have OSA rdevs available, and the need for
three new zLinux guests in a hurry, of course.
VSWITCH is already being planned, but it has a longer timeline since it
involves moving the cheese a great many more recalcitrant people.
So... the question remains (if a reply from Alan is not already winding
its way through the net at this late hour on the east coast)
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
"Marcy Cortes" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System"
04/23/2008 11:29 PM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: OSA rdev and vdev requirements for Linux guests.
Wait, what are you doing attaching osa's to Linux?
VSWITCH!
Seriously, I think you use a lot more storage on the Linux guest and
make him less likely to be idle.
Marcy Cortes
"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 Mike Walter
Sent: Wednesday, April 23, 2008 9:25 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] OSA rdev and vdev requirements for Linux guests.
Way back when, in the olden days, I seem to remember that the first OSA
address of a triplet used by Linux guests had to be an even address.
But then there are also vague memories of more recent information that
as long as the first OSA vdev of a triplet seen by a guest is even, it
does not matter if its rdev is odd. Is that true, or have I been
sneaking sips of Adam's cough medicine?
If the first vdev of the triplet being even is all that matters, do all
the rdevs have to be in ascending sequential order?
Or could we harvest all those lone, odd-numbered OSA rdevs? E.g. "7000,
7001, 7002" used, reclaim the abandoned 7003 rdev to be assigned as an
even-numbered vdev, "7004, 7005, 7006" used, reclaim the abandoned 7007
rdev to be assigned as an even-numbered vdev, etc.)?
And... where is this documented that I obviously overlooked? Of course
if a restriction were removed, where would one find it documented except
in old manuals and folklore? :-)
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
The information contained in this e-mail and
Re: OSA rdev and vdev requirements for Linux guests.
Well, I know all about moving cheeses here :) But how would those Internet security people know? :) I dare them to find that vswitch! Some one here long ago and far away (I'm pretty sure it was the other bank formerly based in SF), posted his scheme of reclaiming. Yes, you can use non-sequentials. No doubt Alan will respond before too long with the real location of the doc. I don't think he ever sleeps. Marcy Cortes "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 Mike Walter Sent: Wednesday, April 23, 2008 9:36 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] OSA rdev and vdev requirements for Linux guests. VSWITCH is the answer, of course. But that's the next great leap through our company Internet Security group. Baby steps first. We have OSA rdevs available, and the need for three new zLinux guests in a hurry, of course. VSWITCH is already being planned, but it has a longer timeline since it involves moving the cheese a great many more recalcitrant people. So... the question remains (if a reply from Alan is not already winding its way through the net at this late hour on the east coast) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Marcy Cortes" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 04/23/2008 11:29 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: OSA rdev and vdev requirements for Linux guests. Wait, what are you doing attaching osa's to Linux? VSWITCH! Seriously, I think you use a lot more storage on the Linux guest and make him less likely to be idle. Marcy Cortes "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 Mike Walter Sent: Wednesday, April 23, 2008 9:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] OSA rdev and vdev requirements for Linux guests. Way back when, in the olden days, I seem to remember that the first OSA address of a triplet used by Linux guests had to be an even address. But then there are also vague memories of more recent information that as long as the first OSA vdev of a triplet seen by a guest is even, it does not matter if its rdev is odd. Is that true, or have I been sneaking sips of Adam's cough medicine? If the first vdev of the triplet being even is all that matters, do all the rdevs have to be in ascending sequential order? Or could we harvest all those lone, odd-numbered OSA rdevs? E.g. "7000, 7001, 7002" used, reclaim the abandoned 7003 rdev to be assigned as an even-numbered vdev, "7004, 7005, 7006" used, reclaim the abandoned 7007 rdev to be assigned as an even-numbered vdev, etc.)? And... where is this documented that I obviously overlooked? Of course if a restriction were removed, where would one find it documented except in old manuals and folklore? :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. 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
Re: OSA rdev and vdev requirements for Linux guests.
VSWITCH is the answer, of course. But that's the next great leap through our company Internet Security group. Baby steps first. We have OSA rdevs available, and the need for three new zLinux guests in a hurry, of course. VSWITCH is already being planned, but it has a longer timeline since it involves moving the cheese a great many more recalcitrant people. So... the question remains (if a reply from Alan is not already winding its way through the net at this late hour on the east coast) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Marcy Cortes" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 04/23/2008 11:29 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: OSA rdev and vdev requirements for Linux guests. Wait, what are you doing attaching osa's to Linux? VSWITCH! Seriously, I think you use a lot more storage on the Linux guest and make him less likely to be idle. Marcy Cortes "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 Mike Walter Sent: Wednesday, April 23, 2008 9:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] OSA rdev and vdev requirements for Linux guests. Way back when, in the olden days, I seem to remember that the first OSA address of a triplet used by Linux guests had to be an even address. But then there are also vague memories of more recent information that as long as the first OSA vdev of a triplet seen by a guest is even, it does not matter if its rdev is odd. Is that true, or have I been sneaking sips of Adam's cough medicine? If the first vdev of the triplet being even is all that matters, do all the rdevs have to be in ascending sequential order? Or could we harvest all those lone, odd-numbered OSA rdevs? E.g. "7000, 7001, 7002" used, reclaim the abandoned 7003 rdev to be assigned as an even-numbered vdev, "7004, 7005, 7006" used, reclaim the abandoned 7007 rdev to be assigned as an even-numbered vdev, etc.)? And... where is this documented that I obviously overlooked? Of course if a restriction were removed, where would one find it documented except in old manuals and folklore? :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. 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. 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: OSA rdev and vdev requirements for Linux guests.
Wait, what are you doing attaching osa's to Linux? VSWITCH! Seriously, I think you use a lot more storage on the Linux guest and make him less likely to be idle. Marcy Cortes "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 Mike Walter Sent: Wednesday, April 23, 2008 9:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] OSA rdev and vdev requirements for Linux guests. Way back when, in the olden days, I seem to remember that the first OSA address of a triplet used by Linux guests had to be an even address. But then there are also vague memories of more recent information that as long as the first OSA vdev of a triplet seen by a guest is even, it does not matter if its rdev is odd. Is that true, or have I been sneaking sips of Adam's cough medicine? If the first vdev of the triplet being even is all that matters, do all the rdevs have to be in ascending sequential order? Or could we harvest all those lone, odd-numbered OSA rdevs? E.g. "7000, 7001, 7002" used, reclaim the abandoned 7003 rdev to be assigned as an even-numbered vdev, "7004, 7005, 7006" used, reclaim the abandoned 7007 rdev to be assigned as an even-numbered vdev, etc.)? And... where is this documented that I obviously overlooked? Of course if a restriction were removed, where would one find it documented except in old manuals and folklore? :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. 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.
