From: Jakob Klocker <j.klocker@proxmox.com>
To: pbs-devel@lists.proxmox.com
Cc: Jakob Klocker <j.klocker@proxmox.com>
Subject: [RFC proxmox{,-backup} 0/2] fix #7198: count veth uplink for PBS running in an LXC
Date: Tue, 7 Jul 2026 13:20:05 +0200 [thread overview]
Message-ID: <20260707112008.321788-1-j.klocker@proxmox.com> (raw)
When PBS runs inside an LXC container, network traffic graphs stay
empty for interfaces with non-standard names (e.g. wan0, vxb01). The
reporter [0] observed that renaming to eth0 and restarting made data
appear.
The cause is in collect_netdev_stats(): an interface is recorded as
NetdevType::Physical only if is_physical() returns true. Inside a
container the uplink is one end of a veth pair (info_kind = "veth"), so
is_physical() returns false and the code falls back to
PHYSICAL_NIC_REGEX, which only matches conventional names. A standard
name like eth0 matches the regex and is counted; a custom name does
not, so its stats are silently dropped. In a VM the guest NIC appears
as a normal hardware NIC without info_kind, which is why the VM case
works.
This series adds is_veth() to proxmox-network-api and gates the
collector on whether PBS runs in a container (checking
/run/systemd/container).
RFC / open questions:
This patch fixes the reported single-uplink case, but in a container
with several veths it counts all of them, including a veth enslaved to
a bridge. In testing (see below) a bridge-enslaved veth was still
counted. An alternative would be to count root-level interfaces without
a master instead of matching veth, which would exclude enslaved
interfaces and also generalise beyond veth.
Also this fix does not work if PBS is run in docker/podman,
since the interface is not a veth there (it was `tap` in podman).
LXC is the case that matters for PVE, so not covering podman/docker
seems acceptable to me.
Related, not fixed here:
NETWORK_INTERFACE_CACHE is a OnceLock populated once at proxy startup
and never refreshed, so interfaces added or renamed after startup are
not picked up until a restart. This matches the reporter's note that a
restart was required. It's pre-existing and independent of this fix.
Testing:
Reproduced in a PVE LXC running PBS with a custom-named veth uplink
("test"). Before: the interface produces no graph data. After: it is
counted. Verified via a temporary debug print in the collector that:
* the custom-named veth uplink is counted,
* a bridge (info_kind = bridge) is correctly excluded,
* with multiple veths present, all veths are counted, including a
bridge-enslaved one - the limitation noted above.
[0] https://bugzilla.proxmox.com/show_bug.cgi?id=7198
proxmox:
Jakob Klocker (1):
network-api: add is_veth helper to IpLink
proxmox-network-api/src/config/helper.rs | 13 +++++++++++++
1 file changed, 13 insertions(+)
proxmox-backup:
Jakob Klocker (1):
fix #7198: metric collection: count veth uplink when running in a
container
src/server/metric_collection/mod.rs | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
Summary over all repositories:
2 files changed, 20 insertions(+), 1 deletions(-)
--
Generated by murpp 0.12.0
next reply other threads:[~2026-07-07 11:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 11:20 Jakob Klocker [this message]
2026-07-07 11:20 ` [PATCH proxmox 1/2] network-api: add is_veth helper to IpLink Jakob Klocker
2026-07-07 11:20 ` [PATCH proxmox-backup 2/2] fix #7198: metric collection: count veth uplink when running in a container Jakob Klocker
2026-07-07 12:14 ` [RFC proxmox{,-backup} 0/2] fix #7198: count veth uplink for PBS running in an LXC Gabriel Goller
2026-07-07 12:47 ` Fabian Grünbichler
2026-07-08 8:49 ` Gabriel Goller
2026-07-08 8:11 ` Jakob Klocker
2026-07-08 8:45 ` Fabian Grünbichler
-- strict thread matches above, loose matches on Subject: below --
2026-07-07 10:55 Jakob Klocker
2026-07-07 11:17 ` Jakob Klocker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260707112008.321788-1-j.klocker@proxmox.com \
--to=j.klocker@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.