SEO

Can someone doing SEA failover verify the following behaviour for me?
I've done a setup following section 5.3 in the "Advaced POWER Virtualization"
redbook (or attempting to; the docs are inconsistent at times). In
short, two VIO servers (1.2), heartbeat on PVID 99 (virt ent3), etc.

What I'm seeing that I suspect is incorrect is that the configured SEA,
ent4, has the configured IP address (en4, actually), shows up in ifconfig,
is unreachable on the 2nd/standby VIO server, until I manually cause the
1st/primary to fail-over.

It seems odd because it breaks communication with the HMC, makes shell access
impossible by anything other than the vterm console and in fact, hangs at
boot due to some NFS stuff it tries to do (which I haven't configured).

Has anyone followed this setup by the Redbook and is it the expected
configuration that the 2nd VIO server be unreachable when in stand-by
mode?

Wil
--
Wil Cooley wcooley@nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *

Wil,

I discovered the same issue with SEA failover. It looks very easy to
set up in the redbook. The VIO 2 was not reachable via network, even
if I pulled the network cables from VIO 1. I had to shutdown VIO 1 for
the failover to occur, and then both the VIO 2 and clients had network
connectivity. Then network would not fail back to VIO 1 even if I
shutdown VIO 2. A call to IBM support did not bring any real
enlightenment to why. I got the same dull response as for a call a
year earlier about general virtual networking. Could this be a 'not
ready for prime-time' feature?

I've used the previous method of net_if backup etherchannel using both
VIOS on separate VLANS trouble free for now until some new patches for
VIO come out that might address it.

One thing good about VIO 1.2 is the ease of creating the vscsi
server/client pairs. Much better than previous.

- Jon

Wil Cooley wrote:
> Can someone doing SEA failover verify the following behaviour for me?
> I've done a setup following section 5.3 in the "Advaced POWER Virtualization"
> redbook (or attempting to; the docs are inconsistent at times). In
> short, two VIO servers (1.2), heartbeat on PVID 99 (virt ent3), etc.
>
> What I'm seeing that I suspect is incorrect is that the configured SEA,
> ent4, has the configured IP address (en4, actually), shows up in ifconfig,
> is unreachable on the 2nd/standby VIO server, until I manually cause the
> 1st/primary to fail-over.
>
> It seems odd because it breaks communication with the HMC, makes shell access
> impossible by anything other than the vterm console and in fact, hangs at
> boot due to some NFS stuff it tries to do (which I haven't configured).
>
> Has anyone followed this setup by the Redbook and is it the expected
> configuration that the 2nd VIO server be unreachable when in stand-by
> mode?
>
> Wil
> --
> Wil Cooley wcooley@nakedape.cc
> Naked Ape Consulting http://nakedape.cc
> * * * * Linux, UNIX, Networking and Security Solutions * * * *

On 2006-01-14, epacket <epacket@yahoo.com> wrote:
> Wil,
>
> I discovered the same issue with SEA failover. It looks very easy to
> set up in the redbook. The VIO 2 was not reachable via network, even
> if I pulled the network cables from VIO 1. I had to shutdown VIO 1 for
> the failover to occur, and then both the VIO 2 and clients had network
> connectivity. Then network would not fail back to VIO 1 even if I
> shutdown VIO 2.

Strange; mine seemed to failover properly. I called tech support and was
told to configure the physical ent with the IP address instead of the SEA;
I thought this had worked because setting ha_mode=standby on the primary
allowed me to continue pinging my client LPARs, but after physically removing
the connection and rebooting I did not see the failover work.

> A call to IBM support did not bring any real enlightenment to why. I
> got the same dull response as for a call a year earlier about general
> virtual networking. Could this be a 'not ready for prime-time'
> feature?

Seems like it.

> I've used the previous method of net_if backup etherchannel using both
> VIOS on separate VLANS trouble free for now until some new patches for
> VIO come out that might address it.

I guess I'll try this, or just let things be without redundancy;
currently our client LPARs are just used for development, so some
downtime is permissible.

> One thing good about VIO 1.2 is the ease of creating the vscsi
> server/client pairs. Much better than previous.

This is our first VIO installation; for that matter, we've only recently
started using micropartitioning and shared CPUs.

Wil
--
Wil Cooley wcooley@nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *

On 2006-01-16, Wil Cooley <wcooley@nakedape.cc> wrote:
> On 2006-01-14, epacket <epacket@yahoo.com> wrote:
>> Wil,
>>
>> I discovered the same issue with SEA failover. It looks very easy to
>> set up in the redbook. The VIO 2 was not reachable via network, even
>> if I pulled the network cables from VIO 1. I had to shutdown VIO 1 for
>> the failover to occur, and then both the VIO 2 and clients had network
>> connectivity. Then network would not fail back to VIO 1 even if I
>> shutdown VIO 2.
>
> Strange; mine seemed to failover properly. I called tech support and was
> told to configure the physical ent with the IP address instead of the SEA;
> I thought this had worked because setting ha_mode=standby on the primary
> allowed me to continue pinging my client LPARs, but after physically removing
> the connection and rebooting I did not see the failover work.

I am happy to say I got it to work. The problem is that there is a fix
required, but the APAR seems to share the same ID as another: IY77134.
I presume this is because one is for VIOS itself and the other is for
AIX 5.3, although the AIX fix is also for the SEA. The correct patch is
here:

ftp://ftp.software.ibm.com/software/....051111.epkg.Z

Wil
--
Wil Cooley wcooley@nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *