[pve-devel] [PATCH manager/widget-toolkit v2 0/2] show altenative interface names in the web ui

[pve-devel] [PATCH manager/widget-toolkit v2 0/2] show altenative interface names in the web ui

[Dominik Csapak]

This series goes on top of Stefan Hahnreich's last series[0], but it seems
there is still some things missing from INotify (to e.g. set the altnames via
the api), so maybe the helper I introduce in the pve-manager patch will be
unnecessary, depending if parsing the interfaces file will already return the
altnames.

Note that the pve-manager patch depends on the widget-toolkit patch

changes from v1:
* show correct alternatives for ifaces with an altname in the iface stanza
* sort altnames

0: https://lore.proxmox.com/pve-devel/20250709194526.560709-2-s.hanreich@proxmox.com/

proxmox-widget-toolkit:

Dominik Csapak (1):
  network: optionally show alternative interface names

 src/node/NetworkEdit.js | 19 +++++++++++++++++++
 src/node/NetworkView.js | 20 ++++++++++++++++++++
 2 files changed, 39 insertions(+)


pve-manager:

Dominik Csapak (1):
  api/ui: show/return alternative interface names

 PVE/API2/Network.pm         | 41 +++++++++++++++++++++++++++++++++++--
 www/manager6/node/Config.js |  1 +
 2 files changed, 40 insertions(+), 2 deletions(-)


Summary over all repositories:
  4 files changed, 79 insertions(+), 2 deletions(-)

-- 
Generated by git-murpp 0.8.1


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [PATCH widget-toolkit v2 1/1] network: optionally show alternative interface names

[Dominik Csapak]

add a new (hidden by default) column for the interface names, and show
them when editing an existing interface with such alternative names.

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
no changes from v1
 src/node/NetworkEdit.js | 19 +++++++++++++++++++
 src/node/NetworkView.js | 20 ++++++++++++++++++++
 2 files changed, 39 insertions(+)

diff --git a/src/node/NetworkEdit.js b/src/node/NetworkEdit.js
index b8e23f9..cd9dc7c 100644
--- a/src/node/NetworkEdit.js
+++ b/src/node/NetworkEdit.js
@@ -5,6 +5,9 @@ Ext.define('Proxmox.node.NetworkEdit', {
     // Enable to show the VLAN ID field
     enableBridgeVlanIds: false,
 
+    // Show alternative names below normal name
+    showAltNames: false,
+
     initComponent: function () {
         let me = this;
 
@@ -363,6 +366,14 @@ Ext.define('Proxmox.node.NetworkEdit', {
             },
         );
 
+        if (me.showAltNames && !me.isCreate) {
+            column1.push({
+                xtype: 'displayfield',
+                name: 'altnames',
+                fieldLabel: gettext("Alternative Names"),
+            });
+        }
+
         if (me.iftype === 'OVSBond') {
             column1.push(
                 {
@@ -449,6 +460,14 @@ Ext.define('Proxmox.node.NetworkEdit', {
                         });
                         return;
                     }
+
+                    if (data.altnames) {
+                        if (Ext.isArray(data.altnames)) {
+                            data.altnames = data.altnames.join('<br>');
+                        }
+                    } else {
+                        me.down('field[name=altnames]').setVisible(false);
+                    }
                     me.setValues(data);
                     me.isValid(); // trigger validation
                 },
diff --git a/src/node/NetworkView.js b/src/node/NetworkView.js
index cf8e6b7..0c62388 100644
--- a/src/node/NetworkView.js
+++ b/src/node/NetworkView.js
@@ -4,6 +4,7 @@ Ext.define('proxmox-networks', {
         'active',
         'address',
         'address6',
+        'altnames',
         'autostart',
         'bridge_ports',
         'cidr',
@@ -33,6 +34,9 @@ Ext.define('Proxmox.node.NetworkView', {
 
     showApplyBtn: false,
 
+    // if true, the altnames column will be shown by default
+    showAltNames: false,
+
     // for options passed down to the network edit window
     editOptions: {},
 
@@ -103,6 +107,7 @@ Ext.define('Proxmox.node.NetworkView', {
                 nodename: me.nodename,
                 iface: rec.data.iface,
                 iftype: rec.data.type,
+                showAltNames: me.showAltNames,
                 ...me.editOptions,
                 listeners: {
                     destroy: () => reload(),
@@ -278,6 +283,21 @@ Ext.define('Proxmox.node.NetworkView', {
                             sortable: true,
                             dataIndex: 'iface',
                         },
+                        {
+                            header: gettext("Alternative Names"),
+                            dataIndex: 'altnames',
+                            hidden: !me.showAltNames,
+                            width: 140, // enough space for 'enx<MAC>'
+                            renderer: (value) => {
+                                if (!value) {
+                                    return '';
+                                }
+                                if (Ext.isArray(value)) {
+                                    return value.map(Ext.htmlEncode).join('<br>');
+                                }
+                                return Ext.htmlEncode(value);
+                            },
+                        },
                         {
                             header: gettext('Type'),
                             sortable: true,
-- 
2.39.5



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH widget-toolkit v2 1/1] network: optionally show alternative interface names

[Thomas Lamprecht]

Am 15.07.25 um 11:07 schrieb Dominik Csapak:
> add a new (hidden by default) column for the interface names, and show
> them when editing an existing interface with such alternative names.
> 

Look OK code-wise in general, UX comments inline.

> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
> no changes from v1
>  src/node/NetworkEdit.js | 19 +++++++++++++++++++
>  src/node/NetworkView.js | 20 ++++++++++++++++++++
>  2 files changed, 39 insertions(+)
> 
> diff --git a/src/node/NetworkEdit.js b/src/node/NetworkEdit.js
> index b8e23f9..cd9dc7c 100644
> --- a/src/node/NetworkEdit.js
> +++ b/src/node/NetworkEdit.js

> @@ -449,6 +460,14 @@ Ext.define('Proxmox.node.NetworkEdit', {
>                          });
>                          return;
>                      }
> +
> +                    if (data.altnames) {
> +                        if (Ext.isArray(data.altnames)) {
> +                            data.altnames = data.altnames.join('<br>');


hmm, with a handful of interfaces each having a handful of altnames
this would increase the height quite a bit I would think.

What do you think about joining the array with comma+space and enabling
sensible text wrapping on word boundaries in this column instead?

> +                        }
> +                    } else {
> +                        me.down('field[name=altnames]').setVisible(false);
> +                    }
>                      me.setValues(data);
>                      me.isValid(); // trigger validation
>                  },
> diff --git a/src/node/NetworkView.js b/src/node/NetworkView.js
> index cf8e6b7..0c62388 100644
> --- a/src/node/NetworkView.js
> +++ b/src/node/NetworkView.js

> @@ -278,6 +283,21 @@ Ext.define('Proxmox.node.NetworkView', {
>                              sortable: true,
>                              dataIndex: 'iface',
>                          },
> +                        {
> +                            header: gettext("Alternative Names"),
> +                            dataIndex: 'altnames',
> +                            hidden: !me.showAltNames,
> +                            width: 140, // enough space for 'enx<MAC>'
> +                            renderer: (value) => {
> +                                if (!value) {
> +                                    return '';
> +                                }
> +                                if (Ext.isArray(value)) {
> +                                    return value.map(Ext.htmlEncode).join('<br>');

same as above w.r.t. join separator.

> +                                }
> +                                return Ext.htmlEncode(value);
> +                            },
> +                        },
>                          {
>                              header: gettext('Type'),
>                              sortable: true,



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH widget-toolkit v2 1/1] network: optionally show alternative interface names

[Thomas Lamprecht]

On Tue, 15 Jul 2025 11:07:48 +0200, Dominik Csapak wrote:
> add a new (hidden by default) column for the interface names, and show
> them when editing an existing interface with such alternative names.
> 
> 

Stefan argued that ip link shows it also vertically and that it's slightly more
readable that way, and that there are normale only two or three altnames, and
that was enough to convie me:

Applied, thanks!

[1/1] network: optionally show alternative interface names
      commit: 691f530d81e3c8a3642ea08d2019cce8c83f7ae4


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [PATCH pve-manager v2 1/1] api/ui: show/return alternative interface names

[Dominik Csapak]

in api listing for all interfaces, and in the GET call for an individual
interface.

For intefaces that are already using an 'altname' in the iface stanza,
we look up the 'legacy' interface name and the remaining altnames and
show those.

If we don't show them, the user might be confused if the bridge ports
and interface names don't correlate.

enables the additional alternative names column in the network view on
the gui.

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
changes from v1:
* also show alternative names for ifaces with altname stanza
  (include legacy iface in that case)
* sort the altnames

 PVE/API2/Network.pm         | 41 +++++++++++++++++++++++++++++++++++--
 www/manager6/node/Config.js |  1 +
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/PVE/API2/Network.pm b/PVE/API2/Network.pm
index a8cd7649..53e0ea0e 100644
--- a/PVE/API2/Network.pm
+++ b/PVE/API2/Network.pm
@@ -12,6 +12,7 @@ use PVE::RESTHandler;
 use PVE::RPCEnvironment;
 use PVE::JSONSchema qw(get_standard_option);
 use PVE::AccessControl;
+use PVE::Network;
 use IO::File;
 
 use base qw(PVE::RESTHandler);
@@ -231,6 +232,32 @@ sub json_config_properties {
     return $prop;
 }
 
+sub extract_altnames {
+    my ($iface, $altnames) = @_;
+
+    $altnames = PVE::Network::altname_mapping() if !defined($altnames);
+
+    my $iface_altnames = [];
+    my $original_iface;
+
+    # when we get an altname, first extract the legacy iface name
+    if (my $legacy_iface = $altnames->{$iface}) {
+        push $iface_altnames->@*, $legacy_iface;
+        $original_iface = $iface;
+        $iface = $legacy_iface;
+    }
+
+    for my $altname (keys $altnames->%*) {
+        next if defined($original_iface) && $original_iface eq $altname;
+        if ($altnames->{$altname} eq $iface) {
+            push $iface_altnames->@*, $altname;
+        }
+    }
+
+    return [sort $iface_altnames->@*] if scalar($iface_altnames->@*) > 0;
+    return undef;
+}
+
 __PACKAGE__->register_method({
     name => 'index',
     path => '',
@@ -390,6 +417,8 @@ __PACKAGE__->register_method({
 
         my $ifaces = $config->{ifaces};
 
+        my $altnames = PVE::Network::altname_mapping();
+
         delete $ifaces->{lo}; # do not list the loopback device
 
         if (my $tfilter = $param->{type}) {
@@ -424,6 +453,9 @@ __PACKAGE__->register_method({
             my $type = $ifaces->{$k}->{type};
             delete $ifaces->{$k}
                 if ($type eq 'bridge' || $type eq 'OVSBridge') && !$can_access_vnet->($k);
+
+            my $iface_altnames = extract_altnames($k, $altnames);
+            $ifaces->{$k}->{altnames} = $iface_altnames if defined($iface_altnames);
         }
 
         return PVE::RESTHandler::hash_to_array($ifaces, 'iface');
@@ -789,10 +821,15 @@ __PACKAGE__->register_method({
         my $config = PVE::INotify::read_file('interfaces');
         my $ifaces = $config->{ifaces};
 
+        my $iface = $param->{iface};
+
         raise_param_exc({ iface => "interface does not exist" })
-            if !$ifaces->{ $param->{iface} };
+            if !$ifaces->{$iface};
+
+        my $altnames = extract_altnames($iface);
+        $ifaces->{$iface}->{altnames} = $altnames if defined($altnames);
 
-        return $ifaces->{ $param->{iface} };
+        return $ifaces->{$iface};
     },
 });
 
diff --git a/www/manager6/node/Config.js b/www/manager6/node/Config.js
index 4cd1671c..f6cd8749 100644
--- a/www/manager6/node/Config.js
+++ b/www/manager6/node/Config.js
@@ -190,6 +190,7 @@ Ext.define('PVE.node.Config', {
                     iconCls: 'fa fa-exchange',
                     itemId: 'network',
                     showApplyBtn: true,
+                    showAltNames: true,
                     groups: ['services'],
                     nodename: nodename,
                     editOptions: {
-- 
2.39.5



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH pve-manager v2 1/1] api/ui: show/return alternative interface names

[Stefan Hanreich]

Was formulating my response to v1, but you were too fast with sending a
v2 for me. I think we need to also consider the case where we pinned and
replaced the names in /e/n/i via pveeth already, but the changes to the
network interface names haven't yet been applied. The problem here is
that we also return interfaces contained in /proc/net/dev in the
overview as well [1] - which would lead to duplicate interface names in
the view.

I considered applying the changes to the network interface names
immediately via `udevadm trigger`. Alternatively, I thought of adding
the old names as altnames when pinning network interfaces, but not in a
persistent manner. I think both would solve this state between
transitioning from the old names to the new names. What do you think?

Generally I agree with using the names from the /e/n/i file as our
'real' name, since the view is basically the interfaces file, but with
the important caveat that we also include interfaces from /proc/net/dev.

[1]
https://git.proxmox.com/?p=pve-common.git;a=blob;f=src/PVE/INotify.pm;h=dbad08c3fc5494403a061b9d77d587314477a9f5;hb=HEAD#l897

On 7/15/25 11:07, Dominik Csapak wrote:
> in api listing for all interfaces, and in the GET call for an individual
> interface.
> 
> For intefaces that are already using an 'altname' in the iface stanza,
> we look up the 'legacy' interface name and the remaining altnames and
> show those.
> 
> If we don't show them, the user might be confused if the bridge ports
> and interface names don't correlate.
> 
> enables the additional alternative names column in the network view on
> the gui.
> 
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
> changes from v1:
> * also show alternative names for ifaces with altname stanza
>   (include legacy iface in that case)
> * sort the altnames
> 
>  PVE/API2/Network.pm         | 41 +++++++++++++++++++++++++++++++++++--
>  www/manager6/node/Config.js |  1 +
>  2 files changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/PVE/API2/Network.pm b/PVE/API2/Network.pm
> index a8cd7649..53e0ea0e 100644
> --- a/PVE/API2/Network.pm
> +++ b/PVE/API2/Network.pm
> @@ -12,6 +12,7 @@ use PVE::RESTHandler;
>  use PVE::RPCEnvironment;
>  use PVE::JSONSchema qw(get_standard_option);
>  use PVE::AccessControl;
> +use PVE::Network;
>  use IO::File;
>  
>  use base qw(PVE::RESTHandler);
> @@ -231,6 +232,32 @@ sub json_config_properties {
>      return $prop;
>  }
>  
> +sub extract_altnames {
> +    my ($iface, $altnames) = @_;
> +
> +    $altnames = PVE::Network::altname_mapping() if !defined($altnames);
> +
> +    my $iface_altnames = [];
> +    my $original_iface;
> +
> +    # when we get an altname, first extract the legacy iface name
> +    if (my $legacy_iface = $altnames->{$iface}) {
> +        push $iface_altnames->@*, $legacy_iface;
> +        $original_iface = $iface;
> +        $iface = $legacy_iface;
> +    }
> +
> +    for my $altname (keys $altnames->%*) {
> +        next if defined($original_iface) && $original_iface eq $altname;
> +        if ($altnames->{$altname} eq $iface) {
> +            push $iface_altnames->@*, $altname;
> +        }
> +    }
> +
> +    return [sort $iface_altnames->@*] if scalar($iface_altnames->@*) > 0;
> +    return undef;
> +}
> +
>  __PACKAGE__->register_method({
>      name => 'index',
>      path => '',
> @@ -390,6 +417,8 @@ __PACKAGE__->register_method({
>  
>          my $ifaces = $config->{ifaces};
>  
> +        my $altnames = PVE::Network::altname_mapping();
> +
>          delete $ifaces->{lo}; # do not list the loopback device
>  
>          if (my $tfilter = $param->{type}) {
> @@ -424,6 +453,9 @@ __PACKAGE__->register_method({
>              my $type = $ifaces->{$k}->{type};
>              delete $ifaces->{$k}
>                  if ($type eq 'bridge' || $type eq 'OVSBridge') && !$can_access_vnet->($k);
> +
> +            my $iface_altnames = extract_altnames($k, $altnames);
> +            $ifaces->{$k}->{altnames} = $iface_altnames if defined($iface_altnames);
>          }
>  
>          return PVE::RESTHandler::hash_to_array($ifaces, 'iface');
> @@ -789,10 +821,15 @@ __PACKAGE__->register_method({
>          my $config = PVE::INotify::read_file('interfaces');
>          my $ifaces = $config->{ifaces};
>  
> +        my $iface = $param->{iface};
> +
>          raise_param_exc({ iface => "interface does not exist" })
> -            if !$ifaces->{ $param->{iface} };
> +            if !$ifaces->{$iface};
> +
> +        my $altnames = extract_altnames($iface);
> +        $ifaces->{$iface}->{altnames} = $altnames if defined($altnames);
>  
> -        return $ifaces->{ $param->{iface} };
> +        return $ifaces->{$iface};
>      },
>  });
>  
> diff --git a/www/manager6/node/Config.js b/www/manager6/node/Config.js
> index 4cd1671c..f6cd8749 100644
> --- a/www/manager6/node/Config.js
> +++ b/www/manager6/node/Config.js
> @@ -190,6 +190,7 @@ Ext.define('PVE.node.Config', {
>                      iconCls: 'fa fa-exchange',
>                      itemId: 'network',
>                      showApplyBtn: true,
> +                    showAltNames: true,
>                      groups: ['services'],
>                      nodename: nodename,
>                      editOptions: {



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH pve-manager v2 1/1] api/ui: show/return alternative interface names

[Dominik Csapak]

On 7/15/25 11:21, Stefan Hanreich wrote:
> Was formulating my response to v1, but you were too fast with sending a
> v2 for me. I think we need to also consider the case where we pinned and
> replaced the names in /e/n/i via pveeth already, but the changes to the
> network interface names haven't yet been applied. The problem here is
> that we also return interfaces contained in /proc/net/dev in the
> overview as well [1] - which would lead to duplicate interface names in
> the view.
> 
> I considered applying the changes to the network interface names
> immediately via `udevadm trigger`. Alternatively, I thought of adding
> the old names as altnames when pinning network interfaces, but not in a
> persistent manner. I think both would solve this state between
> transitioning from the old names to the new names. What do you think?


ok, so from what i can tell 'pveeth pin' writes directly into the /e/n/i file?
shouldn't it write to /e/n/i.new file (or whatever it's named) so we
show it as pending change?

then we could do the udevadm trigger in the 'apply config' api handler?

also, basically the 'altname' lookup code would also have to lookup the
.link files ? (seems like it's a lot of work/disk reading to do?)

> 
> Generally I agree with using the names from the /e/n/i file as our
> 'real' name, since the view is basically the interfaces file, but with
> the important caveat that we also include interfaces from /proc/net/dev.
> 
> [1]
> https://git.proxmox.com/?p=pve-common.git;a=blob;f=src/PVE/INotify.pm;h=dbad08c3fc5494403a061b9d77d587314477a9f5;hb=HEAD#l897
> 
> On 7/15/25 11:07, Dominik Csapak wrote:
>> in api listing for all interfaces, and in the GET call for an individual
>> interface.
>>
>> For intefaces that are already using an 'altname' in the iface stanza,
>> we look up the 'legacy' interface name and the remaining altnames and
>> show those.
>>
>> If we don't show them, the user might be confused if the bridge ports
>> and interface names don't correlate.
>>
>> enables the additional alternative names column in the network view on
>> the gui.
>>
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>> changes from v1:
>> * also show alternative names for ifaces with altname stanza
>>    (include legacy iface in that case)
>> * sort the altnames
>>
>>   PVE/API2/Network.pm         | 41 +++++++++++++++++++++++++++++++++++--
>>   www/manager6/node/Config.js |  1 +
>>   2 files changed, 40 insertions(+), 2 deletions(-)
>>
>> diff --git a/PVE/API2/Network.pm b/PVE/API2/Network.pm
>> index a8cd7649..53e0ea0e 100644
>> --- a/PVE/API2/Network.pm
>> +++ b/PVE/API2/Network.pm
>> @@ -12,6 +12,7 @@ use PVE::RESTHandler;
>>   use PVE::RPCEnvironment;
>>   use PVE::JSONSchema qw(get_standard_option);
>>   use PVE::AccessControl;
>> +use PVE::Network;
>>   use IO::File;
>>   
>>   use base qw(PVE::RESTHandler);
>> @@ -231,6 +232,32 @@ sub json_config_properties {
>>       return $prop;
>>   }
>>   
>> +sub extract_altnames {
>> +    my ($iface, $altnames) = @_;
>> +
>> +    $altnames = PVE::Network::altname_mapping() if !defined($altnames);
>> +
>> +    my $iface_altnames = [];
>> +    my $original_iface;
>> +
>> +    # when we get an altname, first extract the legacy iface name
>> +    if (my $legacy_iface = $altnames->{$iface}) {
>> +        push $iface_altnames->@*, $legacy_iface;
>> +        $original_iface = $iface;
>> +        $iface = $legacy_iface;
>> +    }
>> +
>> +    for my $altname (keys $altnames->%*) {
>> +        next if defined($original_iface) && $original_iface eq $altname;
>> +        if ($altnames->{$altname} eq $iface) {
>> +            push $iface_altnames->@*, $altname;
>> +        }
>> +    }
>> +
>> +    return [sort $iface_altnames->@*] if scalar($iface_altnames->@*) > 0;
>> +    return undef;
>> +}
>> +
>>   __PACKAGE__->register_method({
>>       name => 'index',
>>       path => '',
>> @@ -390,6 +417,8 @@ __PACKAGE__->register_method({
>>   
>>           my $ifaces = $config->{ifaces};
>>   
>> +        my $altnames = PVE::Network::altname_mapping();
>> +
>>           delete $ifaces->{lo}; # do not list the loopback device
>>   
>>           if (my $tfilter = $param->{type}) {
>> @@ -424,6 +453,9 @@ __PACKAGE__->register_method({
>>               my $type = $ifaces->{$k}->{type};
>>               delete $ifaces->{$k}
>>                   if ($type eq 'bridge' || $type eq 'OVSBridge') && !$can_access_vnet->($k);
>> +
>> +            my $iface_altnames = extract_altnames($k, $altnames);
>> +            $ifaces->{$k}->{altnames} = $iface_altnames if defined($iface_altnames);
>>           }
>>   
>>           return PVE::RESTHandler::hash_to_array($ifaces, 'iface');
>> @@ -789,10 +821,15 @@ __PACKAGE__->register_method({
>>           my $config = PVE::INotify::read_file('interfaces');
>>           my $ifaces = $config->{ifaces};
>>   
>> +        my $iface = $param->{iface};
>> +
>>           raise_param_exc({ iface => "interface does not exist" })
>> -            if !$ifaces->{ $param->{iface} };
>> +            if !$ifaces->{$iface};
>> +
>> +        my $altnames = extract_altnames($iface);
>> +        $ifaces->{$iface}->{altnames} = $altnames if defined($altnames);
>>   
>> -        return $ifaces->{ $param->{iface} };
>> +        return $ifaces->{$iface};
>>       },
>>   });
>>   
>> diff --git a/www/manager6/node/Config.js b/www/manager6/node/Config.js
>> index 4cd1671c..f6cd8749 100644
>> --- a/www/manager6/node/Config.js
>> +++ b/www/manager6/node/Config.js
>> @@ -190,6 +190,7 @@ Ext.define('PVE.node.Config', {
>>                       iconCls: 'fa fa-exchange',
>>                       itemId: 'network',
>>                       showApplyBtn: true,
>> +                    showAltNames: true,
>>                       groups: ['services'],
>>                       nodename: nodename,
>>                       editOptions: {
> 



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH pve-manager v2 1/1] api/ui: show/return alternative interface names

[Stefan Hanreich]

On 7/15/25 11:30, Dominik Csapak wrote:
> On 7/15/25 11:21, Stefan Hanreich wrote:
>> Was formulating my response to v1, but you were too fast with sending a
>> v2 for me. I think we need to also consider the case where we pinned and
>> replaced the names in /e/n/i via pveeth already, but the changes to the
>> network interface names haven't yet been applied. The problem here is
>> that we also return interfaces contained in /proc/net/dev in the
>> overview as well [1] - which would lead to duplicate interface names in
>> the view.
>>
>> I considered applying the changes to the network interface names
>> immediately via `udevadm trigger`. Alternatively, I thought of adding
>> the old names as altnames when pinning network interfaces, but not in a
>> persistent manner. I think both would solve this state between
>> transitioning from the old names to the new names. What do you think?
> 
> 
> ok, so from what i can tell 'pveeth pin' writes directly into the /e/n/i
> file?
> shouldn't it write to /e/n/i.new file (or whatever it's named) so we
> show it as pending change?

Currently yes, but I am still considering what would be the best way
forward. I think you could make an argument for both. The problem is
that while we have this mechanism of a temporary configuration file for
/etc/network/interfaces and SDN, we do not have one for the firewall
configuration. There is a dry_run functionality in pveeth, but it just
generates the files in a different location.

It might make more sense to implement it as a two-step process:

* Pinning generates the new configuration files in the pending config of
/e/n/i and SDN. For the firewall we'd have to create one as well and
probably just handle this manually in the following step.

* Add another command that applies the temporary changes which would
also include applying the changes via udevadm immediately.

Then users could inspect the generated changes via our UI (at least for
Network / SDN). This would then also allow us to remove the dry_run
functionality, since it would be implicitly included in this create /
apply process. It would also solve the issue with this weird limbo state.

I'm just unsure on how we could integrate showing the changes to the FW
configuration in a nice way.

> then we could do the udevadm trigger in the 'apply config' api handler?
> 
> also, basically the 'altname' lookup code would also have to lookup the
> .link files ? (seems like it's a lot of work/disk reading to do?)

Yes, exactly - hence why I considered adding them as an altname since
this would save us this procedure of parsing *all* link files in order
to be able to generate a sensible view of /e/n/i.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH pve-manager v2 1/1] api/ui: show/return alternative interface names

[Dominik Csapak]

On 7/15/25 11:41, Stefan Hanreich wrote:
> On 7/15/25 11:30, Dominik Csapak wrote:
>> On 7/15/25 11:21, Stefan Hanreich wrote:
>>> Was formulating my response to v1, but you were too fast with sending a
>>> v2 for me. I think we need to also consider the case where we pinned and
>>> replaced the names in /e/n/i via pveeth already, but the changes to the
>>> network interface names haven't yet been applied. The problem here is
>>> that we also return interfaces contained in /proc/net/dev in the
>>> overview as well [1] - which would lead to duplicate interface names in
>>> the view.
>>>
>>> I considered applying the changes to the network interface names
>>> immediately via `udevadm trigger`. Alternatively, I thought of adding
>>> the old names as altnames when pinning network interfaces, but not in a
>>> persistent manner. I think both would solve this state between
>>> transitioning from the old names to the new names. What do you think?
>>
>>
>> ok, so from what i can tell 'pveeth pin' writes directly into the /e/n/i
>> file?
>> shouldn't it write to /e/n/i.new file (or whatever it's named) so we
>> show it as pending change?
> 
> Currently yes, but I am still considering what would be the best way
> forward. I think you could make an argument for both. The problem is
> that while we have this mechanism of a temporary configuration file for
> /etc/network/interfaces and SDN, we do not have one for the firewall
> configuration. There is a dry_run functionality in pveeth, but it just
> generates the files in a different location.
> 
> It might make more sense to implement it as a two-step process:
> 
> * Pinning generates the new configuration files in the pending config of
> /e/n/i and SDN. For the firewall we'd have to create one as well and
> probably just handle this manually in the following step.
> 
> * Add another command that applies the temporary changes which would
> also include applying the changes via udevadm immediately.
> 
> Then users could inspect the generated changes via our UI (at least for
> Network / SDN). This would then also allow us to remove the dry_run
> functionality, since it would be implicitly included in this create /
> apply process. It would also solve the issue with this weird limbo state.
> 
> I'm just unsure on how we could integrate showing the changes to the FW
> configuration in a nice way.

mhmm on the spot i'd probably say we could color code the fw rule changes
(e.g. yellow for pending changed, red for pending removed, etc.)
maybe also a seperate column with that info as text/symbol
> 
>> then we could do the udevadm trigger in the 'apply config' api handler?
>>
>> also, basically the 'altname' lookup code would also have to lookup the
>> .link files ? (seems like it's a lot of work/disk reading to do?)
> 
> Yes, exactly - hence why I considered adding them as an altname since
> this would save us this procedure of parsing *all* link files in order
> to be able to generate a sensible view of /e/n/i.

ah ok, so you'd do 'ip link property add dev ensX altname nic0' ?
that way you could immediately add that too for the new name, no?

when you'd do that, we would not need to parse the link files
in the api code, since ip would already have that info ?


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH pve-manager v2 1/1] api/ui: show/return alternative interface names

[Stefan Hanreich]

On 7/15/25 12:33, Dominik Csapak wrote:
> On 7/15/25 11:41, Stefan Hanreich wrote:
>> On 7/15/25 11:30, Dominik Csapak wrote:
>>> On 7/15/25 11:21, Stefan Hanreich wrote:
>>>> Was formulating my response to v1, but you were too fast with sending a
>>>> v2 for me. I think we need to also consider the case where we pinned
>>>> and
>>>> replaced the names in /e/n/i via pveeth already, but the changes to the
>>>> network interface names haven't yet been applied. The problem here is
>>>> that we also return interfaces contained in /proc/net/dev in the
>>>> overview as well [1] - which would lead to duplicate interface names in
>>>> the view.
>>>>
>>>> I considered applying the changes to the network interface names
>>>> immediately via `udevadm trigger`. Alternatively, I thought of adding
>>>> the old names as altnames when pinning network interfaces, but not in a
>>>> persistent manner. I think both would solve this state between
>>>> transitioning from the old names to the new names. What do you think?
>>>
>>>
>>> ok, so from what i can tell 'pveeth pin' writes directly into the /e/n/i
>>> file?
>>> shouldn't it write to /e/n/i.new file (or whatever it's named) so we
>>> show it as pending change?
>>
>> Currently yes, but I am still considering what would be the best way
>> forward. I think you could make an argument for both. The problem is
>> that while we have this mechanism of a temporary configuration file for
>> /etc/network/interfaces and SDN, we do not have one for the firewall
>> configuration. There is a dry_run functionality in pveeth, but it just
>> generates the files in a different location.
>>
>> It might make more sense to implement it as a two-step process:
>>
>> * Pinning generates the new configuration files in the pending config of
>> /e/n/i and SDN. For the firewall we'd have to create one as well and
>> probably just handle this manually in the following step.
>>
>> * Add another command that applies the temporary changes which would
>> also include applying the changes via udevadm immediately.
>>
>> Then users could inspect the generated changes via our UI (at least for
>> Network / SDN). This would then also allow us to remove the dry_run
>> functionality, since it would be implicitly included in this create /
>> apply process. It would also solve the issue with this weird limbo state.
>>
>> I'm just unsure on how we could integrate showing the changes to the FW
>> configuration in a nice way.
> 
> mhmm on the spot i'd probably say we could color code the fw rule changes
> (e.g. yellow for pending changed, red for pending removed, etc.)
> maybe also a seperate column with that info as text/symbol

Yeah, I'll have to check how complicated that would be to implement -
particularly when the two firewall rulesets start to diverge. But having
a temporary firewall configuration similar to how /e/n/i or SDN works,
was something that we wanted to explore anyway - so that could actually
be a good starting point for that.

>>
>>> then we could do the udevadm trigger in the 'apply config' api handler?
>>>
>>> also, basically the 'altname' lookup code would also have to lookup the
>>> .link files ? (seems like it's a lot of work/disk reading to do?)
>>
>> Yes, exactly - hence why I considered adding them as an altname since
>> this would save us this procedure of parsing *all* link files in order
>> to be able to generate a sensible view of /e/n/i.
> 
> ah ok, so you'd do 'ip link property add dev ensX altname nic0' ?
> that way you could immediately add that too for the new name, no?
> 
> when you'd do that, we would not need to parse the link files
> in the api code, since ip would already have that info ?
> 

Yes, that was one of the solutions I had in mind, and that would be
quite convenient for that case if we do not immediately apply the changes.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH pve-manager v2 1/1] api/ui: show/return alternative interface names

[Thomas Lamprecht]

Am 15.07.25 um 13:06 schrieb Stefan Hanreich:
> On 7/15/25 12:33, Dominik Csapak wrote:
>> On 7/15/25 11:41, Stefan Hanreich wrote:
>>> On 7/15/25 11:30, Dominik Csapak wrote:
>>>> On 7/15/25 11:21, Stefan Hanreich wrote:
>>>>> Was formulating my response to v1, but you were too fast with sending a
>>>>> v2 for me. I think we need to also consider the case where we pinned
>>>>> and
>>>>> replaced the names in /e/n/i via pveeth already, but the changes to the
>>>>> network interface names haven't yet been applied. The problem here is
>>>>> that we also return interfaces contained in /proc/net/dev in the
>>>>> overview as well [1] - which would lead to duplicate interface names in
>>>>> the view.
>>>>>
>>>>> I considered applying the changes to the network interface names
>>>>> immediately via `udevadm trigger`. Alternatively, I thought of adding
>>>>> the old names as altnames when pinning network interfaces, but not in a
>>>>> persistent manner. I think both would solve this state between
>>>>> transitioning from the old names to the new names. What do you think?
>>>>
>>>>
>>>> ok, so from what i can tell 'pveeth pin' writes directly into the /e/n/i
>>>> file?
>>>> shouldn't it write to /e/n/i.new file (or whatever it's named) so we
>>>> show it as pending change?
>>>
>>> Currently yes, but I am still considering what would be the best way
>>> forward. I think you could make an argument for both. The problem is
>>> that while we have this mechanism of a temporary configuration file for
>>> /etc/network/interfaces and SDN, we do not have one for the firewall
>>> configuration. There is a dry_run functionality in pveeth, but it just
>>> generates the files in a different location.
>>>
>>> It might make more sense to implement it as a two-step process:
>>>
>>> * Pinning generates the new configuration files in the pending config of
>>> /e/n/i and SDN. For the firewall we'd have to create one as well and
>>> probably just handle this manually in the following step.
>>>
>>> * Add another command that applies the temporary changes which would
>>> also include applying the changes via udevadm immediately.
>>>
>>> Then users could inspect the generated changes via our UI (at least for
>>> Network / SDN). This would then also allow us to remove the dry_run
>>> functionality, since it would be implicitly included in this create /
>>> apply process. It would also solve the issue with this weird limbo state.
>>>
>>> I'm just unsure on how we could integrate showing the changes to the FW
>>> configuration in a nice way.

but what changes are there required if it's _transparent_ altname support?

While pending changes for FW might be nice in general, it ideally should
not be a require prerequisite for this effort now.
>> mhmm on the spot i'd probably say we could color code the fw rule changes
>> (e.g. yellow for pending changed, red for pending removed, etc.)
>> maybe also a seperate column with that info as text/symbol
> 
> Yeah, I'll have to check how complicated that would be to implement -
> particularly when the two firewall rulesets start to diverge. But having
> a temporary firewall configuration similar to how /e/n/i or SDN works,
> was something that we wanted to explore anyway - so that could actually
> be a good starting point for that.
> 
>>>
>>>> then we could do the udevadm trigger in the 'apply config' api handler?
>>>>
>>>> also, basically the 'altname' lookup code would also have to lookup the
>>>> .link files ? (seems like it's a lot of work/disk reading to do?)
>>>
>>> Yes, exactly - hence why I considered adding them as an altname since
>>> this would save us this procedure of parsing *all* link files in order
>>> to be able to generate a sensible view of /e/n/i.
>>
>> ah ok, so you'd do 'ip link property add dev ensX altname nic0' ?
>> that way you could immediately add that too for the new name, no?
>>
>> when you'd do that, we would not need to parse the link files
>> in the api code, since ip would already have that info ?
>>
> 
> Yes, that was one of the solutions I had in mind, and that would be
> quite convenient for that case if we do not immediately apply the changes.
before I forget it, lets not name the executable "pveeth", that's hard
to read and it includes an outdated legacy named for NICs "eth" that's
basically burned for being used as pinned names.

For now it would be probably best to name it in a rather specific way,
in the mid term we might get a common tool shared across products to
provide basic network status/config edit support, but until then I'd
not suggest that this evolves in some general network interface handling.

Could be as verbose as:
proxmox-network-interface-pinning

Less verbose but shorter:
proxmox-iface-pin

And then probably have two commands for preparing the pinning for one or
more interface and for applying the prepared changes.
As I'd find it very odd if I–as user–could create the preparation for
pinning here, but then would need to login on the web ui to apply
that on the various panels (in what order?!).
And ideally firewall and SDN handles this transparently, so it doesn't
matter if that configs get changed for the common case.



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH pve-manager v2 1/1] api/ui: show/return alternative interface names

[Stefan Hanreich]

On 7/15/25 14:36, Thomas Lamprecht wrote:
> Am 15.07.25 um 13:06 schrieb Stefan Hanreich:
>> On 7/15/25 12:33, Dominik Csapak wrote:
>>> On 7/15/25 11:41, Stefan Hanreich wrote:
>>>> On 7/15/25 11:30, Dominik Csapak wrote:
>>>>> On 7/15/25 11:21, Stefan Hanreich wrote:
>>>>>> Was formulating my response to v1, but you were too fast with sending a
>>>>>> v2 for me. I think we need to also consider the case where we pinned
>>>>>> and
>>>>>> replaced the names in /e/n/i via pveeth already, but the changes to the
>>>>>> network interface names haven't yet been applied. The problem here is
>>>>>> that we also return interfaces contained in /proc/net/dev in the
>>>>>> overview as well [1] - which would lead to duplicate interface names in
>>>>>> the view.
>>>>>>
>>>>>> I considered applying the changes to the network interface names
>>>>>> immediately via `udevadm trigger`. Alternatively, I thought of adding
>>>>>> the old names as altnames when pinning network interfaces, but not in a
>>>>>> persistent manner. I think both would solve this state between
>>>>>> transitioning from the old names to the new names. What do you think?
>>>>>
>>>>>
>>>>> ok, so from what i can tell 'pveeth pin' writes directly into the /e/n/i
>>>>> file?
>>>>> shouldn't it write to /e/n/i.new file (or whatever it's named) so we
>>>>> show it as pending change?
>>>>
>>>> Currently yes, but I am still considering what would be the best way
>>>> forward. I think you could make an argument for both. The problem is
>>>> that while we have this mechanism of a temporary configuration file for
>>>> /etc/network/interfaces and SDN, we do not have one for the firewall
>>>> configuration. There is a dry_run functionality in pveeth, but it just
>>>> generates the files in a different location.
>>>>
>>>> It might make more sense to implement it as a two-step process:
>>>>
>>>> * Pinning generates the new configuration files in the pending config of
>>>> /e/n/i and SDN. For the firewall we'd have to create one as well and
>>>> probably just handle this manually in the following step.
>>>>
>>>> * Add another command that applies the temporary changes which would
>>>> also include applying the changes via udevadm immediately.
>>>>
>>>> Then users could inspect the generated changes via our UI (at least for
>>>> Network / SDN). This would then also allow us to remove the dry_run
>>>> functionality, since it would be implicitly included in this create /
>>>> apply process. It would also solve the issue with this weird limbo state.
>>>>
>>>> I'm just unsure on how we could integrate showing the changes to the FW
>>>> configuration in a nice way.
> 
> but what changes are there required if it's _transparent_ altname support?

We would refer to the newly generated, pinned, names then in the
configuration files.

> While pending changes for FW might be nice in general, it ideally should
> not be a require prerequisite for this effort now.

Agree, that would too short notice to implement properly imo.

>>> mhmm on the spot i'd probably say we could color code the fw rule changes
>>> (e.g. yellow for pending changed, red for pending removed, etc.)
>>> maybe also a seperate column with that info as text/symbol
>>
>> Yeah, I'll have to check how complicated that would be to implement -
>> particularly when the two firewall rulesets start to diverge. But having
>> a temporary firewall configuration similar to how /e/n/i or SDN works,
>> was something that we wanted to explore anyway - so that could actually
>> be a good starting point for that.
>>
>>>>
>>>>> then we could do the udevadm trigger in the 'apply config' api handler?
>>>>>
>>>>> also, basically the 'altname' lookup code would also have to lookup the
>>>>> .link files ? (seems like it's a lot of work/disk reading to do?)
>>>>
>>>> Yes, exactly - hence why I considered adding them as an altname since
>>>> this would save us this procedure of parsing *all* link files in order
>>>> to be able to generate a sensible view of /e/n/i.
>>>
>>> ah ok, so you'd do 'ip link property add dev ensX altname nic0' ?
>>> that way you could immediately add that too for the new name, no?
>>>
>>> when you'd do that, we would not need to parse the link files
>>> in the api code, since ip would already have that info ?
>>>
>>
>> Yes, that was one of the solutions I had in mind, and that would be
>> quite convenient for that case if we do not immediately apply the changes.
> before I forget it, lets not name the executable "pveeth", that's hard
> to read and it includes an outdated legacy named for NICs "eth" that's
> basically burned for being used as pinned names.
> 
> For now it would be probably best to name it in a rather specific way,
> in the mid term we might get a common tool shared across products to
> provide basic network status/config edit support, but until then I'd
> not suggest that this evolves in some general network interface handling.
> 
> Could be as verbose as:
> proxmox-network-interface-pinning
> 
> Less verbose but shorter:
> proxmox-iface-pin

Fine with me, pveeth was more of a placeholder anyway.

> And then probably have two commands for preparing the pinning for one or
> more interface and for applying the prepared changes.
> As I'd find it very odd if I–as user–could create the preparation for
> pinning here, but then would need to login on the web ui to apply
> that on the various panels (in what order?!).
> And ideally firewall and SDN handles this transparently, so it doesn't
> matter if that configs get changed for the common case.

See my post on the other thread for the pinning tool itself where I
basically propose something like that.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH pve-manager v2 1/1] api/ui: show/return alternative interface names

[Thomas Lamprecht]

Am 15.07.25 um 15:08 schrieb Stefan Hanreich:
> On 7/15/25 14:36, Thomas Lamprecht wrote:
>> but what changes are there required if it's _transparent_ altname support?
> 
> We would refer to the newly generated, pinned, names then in the
> configuration files.

That can be done when serializing those out the next time they get
written though? IMO there's not much benefit for adding such a big
churn, that's only asking for trouble with no advantage for all users
that do not manually edit the firewall rule (or SDN) configs, and
that would still work, it just might be slightly confusing at first;
but the latter can be defused by mentioning this explicitly, e.g. in
documentation about pinning and maybe a CLI stdout message in the tool.


>> And then probably have two commands for preparing the pinning for one or
>> more interface and for applying the prepared changes.
>> As I'd find it very odd if I–as user–could create the preparation for
>> pinning here, but then would need to login on the web ui to apply
>> that on the various panels (in what order?!).
>> And ideally firewall and SDN handles this transparently, so it doesn't
>> matter if that configs get changed for the common case.
> 
> See my post on the other thread for the pinning tool itself where I
> basically propose something like that.

Thanks for the pointer.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH pve-manager v2 1/1] api/ui: show/return alternative interface names

[Stefan Hanreich]

On 7/15/25 15:15, Thomas Lamprecht wrote:
> Am 15.07.25 um 15:08 schrieb Stefan Hanreich:
>> On 7/15/25 14:36, Thomas Lamprecht wrote:
>>> but what changes are there required if it's _transparent_ altname support?
>>
>> We would refer to the newly generated, pinned, names then in the
>> configuration files.
> 
> That can be done when serializing those out the next time they get
> written though? IMO there's not much benefit for adding such a big
> churn, that's only asking for trouble with no advantage for all users
> that do not manually edit the firewall rule (or SDN) configs, and
> that would still work, it just might be slightly confusing at first;
> but the latter can be defused by mentioning this explicitly, e.g. in
> documentation about pinning and maybe a CLI stdout message in the tool.

But if the (alt-)name of the NIC changes in the meanwhile and the
configuration doesn't get written inbetween, how would we ever be able
to infer which NIC was initially referenced in the configuration file?
Isn't this the exact case we're trying to solve with pinning? Or am I
misunderstanding something here?


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] applied: [PATCH pve-manager v2 1/1] api/ui: show/return alternative interface names

[Thomas Lamprecht]

On Tue, 15 Jul 2025 11:07:49 +0200, Dominik Csapak wrote:
> in api listing for all interfaces, and in the GET call for an individual
> interface.
> 
> For intefaces that are already using an 'altname' in the iface stanza,
> we look up the 'legacy' interface name and the remaining altnames and
> show those.
> 
> [...]

Applied, thanks!

[1/1] api/ui: show/return alternative interface names


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel