[PATCH ifupdown2 0/4] Fix multiple Single VXLAN Devices in bridge and some dry-run fixes

[PATCH ifupdown2 0/4] Fix multiple Single VXLAN Devices in bridge and some dry-run fixes

[Robin Christ]

From: Robin Christ <r.christ@partimus.com>

This patch series primarily fixes multiple Single VXLAN Devices in a bridge not
working properly.
It also contains some fixes for the dry-run mode.

Note: I've never used the git e-mail workflow before (1970 has called, they want their
workflow back). Sorry if what I'm sending isn't up to the mailing list standards :)

My company e-mail doesn't work with git send-email, hence the two different e-mail addresses..

Robin Christ (4):
  nlcache: Fix missing nodad option in addr_add_dry_run
  nlcache: Add missing link_set_mtu_dry_run method
  iproute2: Fix bridge_link_update_vni_filter for dry-run
  bridge: Fix multiple Single VXLAN Devices in bridge not having
    tunnel_info applied on first run

 ...ing-nodad-option-in-addr_add_dry_run.patch |  35 ++++++
 ...-missing-link_set_mtu_dry_run-method.patch |  25 +++++
 ...e_link_update_vni_filter-for-dry-run.patch |  62 +++++++++++
 ...tiple-single-vxlan-devices-in-bridge.patch | 101 ++++++++++++++++++
 debian/patches/series                         |   4 +
 5 files changed, 227 insertions(+)
 create mode 100644 debian/patches/pve/0016-nlcache-fix-missing-nodad-option-in-addr_add_dry_run.patch
 create mode 100644 debian/patches/pve/0017-nlcache-add-missing-link_set_mtu_dry_run-method.patch
 create mode 100644 debian/patches/pve/0018-iproute2-fix-bridge_link_update_vni_filter-for-dry-run.patch
 create mode 100644 debian/patches/pve/0019-bridge-fix-multiple-single-vxlan-devices-in-bridge.patch

-- 
2.47.3

[PATCH ifupdown2 1/4] nlcache: Fix missing nodad option in addr_add_dry_run

[Robin Christ]

From: Robin Christ <r.christ@partimus.com>

nodad option was added to nlcache NetlinkListenerWithCache addr_add, but not addr_add_dry_run,
breaking dry runs (--no-act) with the error

NetlinkListenerWithCache.addr_add_dry_run() got an unexpected keyword argument 'nodad'

Signed-off-by: Robin Christ <r.christ@partimus.com>
---
 ...ing-nodad-option-in-addr_add_dry_run.patch | 35 +++++++++++++++++++
 debian/patches/series                         |  1 +
 2 files changed, 36 insertions(+)
 create mode 100644 debian/patches/pve/0016-nlcache-fix-missing-nodad-option-in-addr_add_dry_run.patch

diff --git a/debian/patches/pve/0016-nlcache-fix-missing-nodad-option-in-addr_add_dry_run.patch b/debian/patches/pve/0016-nlcache-fix-missing-nodad-option-in-addr_add_dry_run.patch
new file mode 100644
index 0000000..6706fd7
--- /dev/null
+++ b/debian/patches/pve/0016-nlcache-fix-missing-nodad-option-in-addr_add_dry_run.patch
@@ -0,0 +1,35 @@
+From: Robin Christ <r.christ@partimus.com>
+Date: Mon, 30 Mar 2026 18:44:20 +0200
+Subject: nlcache: Fix missing nodad option in addr_add_dry_run
+
+nodad option was added to nlcache NetlinkListenerWithCache addr_add, but not addr_add_dry_run,
+breaking dry runs (--no-act) with the error
+
+NetlinkListenerWithCache.addr_add_dry_run() got an unexpected keyword argument 'nodad'
+
+Signed-off-by: Robin Christ <r.christ@partimus.com>
+---
+ ifupdown2/lib/nlcache.py | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/ifupdown2/lib/nlcache.py b/ifupdown2/lib/nlcache.py
+index 33dd909..a92ac6f 100644
+--- a/ifupdown2/lib/nlcache.py
++++ b/ifupdown2/lib/nlcache.py
+@@ -3393,12 +3393,15 @@ class NetlinkListenerWithCache(nllistener.NetlinkManagerWithListener, BaseObject
+     # ADDRESS
+     ############################################################################
+ 
+-    def addr_add_dry_run(self, ifname, addr, broadcast=None, peer=None, scope=None, preferred_lifetime=None, metric=None):
++    def addr_add_dry_run(self, ifname, addr, broadcast=None, peer=None, scope=None, preferred_lifetime=None, metric=None, nodad=False):
+         log_msg = ["netlink: ip addr add %s dev %s" % (addr, ifname)]
+ 
+         if scope:
+             log_msg.append("scope %s" % scope)
+ 
++        if nodad:
++            log_msg.append("nodad")
++
+         if broadcast:
+             log_msg.append("broadcast %s" % broadcast)
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 2865533..8655369 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -16,3 +16,4 @@ upstream/0001-use-raw-strings-for-regex-to-fix-backslash-interpret.patch
 upstream/0002-vxlan-add-support-for-IPv6-vxlan-local-tunnelip.patch
 pve/0014-nlmanager-read-ipv6-devconf-disable_ipv6-attribute-t.patch
 pve/0015-revert-addons-bond-warn-if-sub-interface-is-detected-on-bond-slave.patch
+pve/0016-nlcache-fix-missing-nodad-option-in-addr_add_dry_run.patch
-- 
2.47.3

[PATCH ifupdown2 2/4] nlcache: Add missing link_set_mtu_dry_run method

[Robin Christ]

From: Robin Christ <r.christ@partimus.com>

nlcache NetlinkListenerWithCache got a new link_set_mtu based on netlink at
some point, but never the dry run variant link_set_mtu_dry_run,
breaking dry runs

Signed-off-by: Robin Christ <r.christ@partimus.com>
---
 ...-missing-link_set_mtu_dry_run-method.patch | 25 +++++++++++++++++++
 debian/patches/series                         |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 debian/patches/pve/0017-nlcache-add-missing-link_set_mtu_dry_run-method.patch

diff --git a/debian/patches/pve/0017-nlcache-add-missing-link_set_mtu_dry_run-method.patch b/debian/patches/pve/0017-nlcache-add-missing-link_set_mtu_dry_run-method.patch
new file mode 100644
index 0000000..f90dd78
--- /dev/null
+++ b/debian/patches/pve/0017-nlcache-add-missing-link_set_mtu_dry_run-method.patch
@@ -0,0 +1,25 @@
+From: Robin Christ <r.christ@partimus.com>
+Date: Mon, 30 Mar 2026 18:59:04 +0200
+Subject: nlcache: Add missing link_set_mtu_dry_run method
+
+nlcache NetlinkListenerWithCache got a new link_set_mtu based on netlink at some point, but never the dry run variant link_set_mtu_dry_run, breaking dry runs
+
+Signed-off-by: Robin Christ <r.christ@partimus.com>
+---
+ ifupdown2/lib/nlcache.py | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/ifupdown2/lib/nlcache.py b/ifupdown2/lib/nlcache.py
+index a92ac6f..2d37443 100644
+--- a/ifupdown2/lib/nlcache.py
++++ b/ifupdown2/lib/nlcache.py
+@@ -3331,6 +3331,9 @@ class NetlinkListenerWithCache(nllistener.NetlinkManagerWithListener, BaseObject
+ 
+     ###
+ 
++    def link_set_mtu_dry_run(self, ifname, mtu):
++        self.log_info_ifname_dry_run(ifname, "netlink: ip link set dev %s mtu %s" % (ifname, mtu))
++
+     """
+     Sets the MTU of the given link, updating the cache on success.
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 8655369..45d92cb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -17,3 +17,4 @@ upstream/0002-vxlan-add-support-for-IPv6-vxlan-local-tunnelip.patch
 pve/0014-nlmanager-read-ipv6-devconf-disable_ipv6-attribute-t.patch
 pve/0015-revert-addons-bond-warn-if-sub-interface-is-detected-on-bond-slave.patch
 pve/0016-nlcache-fix-missing-nodad-option-in-addr_add_dry_run.patch
+pve/0017-nlcache-add-missing-link_set_mtu_dry_run-method.patch
-- 
2.47.3

[PATCH ifupdown2 3/4] iproute2: Fix bridge_link_update_vni_filter for dry-run

[Robin Christ]

From: Robin Christ <r.christ@partimus.com>

This appears to have been primarily a simple indentation error (block
should've been in indented, but was not)

During dry run, the command "bridge -j -p vni show dev %s" will not
be executed and thus return empty string. vnishow will be None
and accessing it will err.

Signed-off-by: Robin Christ <r.christ@partimus.com>
---
 ...e_link_update_vni_filter-for-dry-run.patch | 62 +++++++++++++++++++
 debian/patches/series                         |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 debian/patches/pve/0018-iproute2-fix-bridge_link_update_vni_filter-for-dry-run.patch

diff --git a/debian/patches/pve/0018-iproute2-fix-bridge_link_update_vni_filter-for-dry-run.patch b/debian/patches/pve/0018-iproute2-fix-bridge_link_update_vni_filter-for-dry-run.patch
new file mode 100644
index 0000000..4ab9f16
--- /dev/null
+++ b/debian/patches/pve/0018-iproute2-fix-bridge_link_update_vni_filter-for-dry-run.patch
@@ -0,0 +1,62 @@
+From: Robin Christ <r.christ@partimus.com>
+Date: Mon, 30 Mar 2026 19:14:26 +0200
+Subject: iproute2: Fix bridge_link_update_vni_filter for dry-run
+
+This appears to have been primarily a simple indentation error (block
+should've been in indented, but was not)
+
+During dry run, the command "bridge -j -p vni show dev %s" will not
+be executed and thus return empty string. vnishow will be None
+and accessing it will err.
+---
+ ifupdown2/lib/iproute2.py | 35 +++++++++++++++++++----------------
+ 1 file changed, 19 insertions(+), 16 deletions(-)
+
+diff --git a/ifupdown2/lib/iproute2.py b/ifupdown2/lib/iproute2.py
+index 15b581e..894afd3 100644
+--- a/ifupdown2/lib/iproute2.py
++++ b/ifupdown2/lib/iproute2.py
+@@ -1044,24 +1044,27 @@ class IPRoute2(Cache, Requirements):
+             output = utils.exec_command(cmd)
+             if output:
+                 vnishow = json.loads(output.strip("\n"))
+-            self.logger.debug(vnishow)
+-            for s in vnishow:
+-                vlist = s.get('vnis')
+-                for v in vlist:
+-                    vstart = v.get('vni')
+-                    vend = v.get('vniEnd')
+-                    group = v.get('group')
+-                    if vend:
+-                        for tv in range(int(vstart), int(vend)+1):
++                self.logger.debug(vnishow)
++                for s in vnishow:
++                    vlist = s.get('vnis')
++                    for v in vlist:
++                        vstart = v.get('vni')
++                        vend = v.get('vniEnd')
++                        group = v.get('group')
++                        if vend:
++                            for tv in range(int(vstart), int(vend)+1):
++                                if group:
++                                    rvnisd[tv] = group
++                                else:
++                                    rvnisd[tv] = None
++                        else:
+                             if group:
+-                                rvnisd[tv] = group
++                                rvnisd[int(vstart)] = group
+                             else:
+-                                rvnisd[tv] = None
+-                    else:
+-                        if group:
+-                            rvnisd[int(vstart)] = group
+-                        else:
+-                            rvnisd[int(vstart)] = None
++                                rvnisd[int(vstart)] = None
++            else:
++                self.logger.debug("%s: no output - dry run? Assuming no vnis assigned" % cmd)
++
+             vnis_int = vnisd.keys()
+             rvnis_int = rvnisd.keys()
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 45d92cb..1dc2fc6 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -18,3 +18,4 @@ pve/0014-nlmanager-read-ipv6-devconf-disable_ipv6-attribute-t.patch
 pve/0015-revert-addons-bond-warn-if-sub-interface-is-detected-on-bond-slave.patch
 pve/0016-nlcache-fix-missing-nodad-option-in-addr_add_dry_run.patch
 pve/0017-nlcache-add-missing-link_set_mtu_dry_run-method.patch
+pve/0018-iproute2-fix-bridge_link_update_vni_filter-for-dry-run.patch
-- 
2.47.3

[PATCH ifupdown2 4/4] bridge: Fix multiple Single VXLAN Devices in bridge not having tunnel_info applied on first run

[Robin Christ]

From: Robin Christ <r.christ@partimus.com>

If you add multiple Single VXLAN Devices to a bridge, only the last one would get the proper
tunnel_info applied, ultimately resulting in a non-functional network setup.
This could be fixed by a second execution of ifupdown2.

The reason for this was that the original code was not written with multiple Single VXLAN Devices
in a single bridge in mind, thus it had only the variable single_vxlan_device_ifaceobj storing
a single interface that would control the application of tunnel_info the bridge's SVDs.
Replacing the variable against a list single_vxlan_device_ifaceobjs and adding another little
loop fixes the issue.

Additionally, some very exhaustive, clarifying information has been added

Signed-off-by: Robin Christ <r.christ@partimus.com>
---
 ...tiple-single-vxlan-devices-in-bridge.patch | 101 ++++++++++++++++++
 debian/patches/series                         |   1 +
 2 files changed, 102 insertions(+)
 create mode 100644 debian/patches/pve/0019-bridge-fix-multiple-single-vxlan-devices-in-bridge.patch

diff --git a/debian/patches/pve/0019-bridge-fix-multiple-single-vxlan-devices-in-bridge.patch b/debian/patches/pve/0019-bridge-fix-multiple-single-vxlan-devices-in-bridge.patch
new file mode 100644
index 0000000..1374426
--- /dev/null
+++ b/debian/patches/pve/0019-bridge-fix-multiple-single-vxlan-devices-in-bridge.patch
@@ -0,0 +1,101 @@
+From: Robin Christ <r.christ@partimus.com>
+Date: Mon, 30 Mar 2026 21:07:41 +0200
+Subject: bridge: Fix multiple Single VXLAN Devices in bridge not having
+ tunnel_info applied on first run
+
+If you add multiple Single VXLAN Devices to a bridge, only the last one would get the proper
+tunnel_info applied, ultimately resulting in a non-functional network setup.
+This could be fixed by a second execution of ifupdown2.
+
+The reason for this was that the original code was not written with multiple Single VXLAN Devices
+in a single bridge in mind, thus it had only the variable single_vxlan_device_ifaceobj storing
+a single interface that would control the application of tunnel_info the bridge's SVDs.
+Replacing the variable against a list single_vxlan_device_ifaceobjs and adding another little
+loop fixes the issue.
+
+Additionally, some very exhaustive, clarifying information has been added
+
+Signed-off-by: Robin Christ <r.christ@partimus.com>
+---
+ ifupdown2/addons/bridge.py | 54 +++++++++++++++++++++++++++++++++++++++++++---
+ 1 file changed, 51 insertions(+), 3 deletions(-)
+
+diff --git a/ifupdown2/addons/bridge.py b/ifupdown2/addons/bridge.py
+index dee6f7b..5918c94 100644
+--- a/ifupdown2/addons/bridge.py
++++ b/ifupdown2/addons/bridge.py
+@@ -2145,7 +2145,51 @@ class bridge(Bridge, moduleBase):
+ 
+     def up_apply_brports_attributes(self, ifaceobj, ifaceobj_getfunc, bridge_vlan_aware, target_ports=[], newly_enslaved_ports=[]):
+         ifname = ifaceobj.name
+-        single_vxlan_device_ifaceobj = None
++        # Historically, "Single VXLAN Device" was chosen to name the concept of having
++        # a single VXLAN interface with "external" flag in ip link (Kernel VXLAN_F_COLLECT_METADATA)
++        # that is also the only VXLAN interface slave of the bridge. This VXLAN interface
++        # would terminate all the VNIs for the bridge, improving scalability a lot, as now you
++        # don't have to create a VXLAN interface for each VNI.
++        # In the beginning, you could only ONE Single VXLAN device per UDP-Port on the entire system.
++        # However, it was recognized that there may be the need to have multiple "Single VXLAN Devices"
++        # on your system, and in kernel commit f9c4bb0b245cee35ef66f75bf409c9573d934cf9 the possibility
++        # to have multiple SVD's was added, but it requires the "vnifilter" flag (kernel VXLAN_F_VNIFILTER)
++        #
++        # But even with Single VXLAN Devices at hand, there are valid scenarios where you may want to have multiple
++        # Single VXLAN Devices on the same bridge! One scenario could be traffic steering in BGP-to-the-host
++        # setups, where you don't want separate bridges per VXLAN interface (e.g. because customer VMs don't
++        # want a single trunk port that terminates in different VXLAN interface depending on the VLAN)
++        #
++        # Addendum: A little explanation how "Single VXLAN Device" works in kernel:
++        # In the beginning, a VXLAN interface could only have a single VNI assigned. You had to create one
++        # VXLAN device per VNI, which didn't scale. Therefore, the following flags were added:
++        #
++        # 1. link add dev <ifname> type vxlan external
++        # This flag is what makes a VXLAN interface a "Single VXLAN Device"!
++        # The "external" flag is very oddly and cryptically named. While technically the naming is correct, as it
++        # indicates "whether an external control plane (e.g. ip route encap) or the internal FDB should be used"
++        # it doesn't really help you as a user.
++        # It was added in kernel commit ee122c79d4227f6ec642157834b6a90fcffa4382 ("vxlan: Flow based tunneling")
++        # and is called VXLAN_F_COLLECT_METADATA
++        # What this flag essentially does it that a VXLAN interface with "external" flag
++        # **will receive traffic for all VNIs** on the entire system, and there can be only ONE of them (unless
++        # you add the "vnifilter" flag!)
++        # With this flag active, you must do 'bridge vlan add dev <ifname> vid <vid> tunnel_info id <vni>'!
++        #
++        # 2. link add dev <ifname> type vxlan vnifilter
++        # As mentioned above, at some point it was recognized that there may be the need
++        # to have multiple "Single VXLAN Devices".
++        # Therefore in kernel commit f9c4bb0b245cee35ef66f75bf409c9573d934cf9
++        # ("vxlan: vni filtering support on collect metadata device") the possibility
++        # to have multiple SVD's was added, using the "vnifilter" flag (kernel VXLAN_F_VNIFILTER)
++        # This flag limits which VNIs are received on a "Single VXLAN Device", ultimately
++        # allowing you to have multiple "Single VXLAN Devices" on the same system...
++        # and even on the same bridge!
++        # With this flag active, you must do 'bridge vni add dev <ifname> vni <vni>'
++        # yes, even though this uses the bridge command, this is not really related to bridges
++        # at all and <ifname> is the name of a VXLAN interface!
++
++        single_vxlan_device_ifaceobjs = []
+ 
+         try:
+             brports_ifla_info_slave_data    = dict()
+@@ -2471,7 +2515,7 @@ class bridge(Bridge, moduleBase):
+                     #
+ 
+                     if brport_ifaceobj.link_privflags & ifaceLinkPrivFlags.SINGLE_VXLAN:
+-                        single_vxlan_device_ifaceobj = brport_ifaceobj
++                        single_vxlan_device_ifaceobjs.append(brport_ifaceobj)
+                         brport_vlan_tunnel_cached_value = self.cache.get_link_info_slave_data_attribute(
+                             brport_name,
+                             Link.IFLA_BRPORT_VLAN_TUNNEL
+@@ -2501,7 +2545,11 @@ class bridge(Bridge, moduleBase):
+         except Exception as e:
+             self.log_error(str(e), ifaceobj)
+ 
+-        if single_vxlan_device_ifaceobj:
++        # As explained at the top of the function, we have have multiple SVD's enslaved to our bridge
++        # If we don't handle them all here, we will have the scenario where only the FIRST enslaved
++        # VXLAN interface gets the tunnel_info applied, and the other ones don't... Leading to the
++        # scenario that the network config is only correctly applied after another ifreload...
++        for single_vxlan_device_ifaceobj in single_vxlan_device_ifaceobjs:
+             self.apply_bridge_port_vlan_vni_map(single_vxlan_device_ifaceobj)
+ 
+     @staticmethod
diff --git a/debian/patches/series b/debian/patches/series
index 1dc2fc6..a059c38 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -19,3 +19,4 @@ pve/0015-revert-addons-bond-warn-if-sub-interface-is-detected-on-bond-slave.patc
 pve/0016-nlcache-fix-missing-nodad-option-in-addr_add_dry_run.patch
 pve/0017-nlcache-add-missing-link_set_mtu_dry_run-method.patch
 pve/0018-iproute2-fix-bridge_link_update_vni_filter-for-dry-run.patch
+pve/0019-bridge-fix-multiple-single-vxlan-Devices-in-bridge.patch
-- 
2.47.3

Re: [PATCH ifupdown2 4/4] bridge: Fix multiple Single VXLAN Devices in bridge not having tunnel_info applied on first run

[Gabriel Goller]

On 30.03.2026 23:39, Robin Christ wrote:
> From: Robin Christ <r.christ@partimus.com>
> 
> If you add multiple Single VXLAN Devices to a bridge, only the last one would get the proper
> tunnel_info applied, ultimately resulting in a non-functional network setup.
> This could be fixed by a second execution of ifupdown2.
> 
> The reason for this was that the original code was not written with multiple Single VXLAN Devices
> in a single bridge in mind, thus it had only the variable single_vxlan_device_ifaceobj storing
> a single interface that would control the application of tunnel_info the bridge's SVDs.
> Replacing the variable against a list single_vxlan_device_ifaceobjs and adding another little
> loop fixes the issue.
> 
> Additionally, some very exhaustive, clarifying information has been added
> 
> Signed-off-by: Robin Christ <r.christ@partimus.com>
> ---
>  ...tiple-single-vxlan-devices-in-bridge.patch | 101 ++++++++++++++++++
>  debian/patches/series                         |   1 +
>  2 files changed, 102 insertions(+)
>  create mode 100644 debian/patches/pve/0019-bridge-fix-multiple-single-vxlan-devices-in-bridge.patch

Thanks for these patches!
If you haven't already, please sign the contribution
agreement and send it to office@proxmox.com
(https://pve.proxmox.com/wiki/Developer_Documentation#Software_License_and_Copyright).

The dry-run patches before look good, maybe @Christoph can have a look at them as well.

About this one though: what is the use-case? we don't use SVDs and so the
tunnel_info property is also not used AFAIK?

Re: [PATCH ifupdown2 4/4] bridge: Fix multiple Single VXLAN Devices in bridge not having tunnel_info applied on first run

[Robin Christ]

On Tue Mar 31, 2026 at 10:18 AM CEST, Gabriel Goller wrote:                                                                                                            
> Thanks for these patches!                                                                                                                                            
> If you haven't already, please sign the contribution                                                                                                                 
> agreement and send it to office@proxmox.com                                                                                                                          
> (https://pve.proxmox.com/wiki/Developer_Documentation#Software_License_and_Copyright).                                                                               
                                                                                                                                                                       
On it, probably gonna send it tomorrow.                                                                                                                                
                                                                                                                                                                       
> The dry-run patches before look good, maybe @Christoph can have a look at them as well.                                                                              
                                                                                                                                                                       
I noticed that in my last patch, there is a little typo in debian/patches/series as I renamed the patch file.                                                          
Should I post a new patch or can that be fixed on merge?                                                                                                               
                                                                                                                                                                       
> About this one though: what is the use-case? we don't use SVDs and so the                                                                                            
> tunnel_info property is also not used AFAIK?                                                                                                                         
                                                                                                                                                                       
Not yet... ;) We (Partimus) are currently rebuilding our entire network, and we use a lot of EVPN with Proxmox.                                                        
We're probably building one of the most extreme EVPN setups you'll ever find in the wild right now, but all based on Proxmox.                                          
We completely circumvent the existing Proxmox SDN though, as it by far doesn't fit our requirements.                                                                   
                                                                                                                                                                       
TL;DR our use case for SVDs, and multiple SVDs in a single bridge: Traffic Steering.                                                                                   
I will drop you some details via direct e-mail.                                                                                                                        
                                                                                                                                                                       
As it seems like ifupdown2 upstream development has effectively been halted, Proxmox seemed like the best way                                                          
to file the fixes.