Eight Virtual NIC Functions Are Not Eight Physical Network Ports

Separate the PCIe function from the physical port

Single Root I/O Virtualization, or SR-IOV, lets a PCIe device expose multiple functions to a virtualized system. Intel's Ethernet Adapters and Devices User Guide 29.2, dated November 28, 2024, distinguishes a physical function, or PF, with full PCIe management capabilities from a virtual function, or VF, assigned to a VM. It explicitly describes one network port appearing as several virtual functions.

The Linux kernel's PCI I/O virtualization overview explains why these can appear as separate devices: each VF has its own PCI configuration address and mapped register space. Its driver operates that interface. The guest can therefore receive a hardware-backed device interface without receiving another adapter card or external connector.

Keep the two inventories separate. A PF belongs to the PCIe function inventory; a physical network port belongs to the external attachment inventory. Do not assume one PF equals one jack across devices. Ask the equipment or virtualization supplier to identify the actual relationship between each assigned VF, its parent PF and the physical port or ports that carry its external traffic.

References: [I1][K1]

Direct assignment changes the packet path

Microsoft's Hyper-V SR-IOV documentation describes a VF data path that bypasses the virtualization stack's software switch for traffic between the VM and its attached VF. The adapter still handles the network traffic, and external packets use its physical network port. In that architecture, an internal NIC switch connects the PF/VF interfaces with the external port.

Direct describes how the VM accesses adapter resources. It does not mean that the VM owns the whole adapter or has an exclusive external link. Several separately addressable functions can converge on the same physical attachment. Traffic that remains inside the adapter also needs to be distinguished from traffic that actually crosses the external link.

The appointed platform and security owners must assess the intended implementation; separate memory and interrupt resources alone do not approve a complete tenant-security design.

References: [M1][M2]

Compare four VFs on one port with four physical ports

Consider two fictional offers for networking used by four VMs. Offer A assigns one VF to each VM. Stipulate that all four VFs use one active physical port, P1, operating at 100 Gb/s. That port has one direct external cable connection to one switch port. The example assumes no intermediate patching or alternate external path.

A supplies four function allocations and one external connection. The external port's nominal rate remains 100 Gb/s. Multiplying four VFs by that rate to advertise 400 Gb/s would count the same physical link four times. Dividing 100 by four would be a different unsupported step: the offer has stated no equal 25 Gb/s entitlement, minimum reservation or scheduling policy.

Now stipulate that the four VMs each request 30 Gb/s of simultaneous traffic through P1 toward the external network. Their combined demand is 120 Gb/s against one 100 Gb/s nominal link in that direction. Creating more functions cannot supply that missing external capacity. This arithmetic identifies a capacity mismatch under the stated demand; it predicts no throughput, fairness, latency or packet-loss outcome.

Offer B explicitly identifies four separate physical ports, P1 through P4, each operating at 100 Gb/s, with four direct cable connections and four remote switch-port terminations. Its nominal port-rate sum is 400 Gb/s in one direction across those four links. B supplies a different physical connection inventory. Its supplier must still explain how the VMs use those ports and what resources each VM is entitled to receive. Four ports alone establish neither a 400 Gb/s path for one VM nor achieved application throughput.

If A instead advertises eight VFs while retaining the same P1 attachment, its function population has doubled and its external port inventory has stayed at one. If B's four ports share other hardware, those common dependencies also remain. Neither offer is universally preferable: the useful comparison concerns the required allocations, concurrent external demand and actual connections.

Check each port even when the combined rate looks sufficient

A second fictional supplier comparison keeps the connection count fixed: four VFs, A, B, C and D, and two distinct active physical ports, P1 and P2, each operating at 100 Gb/s. Each VF has 40 Gb/s of simultaneous outward demand to the external network in one direction. Total demand is therefore 160 Gb/s, below the ports' 200 Gb/s nominal sum. The VF-to-port relationships below are explicit offer inputs, not relationships inferred from PF counts. All demand must cross the external port named for that VF; no adapter-internal traffic, automatic remapping or alternate route is included.

The supplier's mapUneven assigns A, B and C to P1, and D to P2. P1 must carry three 40 Gb/s demands, totaling 120 Gb/s against its 100 Gb/s nominal rate. P2 has only D's 40 Gb/s demand against its own 100 Gb/s rate. The adapter-wide comparison of 160 with 200 therefore hides a 20 Gb/s nominal shortfall at P1.

P2 has 60 Gb/s of nominal headroom in that arithmetic, but it is headroom on a different physical attachment. Under mapUneven, A, B and C still need their traffic to leave through P1. Subtracting P1's shortfall from P2's headroom would silently assume a way for that demand to use P2, which this offer has not supplied. Counting both ports correctly does not make their spare rates interchangeable for the stipulated traffic.

The alternative supplier mapBalanced assigns A and B to P1, and C and D to P2. Each port now has two 40 Gb/s demands, or 80 Gb/s against 100 Gb/s. The comparison still contains four VFs, two ports, 160 Gb/s of total outward demand and a 200 Gb/s nominal port-rate sum. What changed is which demand reaches each external port. Neither port has the specific nominal overdemand found in mapUneven.

For the represented demand, mapUneven fails that per-port capacity comparison, while mapBalanced avoids the identified mismatch. That result establishes no attained throughput, reserved per-VM bandwidth, host or PCIe capacity, isolation or redundancy. The 40 Gb/s values are demand premises, not equal-share entitlements. A supplier response that lists only four VFs and two 100 Gb/s ports leaves the decisive allocation unresolved: request the actual supplied map before treating the offers as equivalent.

Locate the shared dependency before calling paths independent

In fictional Offer A, all four VM allocations depend on the same external cable and port for the stipulated external path. If that cable becomes unavailable, none of the four can use that path. This is a consequence of the stated mapping, not a claim that all VF devices disappear or that every form of local communication stops. No alternate path or recovery behavior has been stipulated.

Offer B separates the four cable connections, so the loss of one cable concerns a different physical boundary. Yet its four ports could reside on the same adapter, in the same host, or connect to the same upstream switch. Four external connections do not prove four independent failure domains.

Name the event the purchase must tolerate. Retaining connectivity after one cable is unavailable is a different requirement from retaining it after an adapter, host or upstream switch becomes unavailable. Ask the supplier to identify which resources the relevant VM paths share and how any claimed continuity is provided. Separate function identities cannot answer that availability question.

Compare the allocation and the external connection together

Have each supplier state whether its advertised interface is an SR-IOV VF, a whole-device allocation or another virtual network interface. A generic virtual NIC count does not establish the mechanism. For a VF offer, request the exact adapter and supported host, hypervisor, guest and driver combination, together with the VF-to-PF-to-port relationship. A general statement that the adapter supports SR-IOV leaves the offered implementation unresolved.

Read the bandwidth description separately. Which active physical ports carry external traffic, at what operating rates, and which other allocations share them? For each port, add the concurrent external demands mapped to it in the direction being compared, then compare that demand with the port's stated operating rate. Keep this per-port comparison alongside the adapter-wide sum. Does a per-VM rate describe a supported cap, an agreed minimum or an expectation under stated conditions? Have the supplier explain any claimed resource policy and its applicability rather than deriving an entitlement from the number of VFs. Relevant operating evidence must address the intended competing traffic, not just an otherwise idle allocation.

Use the resulting description to decide what is missing. A shared-port allocation can fit a requirement for several VM interfaces whose external demands fit the offered service. A requirement for separately identified external connections needs those ports and connections explicitly included. A requirement for continuity beyond a named hardware failure needs the corresponding path and operating behavior explained. Additional VFs resolve none of those missing physical requirements by themselves.

Bring the physical port map to a cabling inquiry when work is needed

If the selection also requires equipment cabling, use the physical port map to define that work. Count the actual connections and specified assemblies, including any retained links and patching, rather than ordering one cable for every VF. The linked cable-schedule guide explains how connection relationships and material quantities differ.

Leviathan's Structured Cabling & Fiber service can discuss agreed installation of customer-supplied compatible assemblies, routing, dressing, labeling and physical connection records. Use the service and project-inquiry links below to share a nonconfidential endpoint schedule, approved routes, material responsibilities, site constraints and requested records. VF creation, hypervisor and guest integration, resource policies and workload verification belong with the separately appointed platform and software providers.

References: [L1]