Re: [PATCH pve-network v3 09/17] sdn: dhcp: add an eBPF backend answering on each guest interface

[Hannes Laimer <h.laimer@proxmox.com>]

On 2026-10-20 15:11, Stefan Hanreich wrote:
> On 10/20/26 10:04 AM, Hannes Laimer wrote:
>> The ebpf DHCP backend answers DHCPv4 from a program in the kernel on
>> every guest interface of its zones, with the address the SDN MAC cache
>> holds for the interface's MAC. No server runs per zone, and IPv6
>> subnets are not served. A subnet without a gateway is served under a
>> link-local server identifier no host owns, so its guests renew by
>> broadcast at their rebinding time.
>>
>> An apply runs a full pass on each node, and on a node that no zone
>> with the ebpf backend includes, the pass removes the responder
>> altogether. A record change rewrites the answers for its MAC on the
>> node the change is made on, and the other nodes catch up at their
>> next apply.
>>
>> The responder is pinned in bpffs and does not survive a reboot, so a
>> boot hook runs a full pass. Removing the package deletes those pins,
>> since nothing would detach the responder afterward.
>>
>> Signed-off-by: Hannes Laimer <h.laimer@proxmox.com>
>> ---

[..]

>> +# the NIC lines come from pmxcfs in one go, so no guest config gets parsed for
>> +# this. With a vmid only that guest's lines are fetched
>> +sub guest_nics {
>> +    my ($vmid) = @_;
>> +
>> +    # a hook script starts with the cluster cache empty
>> +    PVE::Cluster::cfs_update();
>> +    my $vmlist = PVE::Cluster::get_vmlist();
>> +    my $nets = PVE::Cluster::get_guest_config_properties([map { "net$_" } 0 .. 31], $vmid);
>> +    my $nics = [];
>> +    for my $vmid (sort keys %$nets) {
>> +        my $guest = $vmlist->{ids}->{$vmid} // next;
>> +        my $prefix = ($guest->{type} // '') eq 'lxc' ? 'veth' : 'tap';
>> +        for my $key (sort keys %{ $nets->{$vmid} }) {
>> +            my ($index) = $key =~ m/^net(\d+)$/ or next;
>> +            my $net = $nets->{$vmid}->{$key};
>> +            my ($bridge) = $net =~ m/(?:^|,)bridge=([^,]+)/ or next;
>> +            # a VM names the MAC as the value of its model, a container as hwaddr
>> +            my ($mac) = $net =~ m/(?:^|,)[a-z0-9_-]+=([0-9a-f]{2}(?::[0-9a-f]{2}){5})(?:,|$)/i;
> 
> Is there a reason for not using the pre-existing parse_net /
> parse_lxc_network functions in qemu-server / pve-container here?
> They'd provide a standalone way of parsing the property string only,
> without re-implementing the logic here.
> 
> Circular dependencies potentially?

yes, both depend on pve-network :/
the lxc helper also fills the mac if missing, and for
`parse_property_string` we'd need the format

> 
>> +            push @$nics,
>> +                {
>> +                    vmid => $vmid,
>> +                    node => $guest->{node},
>> +                    iface => "$prefix${vmid}i$index",
>> +                    bridge => $bridge,
>> +                    mac => $mac,
>> +                };
>> +        }
>> +    }
>> +
>> +    return $nics;
>> +}
>> +


[..]