I appreciate the elaboration and its relevance to link aggregation. My
next question would be how to move toward non-shared OSAs and maintain no
n-
VLAN-aware guests connected to multiple VLANs through the OSA. The two
seem to be incompatible. Either the guests need to become VLAN-aware to
have multiple NICs to the same VSWITCH, or NICDEF needs a new parameter t
o
define its' default VLAN (to supercede the VSWITCH GRANT default VLAN for
*every* NIC from a guest).
Is there another way?
Brian Nielsen
On Mon, 26 Mar 2007 12:16:00 -0400, Alan Altmark <[EMAIL PROTECTED]
>
wrote:
>On Monday, 03/26/2007 at 09:53 EST, Brian Nielsen <[EMAIL PROTECTED]
V>
>wrote:
>> On Fri, 23 Mar 2007 09:55:05 -0400, Alan Altmark
><[EMAIL PROTECTED]>
>> wrote:
>>
>> >It is also my
>> >recommendation that you do not share an OSA in use by a VSWITCH,
>> >*especially* if it is VLAN-aware. The last thing you want is a fight
>> >between two VSWITCHes about whether a VLAN is in use. Yes it is, no
it
>> >isn't, yes it is, no it isn't.... If you choose to go down this path
,
>> >define the VSWITCH with NOGVRP.
>>
>> Would you please eloborate on this? I have multiple VLAN-aware
>VSWITCHes
>> sharing the same OSA with no problems. Each VSWITCH has a distinct an
d
>> separate set of VLANs, if that makes any difference. This setup is
>> required to connect non-VLAN-aware guests to multiple VLANs via VSWITC
H
>> GRANTs.
>>
>> If there is a pitfall in there somewhere I'd like to know more about i
t.
>
>As long as you do not try to span VLANs across different VSWITCHes shari
ng
>an OSA, it will work. The problem I run into is that someone changes th
e
>switch (virtual or real) or VLAN configuration without thinking about th
e
>affect on a shared port. Things start to fail. But it's just a
>recommendation, not a requirement. Our gun. Your foot.
>
>In z/VM 5.3 we announced support for IBM System z9 IEEE 802.1ad Link
>Aggregation ("channel bonding", "etherchannel"), providing additional
>bandwidth with each OSA you add to the "aggregation group". In this
>configuration, the OSAs are usable by only a single VSWITCH at a time, a
nd
>will use additional hardware support to enforce this. (There is a
>switch-to-switch protocol flowing over the links along with user data an
d
>more than one cook in the kitchen will spoil the broth...) Imagine up
to
>80 Gb of data per second moving in/out of the box (up to eight 10 Gb
>ports).
>
>This support also provides for the smooth addition or removal of OSAs fr
om
>the aggregation group, whether because you want to add/take an OSA, or
>because one fails. No data is lost, with retransmission handled at a
>packet level rather than at the TCP segment level.
>
>If you ever think you will want to take advantage of this support, you
>need to be planning for dedicated OSAs, even if you need to share right
>now.
>
>And, of course, mixing VLAN-aware and non-VLAN-aware is a no-no, though
>nothing will enforce it.
>
>So, none of this is really about what *can* be done. You can share all
>you want. But the risk to your virtual data center is lowest if you don
't
>share, and that remains my recommendation.
>
>Admittedly, "because Alan says so" only goes so far (the "Wesayso
>Corporation", anyone?). I have the same problem at home. Go figure. :
-)
>
>Alan Altmark
>z/VM Development
>IBM Endicott
>========================
=========================
========================
