SEA - Shared Ethernet Adapter

SEA- Shared Ethernet Adapter is a Logical adapter created on the Virtual I/O server.
SEA enables virtual ethernet adapters to have a communication link to the external world (Outside the Physical server)

In an environment where you have PowerVM and virtual I/O servers and LPAR's that run on virtual resources, a device named SEA created on the virtual I/O server is responsible for handling the network traffic from the LPAR (Which has no I/O adapters) to the world outside (outside the physical server).

Why Virtualize I/O ?

With micro partitioning Technology emerging with POWER5 an IBM Pseries Frame could run LPAR's with a minimum of 0.1 processor .

Need to know more about Micro partitioning and shared processor partitioning ? Visit http://santechblogs.blogspot.com/2008/05/shared-processor-partition-in-ibm.html

Now consider a frame with 20 cpu's on it and lets assume that we create 40 LPAR's with 0.5 cpu each. Ohh yes we can run LPAR with a minimum of 0.1 cpu so 0.5 is more than fine.

Now coming back to the point of why virtualize I/O . Consider that each of these 40 LPARS needs at least one network adapter so that it can communicate to the network. That makes it 40 ethernet adapter slots. The Pseries servers comes with dual /quad port NIC adapters which cannot be divided between lpars, that way you need a minimum of 40 dual port NIC adapters on a frame which has just 20 cpu, which is not going to be possible. The case is similar if at least 20 of those lpars (if not all) requires SAN connectivity. We are definitely going to be short of NIC and HBA adapters. Thats exactly the need to Virtualize I/O

How Virtual I/O networking works

The VIO servers combined with the Power Hypervisor (part of hardware) is responsible for the functioning of the virtual networking. The virtual network operates in the power hypervisor and the VIO servers manages the inbound and outbound traffic to and from the server respectively.

The VIO servers gets the Physical adapters and the required connectivity to the network. The LPAR's then use the virtual network in the power hypervisor to route its network traffic through the VIO servers (which has connectivity to the network).

The LPAR's and VIO servers communicate using virtual adapters and VLANS which are created in the POWER Hypervisor space (The VLAN Numbers on the LPARS and VIO servers has no relation with what the actual network VLAN is). Each of the virtual ethernet adapters created on LPAR's as well as on the VIO servers has a VLAN number, virtual adpaters in the same VLAN can communicate to each other in the power hypervispor space. This includes the virtual ethernet adapter on the VIO server as well. The Virtual adapter on the VIO server then gets linked to the Physical ethernet adapter, which has connectivity to the external network. The device which links the Virtual ethernet adapter on the VIO server to a Physical adapter on the VIO server is called the SEA.

A SEA has the following components

1)A virtual Network adapter --- > To Communicate with virtual adapter on the LPAR's which are on the same VLAN

* A virtual adapter can be part of multiple VLAN's

2) A Physical Network adapter which has connectivity to external network also called as Backing device

3) Control Channel ----> These are Virtual adapters which operates inside the frame, sending heart beats across the 2 vio servers (2 vio servers are used for reedundancy) to check each others availability.

How different are virtual ethernet adapters on LPAR and Virtual ethernet adapters on VIO server?

The Virtual ethernet adapter on the LPAR and that on the client differs in the fact that, the one's on the VIO has connectivity to external network enabled. It also has a value called trunk priority set so as to decide which of the VIO server will act as primary at a given point, lesser the value higher the priority.

Yes, the Virtual ethernet adapter on the server gets linked to a physical adapter through a device called SEA which will then route the packets from the virtual ethernet adapter to the physical adapter and then it goes to the network. How does the packet from an LPAR reach the Virtual ethernet adapter ?

A Virtual ethernet adapter on the LPAR has visibility of all the other virtual ethernet adapter in the hypervisor space which belongs to the same VLAN as it is. for Example a Virtual ethernet adapter on an LPAR with VLAN ID 1 has visibility of all the Virtual ethernet adapters on other LPAR's with VLAN ID 1, these also include the Virtual ethernet adapters on the VIO servers which has the speciality that it has connectivity to external network enabled and also a trunk priority set. A packet originating from the LPAR passes through the LPAR's Virtual ethernet adapters if the transfer is for another lpar in the same frame with a Virtual ethernet adapter on the same VLAN the VIO server does not come into the picture. The Virtual ethernet adapters on both the LPAR's communicate in the hypervisor space and exchange of packet takes place. If the packet is suppose to be for a server outside the frame the Virtual ethernet adapter on the LPAR looks for a Virtual ethernet adapter in the same VLAN with external access enabled. In case it find multiple Virtual ethernet adapter with external access enabled it chooses one based on the trunk priority. Lesser the value higher the priority. So the packet has no reached the Virtual ethernet adapter on the VIO server which as we saw above has a link to the pysical adapter through a magic device called SEA (Shared Ethernet Adapter)


How to create Virtual network adapters and how to assign VLAN id's to them?.

Virtual adapters are defined in the profile of an LPAR. It can either be created by editing the profile and shutting down and activating the LPAR or by DLPAR operation to add the virtual ethernet adapter. The create task of virtual ethernet adapter involves specifying vlan id's for the virtual adapter as well. The adapter then shows up on the server and you can work with it in the same way as you do for a physical adapter.

Shared Processor partition in IBM power5

The IBM Power5 series has introduced the feature of shared processor partitions.
A group of Logical partition shares the processing power from a pool of physical processors. While that can be a one line description to what shared processor partition are , there is a lot to it than just running by using the processing power from a shared processor pool.

In power4, there was no concept of shared processor partitions and required LPARS to have dedicated processors assigned to it. The disadvantage here was that a lot processing power may remain idle with one LPAR while other LPAR'S are craving for more cpu's.

Shared Processor Partitions deals with the scenario in a better way. It steals idle cpu cycles from one LPAR and gives it to another LPAR which needs more processing power. The assigning of processing power when multiple LPARS compete for processor is decided on weightage given to the LPAR which will be detailed a little later.


A deeper dive now


Partitions on Power5 can be broadly classified into 2 based on the allocation of processors.


1 Dedicated Processor Partitions

2 Shared Processor Partitions


Dedicated Processor Partitions are much like the power4 LPAR'S and has a minimum,desired and maximum value for processors assigned to it.


Shared Processor Partitions shares the processors from a pool of processors.

All the processors which are not assigned to dedicated partitions together form the shared processor pool.

More About Shared Processor Partitions.

As said earlier sharedprocessor partitions uses processing power from a shared pool of processors.

Shared Processor Partitions are further divided into two

1 Capped Partition

Capped partition can make use of processing units lesser than or equal to its Entitled capacity from the shared pool


2 Uncapped partition


Uncapped partition can use more processing power than its entitled capacity in case it needs.


In the event of two uncapped partition competing for cpu from shared pool the lpar with a higher weightage will get the cpu cycles.


The weightage of LPAR is a value between 0-254 and the default is 128 . A value of 0 as weightage for an uncapped LPAR is considered as a capped partition.


Entitled capacity is the amount of processing units that gets assigned to the LPAR when the profile is activated. It can be any value ranging from the minimum value specified in profile upto the Desired value. [Remember that the maximum value for processing units is just applicable in case of a DLPAR operation to add more processing units on the fly]

The simple idea of Shared procressing pools is for LPARs to use processing units as and when its required and then put it back to the shared pool when they don't need it , so that other LPARs which might need extra processing power can pick it up from there.

Another thing to take care of when planning a shared processor partition is the virtual processor values.

Power5 LPARS has minimum, desired and maximum values for virtual processors in addition to the processor settings. The cpu from the shared pool are dispatched to the virtual processor by the power Hypervisor.

The total processing units an LPAR holds can conceptually be viewed as equally divided among the virtual processors. A virtual processor cannot hold more than 1.0 processing unit, so the number of virtual processors should be chosen, so as to harvest the additional processing power the LPAR may need to acquire from the shared pool.

For Eg if you have an uncapped partition with 2 virtual processors and the entitled capacity of the LPAR is 1.0 processing units. As load increases the server will demand and acquire more processing power from the shared pool. The amount of processing units becomes 1.5 ... 1.75 and then 2.0 . Unfortunately the LPAR cannot take any more processing units from the shared pool even if the shared pool has free processing units ,because it has run out of virtual processor. If the number virtual processor we specified while creating the LPAR was 3, we could have taken one more processing unit out of the shared pool to meet the processing requirement of the LPAR.

To Sum up

The shared processor partition, provides a way by which Processing power can be efficiently used between a set of LPARS by using the processing power as and when required and not holding up udle cpu cycles or rather not wasting it. Additional control over the way the processing power will be allocated/distributed are provided by features such as capped and uncapped partition and also the weightage for the uncapped partition.