network: backport VM QoS live/hot update to 1.7-dev

[zbb88888]

Backport the VM network QoS changes from pr-17213 into the 1.7-dev branch.

This backport includes:

• initial VM network QoS API and generated artifacts

• NET_ADMIN capability for root virt-launcher so tc-based QoS commands can run

• live update and hot-update handling for interface QoS changes

• cleanup of temporary QoS hot-update debug logs

• 1.7-dev-specific conflict resolution that ports virtwrap converter changes into the legacy converter layout

What this PR does

Before this PR:

After this PR:

References

Why we need it and why it was done in this way

The following tradeoffs were made:

The following alternatives were considered:

Links to places where the discussion took place:

Special notes for your reviewer

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Design: A VEP (virtualization enhancement proposal) was considered and is present (link) or not required
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Testing: New code requires new unit tests. New features and bug fixes require at least one e2e test
• Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
• Community: Announcement to kubevirt-dev was considered
• AI Contributions: The PR abides by the KubeVirt AI Contribution Policy.

Release note

[gemini-code-assist]

Code Review

This pull request introduces support for network interface bandwidth (QoS) limits for Virtual Machine Instances. It adds new Bandwidth and BandwidthParams fields to the interface specification, allowing users to define inbound and outbound average, peak, and burst rates. The implementation includes API updates, conversion logic from Kubernetes quantities to Libvirt units, and the addition of the NET_ADMIN capability to the virt-launcher container to enable traffic control commands. Furthermore, the PR enables dynamic updates of bandwidth settings for existing interfaces. I have no feedback to provide as there were no review comments to evaluate.

[fennoai]

Code Review — VM Network QoS Backport

This PR introduces bandwidth QoS support via new Bandwidth/BandwidthParams API types, a NET_ADMIN capability grant, and live/hot update propagation to libvirt. Overall the structure is solid, but a few issues warrant attention.

[fennoai]

Security: NET_ADMIN granted to all root virt-launcher pods, not just those with QoS configured.

NET_ADMIN is one of the most powerful Linux capabilities — it allows arbitrary manipulation of network interfaces, iptables, routing tables, and traffic control. Adding it unconditionally to every root virt-launcher (regardless of whether any interface has a Bandwidth spec) violates least-privilege and expands the blast radius of any virt-launcher compromise.

Consider gating this on whether the VMI actually has at least one interface with a non-nil Bandwidth field, or applying it only to the specific code path that invokes tc commands.

[fennoai]

API docs claim bytes/sec but conversion divides by 1024; also missing peak >= average enforcement.

1. The converter's quantityToLibvirtKB divides every value by 1024 before passing it to libvirt. The test at converter_test.go inputs "1000Ki" and expects 1000, confirming the function really expects kibibytes as input — not raw bytes. However, the field comments here say "Average rate in bytes/sec". Any user who passes "1000" (1000 bytes) will get 0 after integer division (1000 / 1024 = 0), silently disabling the rate limit.

   The API documentation should match the actual unit contract (kibibytes/sec for average/peak, kibibytes for burst), or the converter should be updated to correctly handle byte-unit input.

2. Libvirt requires peak >= average when both are set. There is no CEL validation marker or admission webhook check enforcing this ordering. A violating spec will pass API validation and fail opaquely at the libvirt layer rather than producing a clear Kubernetes admission error.

[fennoai]

Observability gap: log line removed without replacement, and the error message below still says "link state" when bandwidth changes can also flow through this path.

The log.Log.Infof("preparing to update link state...") call was removed here, and no replacement log was added for bandwidth updates. In a production cluster, there is now no trace log when updateIfaceInDomain is called, making it harder to diagnose QoS enforcement failures.

Also, the error message a few lines down ("libvirt failed to set link state to interface...") now fires for both link-state and bandwidth changes, which will mislead operators. Suggest replacing with something like: "libvirt failed to update interface %s: %v".

[fennoai]

Minor: state is unconditionally overwritten when only bandwidth changed.

When shouldUpdateExistingIfaceState == false and only shouldUpdateExistingIfaceBandwidth == true, vmiIface.State = vmIface.State still executes. This is currently safe because the states must already be equal (otherwise shouldUpdateExistingIfaceState would be true), but the code doesn't make that invariant explicit. A future change to the condition logic could silently introduce an unintended state reset.

Guarding the state assignment with if shouldUpdateExistingIfaceState would make intent unambiguous:

if shouldUpdateExistingIfaceState {
    vmiIface.State = vmIface.State
}
if shouldUpdateExistingIfaceBandwidth {
    vmiIface.Bandwidth = vmIface.Bandwidth.DeepCopy()
}

[fennoai]

Dead overflow guard on 64-bit platforms.

maxUint := uint64(^uint(0))
if uint64(val) > maxUint {
    return uint(maxUint)
}

val is int64; on a 64-bit platform ^uint(0) is uint64 max (18446744073709551615), which is always greater than any int64 value. The branch can never be taken. This provides false safety assurance — callers may assume extreme values are capped, but on 64-bit they pass through unchanged. Consider removing the dead check and instead enforcing an explicit upper-bound limit (e.g., reject anything above a sensible max like 10 Gbit/s) in the admission webhook.