Marty,

Thanks for the sympathy.  I'm beginning to feel "caught in the middle".  My
network folks think the VM TCPIP stack is ancient because of how it handles
EqualCostMultiPath (and OSPF authentication, although that's now available
in v5.2) and the VM development folks think our network design is lousy
because hosts have to do routing.  Sigh!  As if I have any influence in the
network design ...

You can still run VSWITCH in this environment.  You just have to build
automation (or manually handle it) to detect the CP messages issued when
the OSA quits/resumes talking (and I'm sure there's some I haven't found in
my testing) and then configure VM and/or Linux IP stacks to IFCONFIG the
appropriate interface down/up.  And, for a lot of zLinux instances, it
almost has to be automagic.

Sometimes, I wonder, considering how reliable the entire network
infrastructure seems to be, if its worth all this trouble for redundancy.
Our last network outage in the last five years was planned.  Our
distributed systems have just started to utilize multiple adapters the last
two years, mainly in anticipation of that planned outage.  But, just as
soon as I succumb to the temptation, it'll happen and I'll be standing
their with my so-called pants down.

I agree with your comments about routing flexibility.  I haven't attempted
to move the entire guest LAN subnet but I do commonly move second-level
guests back-and-forth between either of my physical VM processors; and, the
guest LAN should work the same way as long as I move them all together.

Thanks,
Dennis

Marty Cortes wrote on 08/02/2006 06:54:15 PM:

>
> Dennis's network people must hang out with mine or read the same doc or
> something.  They too want OSAs on their very own little subnets.
>
> I finally managed to get them to take 1 port off each card on the test
> box so that I could at least test VSWITCH.   Still haven't approached
> the subject about production.  The cool thing about the VM routing thing
> though is that I can float that guest LAN subnet anywhere I want it to
> be :) - really good for disaster tests and those who move their
> datacenters all over the place.

Reply via email to