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: [email protected] 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: [email protected] >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: [email protected] >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. >========================= ========================== =======================
