In a virtualised IBM Power Systems environment, understanding how I/O is abstracted and delivered to client LPARs is critical for designing, testing, and validating reliable enterprise workloads. Technologies such as Virtual Ethernet (vETH), SR-IOV based virtual NICs (vNIC), Virtual Fibre Channel (vFC), and Direct Attach I/O form the foundation of network and storage connectivity. Each configuration offers different trade-offs in terms of performance, flexibility, isolation, and resiliency, making them highly relevant for functional testing, performance benchmarking, and validation. This blog walks through these I/O models with simple block diagrams and practical context to help choose the right configuration for their Power server test environments.
1. vETH (Virtual Ethernet)
What it is
- vETH is a virtual network adapter used by client LPARs.
- It connects to the outside network through VIOS, not directly to physical NICs.
How it works with VIOS
- Client LPAR has a vETH adapter.
- VIOS has a corresponding Shared Ethernet Adapter (SEA).
- SEA bridges virtual traffic to a physical Ethernet adapter on the VIOS.
Typical test usage
- Basic network connectivity testing for LPARs.
- Functional validation of TCP/IP, MTU, VLAN tagging.
- Performance testing when SR-IOV is not required.
Key characteristics
- Fully virtualised.
- Slight overhead due to VIOS mediation.
- Highly flexible and easy to reconfigure.
Common commands
lsdev -type adapter | grep ent
lsmap -all -net
vETH (Virtual Ethernet via SEA) block diagram
+---------------------+ +----------------------+
| Client LPAR | | Client LPAR |
| | | |
| vETH (entX) | | vETH (entY) |
+----------+----------+ +----------+-----------+
| |
| Virtual Ethernet (VLAN) |
+------------+-----------------+
|
+-------+--------+
| VIOS |
| |
| SEA (entSEA) |
| | |
| Phys NIC |
| (ent0) |
+-------+--------+
|
Physical Network
|
Switch / LAN
Data path Client LPAR → vETH → VIOS SEA → Physical NIC → Network
2. vNIC (Virtual NIC, SR-IOV based)
What it is
- vNIC is a logical slice of a physical SR-IOV capable NIC.
- Traffic bypasses the VIOS data path.
How it works with VIOS
- VIOS still manages the hardware and provisioning.
- Data path goes directly between LPAR and NIC, not through SEA.
Typical test usage
- High performance networking tests.
- Low latency workload validation.
- Stress and scale testing of network intensive applications.
Key characteristics
- Near bare-metal performance.
- Lower CPU overhead than vETH.
- Requires SR-IOV capable adapters and firmware.
Test focus areas
- Failover behaviour.
- NIC reset and error injection.
- Performance comparison vs vETH.
vNIC (SR-IOV Virtual NIC) block diagram
+---------------------+ +---------------------+
| Client LPAR | | Client LPAR |
| | | |
| vNIC (SR-IOV VF) | | vNIC (SR-IOV VF) |
+----------+----------+ +----------+----------+
| |
| SR-IOV Virtual Functions |
+---------------+---------------+
|
+--------+---------+
| VIOS |
| |
| SR-IOV Manager |
| (control only) |
+--------+---------+
|
SR-IOV Physical NIC
|
Switch / LAN
Data path Client LPAR → vNIC → Physical NIC
VIOS is control plane only, not in data path.
3. vFC (Virtual Fibre Channel)
What it is
- vFC provides virtualised Fibre Channel storage access.
- Client LPAR accesses SAN disks through VIOS.
How it works with VIOS
- VIOS owns the physical FC adapter.
- VIOS presents virtual FC adapters to client LPARs.
- SAN zoning is still done using VIOS WWPNs.
Typical test usage
- SAN boot validation.
- Multipath I/O testing (MPIO).
- Error recovery and path failover testing.
- RAS validation for storage stack.
Key characteristics
- Storage traffic goes through VIOS.
- Mature and widely used in enterprise deployments.
- Slight latency compared to NPIV direct attach.
Common commands
lsmap -all -npiv
lsdev -type disk
vFC (Virtual Fibre Channel via VIOS) block diagram:
+---------------------+ +---------------------+
| Client LPAR | | Client LPAR |
| | | |
| vFC Adapter | | vFC Adapter |
+----------+----------+ +----------+----------+
| |
| Virtual Fibre Channel |
+------------+-----------------+
|
+-------+--------+
| VIOS |
| |
| Phys FC HBA |
| (NPIV) |
+-------+--------+
|
SAN Fabric
|
Storage Array (LUNs)
Data path Client LPAR → vFC → VIOS FC adapter → SAN → Storage
4. Direct Attach (Dedicated I/O)
What it is
- Physical adapter is exclusively assigned to one LPAR.
- No VIOS involvement in the data path.
This applies to:
- Dedicated Ethernet adapter.
- Dedicated Fibre Channel adapter.
How it works
- Adapter is removed from VIOS ownership.
- LPAR directly controls the hardware.
Typical test usage
- Baseline performance testing.
- Hardware specific feature validation.
- Comparing virtual vs native performance.
- Stress, reliability, and error handling tests.
Key characteristics
- Best performance and lowest latency.
- No sharing or flexibility.
- Less common in highly virtualised environments.
Direct Attach (Dedicated I/O) Block diagram
a) Direct Attach Ethernet
+---------------------+
| Client LPAR |
| |
| Dedicated NIC |
| (Physical Adapter) |
+----------+----------+
|
Physical Network
|
Switch / LAN
b) Direct Attach Fibre Channel
+---------------------+
| Client LPAR |
| |
| Dedicated FC HBA |
| (Physical Adapter) |
+----------+----------+
|
SAN Fabric
|
Storage Array
Data path Client LPAR → Physical Adapter → Network or SAN
No VIOS involvement.
Summary Comparison
|
Feature |
vETH |
vNIC |
vFC |
Direct Attach |
|
Uses VIOS data path |
Yes |
No |
Yes |
No |
|
Network or Storage |
Network |
Network |
Storage |
Both |
|
Performance |
Medium |
High |
Medium |
Highest |
|
Flexibility |
High |
Medium |
High |
Low |
|
Typical use |
Functional tests |
Perf tests |
SAN tests |
Baseline tests |
In a POWER Test Environment (Typical Setup)
- vETH for general functional, regression, and CI testing.
- vNIC for performance, scale, and latency sensitive workloads.
- vFC for SAN boot, MPIO, and storage RAS testing.
- Direct Attach for benchmark comparisons and hardware validation.
Quick Visual Comparison
vETH : LPAR → VIOS → NIC
vNIC : LPAR → NIC
vFC : LPAR → VIOS → FC → SAN
Direct : LPAR → Adapter → HW
How this helps in testing
- vETH: Validate SEA failover, VLAN isolation, MTU handling.
- vNIC: Measure latency, throughput, CPU savings.
- vFC: Test MPIO, SAN failover, error injection.
- Direct Attach: Establish performance and baseline.
Host Network Virtualization (HNV) on IBM Power Systems means that networking is centrally defined and enforced by the PowerVM hypervisor and the Virtual I/O Server (VIOS) rather than by individual LPARs. The hypervisor creates virtual Ethernet adapters, virtual switches, and VLAN isolation, ensuring that each LPAR only sees its assigned logical network and cannot alter network topology or policies. VIOS owns the physical NICs and provides the controlled data path using mechanisms such as Shared Ethernet Adapters, handling VLAN tagging, failover, load sharing, and connectivity to the external network. As a result, LPARs consume networking as a service, while all critical networking decisions, isolation, and resilience are managed outside the guest OS, which is the core principle of HNV in Power virtualization.
In HNV (Host Network Virtualization) on IBM Power:
- The hypervisor (PowerVM) defines and enforces the virtual network topology
- VIOS owns and manages the actual data path to the physical network
- LPARs never talk directly to the physical NIC
So control is split cleanly:
- Control plane → Hypervisor + VIOS
- Data plane → Mostly VIOS
1. Role of the PowerVM hypervisor
The hypervisor is the authority for virtual networking.
What the hypervisor controls
a. Virtual Ethernet adapters
- Each LPAR is given one or more virtual Ethernet (vEth) adapters
- These adapters are purely logical, no hardware backing
- Attributes controlled by hypervisor:
- VLAN ID
- PVID
- Trunk or access mode
- MAC address
The LPAR cannot change these. They are enforced outside the guest OS.
b. Virtual switches (vSwitch)
- PowerVM creates internal virtual switches
- vEth adapters are attached to a vSwitch
- The vSwitch determines:
- Which LPARs can communicate
- VLAN separation
- Broadcast domains
This is equivalent to a software L2 switch inside the hypervisor.
c. Network isolation
- VLAN enforcement happens before packets reach VIOS
- An LPAR cannot:
- See traffic from another VLAN
- Spoof VLANs outside its configuration
This isolation is hypervisor‑enforced, not guest‑controlled.
2. Role of VIOS (Virtual I/O Server)
VIOS is the bridge between virtual networks and physical networks.
What VIOS controls
a. Physical NIC ownership
- VIOS owns the physical Ethernet adapters
- Guest LPARs never see or manage NICs directly
b. Shared Ethernet Adapter (SEA)
VIOS creates an SEA, which:
- Binds:
- One or more physical NICs
- One or more virtual Ethernet adapters
- Bridges traffic between:
- Virtual switch (hypervisor side)
- Physical network (NIC side)
Think of SEA as a controlled software bridge.
c. Traffic handling and policies
VIOS controls:
- Failover between NICs
- Load sharing
- Promiscuous mode
- VLAN tagging and untagging
- Bandwidth sharing across LPARs
This is where centralised policy enforcement happens.
3. Packet flow: who touches the packet and when
Let us trace a packet from a Linux LPAR.
Step‑by‑step flow
- Linux guest
- Sends packet via eth0
- Guest believes this is a normal NIC
- Hypervisor
- Receives packet from vEth adapter
- Checks:
- VLAN validity
- vSwitch membership
- Isolation rules
- Virtual switch
- Forwards packet to the correct virtual port
- Usually the VIOS vEth
- VIOS
- SEA receives the packet
- Applies:
- VLAN tagging or stripping
- Failover logic
- QoS or load sharing
- Physical NIC
- Packet exits to external network
This is the essence of Host Network Virtualization.
|
Layer |
Who controls it |
|
VLANs |
Hypervisor + VIOS |
|
Switching |
Hypervisor |
|
NIC selection |
VIOS |
|
Failover |
VIOS |
|
Isolation |
Hypervisor |
|
Policy |
VIOS |
NOTE: What HNV and SR‑IOV fundamentally are
1) HNV (Host Network Virtualization:
- Software‑based network virtualization
- Networking is controlled by the hypervisor and VIOS
- LPARs use virtual Ethernet adapters
- Physical NICs are shared and abstracted
2) SR‑IOV (Single Root I/O Virtualization)
- Hardware‑assisted I/O virtualization
- NIC exposes multiple Virtual Functions (VFs)
- LPARs get direct access to NIC hardware
- Minimal hypervisor involvement in data path
|
Aspect |
HNV |
SR‑IOV |
|
Latency |
Higher |
Very low |
|
Throughput |
Good, but capped by VIOS |
Near line‑rate |
|
CPU overhead |
Higher due to VIOS |
Lower |
|
Determinism |
Less predictable |
Highly predictable |
In conclusion, vETH, vNIC, vFC, and Direct Attach I/O represent distinct I/O delivery models in IBM Power Systems, each serving different testing and deployment needs . While vETH and vFC provide flexibility and efficient resource sharing , vNIC and Direct Attach enable near native performance that is essential for performance benchmarking and latency sensitive workloads. A clear understanding of these architectures, their data paths, and failure domains helps test architects and automation engineers design realistic test environments, identify coverage gaps, and validate behaviour under stress and fault scenarios. Choosing the right I/O model is therefore not just an architectural decision, but a key enabler for building robust, observable, and enterprise ready Power server solutions.
