Skip to content

xe-reset-networking: Allow the user to perform a network reset without renaming the management interface #6852

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sgerag wants to merge 2 commits into
base: master
Choose a base branch
from
Open

xe-reset-networking: Allow the user to perform a network reset without renaming the management interface #6852

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
61cab92
xe-reset-networking: allow the user to perform a network reset without
sgerag Jan 14, 2026
693cee0
Replace the parameter name and consequently revert the logic (details…
sgerag Jan 27, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions python3/bin/xe-reset-networking
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -91,6 +91,7 @@ if __name__ == "__main__":
parser.add_option("--gateway", help="Gateway for new management interface", dest="gateway", default='')
parser.add_option("--gateway-v6", help="IPv6 Gateway for new management interface", dest="gateway_v6", default='')
parser.add_option("--dns", help="DNS server for new management interface", dest="dns", default='')
parser.add_option("--reset-interface-name-rules", help="Reset the management interface name", dest="reset_interface_name_rules", action="store_const", const=True, default=True)
Copy link
Contributor

@changlei-li changlei-li Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
parser.add_option("--reset-interface-name-rules", help="Reset the management interface name", dest="reset_interface_name_rules", action="store_const", const=True, default=True)
parser.add_option("--reset-interface-name-rules", help="Reset the interface name rules to the install-time configuration (with interface-rename.py only)", dest="reset_interface_name_rules", action="store_const", const=True, default=True)

(options, args) = parser.parse_args()

# Determine pool role
Expand Down Expand Up @@ -174,6 +175,10 @@ if __name__ == "__main__":
if not os.access('/tmp/fist_network_reset_no_warning', os.F_OK):
configuration = []
configuration.append("Management interface: " + device)
if not options.reset_interface_name_rules:
configuration.append("Rename interface: Yes")
else:
configuration.append("Rename interface: No")
Copy link
Contributor

@changlei-li changlei-li Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
configuration.append("Rename interface: No")
if options.reset_interface_name_rules:
configuration.append("Reset interface name rules: Yes")
else:
configuration.append("Reset interface name rules: No")

configuration.append("IP configuration mode: " + options.mode)
configuration.append("IPv6 configuration mode:" + options.mode_v6)
if vlan != None:
Expand Down Expand Up @@ -288,8 +293,9 @@ Type 'no' to cancel.
if rename_script_exists:
# Reset the domain 0 network interface naming configuration
# back to a fresh-install state for the currently-installed
# hardware.
os.system(f"{RENAME_SCRIPT} --reset-to-install")
# hardware (unless prevented by the user).
if not options.reset_interface_name_rules:
Copy link
Contributor

@changlei-li changlei-li Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if not options.reset_interface_name_rules:
if options.reset_interface_name_rules:

os.system(f"{RENAME_SCRIPT} --reset-to-install")
Copy link
Contributor

@changlei-li changlei-li Jan 23, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This script already deletes networkd.db, writes new management.conf, update inventory file. And create /var/tmp/network-reset to trigger XAPI check_network_reset after reboot. While management interface is determined by LABEL in the management conf.
I think interface-rename --reset-to-install just cover the static/dynamic rule from the original backup rule files. I am not clear how it affects the management interface name.
Could you give an example? Thank you.

Copy link
Author

@sgerag sgerag Jan 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I understand 100% the question. Based on my understanding and the testing I have done, --device (essentially LABEL) points to the management interface.

Currently, the management network interface will be renamed back to what it would have been if a fresh installation was to be performed. However, for some use cases, the user might have already renamed the interface and would like to prevent the renaming when doing xe-reset-networking.

If you mean something different and I can help somehow, please let me know.

Copy link
Contributor

@changlei-li changlei-li Jan 26, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to have a better understand of the issue. Can you show the use case in detail? How does the user rename the interface? Does it change the interface-rename-data/static-rules.conf manually or using interface-rename.py --update?
My concern is

  1. Is the option name proper? I can't understand the relation between keep interface name and skip interface-rename --reset-to-install easily.
  2. It is obvious that it is just an option with interface-rename and not applied for the new interfaces sorting introduced in networkd recently. I wonder if it can only go to 26.1-lcm (I don't insist)

Copy link
Author

@sgerag sgerag Jan 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example, we had a user with a host which had interfaces with certain names that needed to be renamed to be part of a bond interface before joining an XCP-ng pool. They renamed the relevant interface by using interface-rename --update. This naming was needed to be preserved when performing an emergency network reset.

Also, others report that renaming is some times useful to retain consistency across the hosts in the same pool.

2. It is obvious that it is just an option with interface-rename and not applied for the new interfaces sorting introduced in networkd recently. I wonder if it can only go to 26.1-lcm (I don't insist)

Hmm, I don't have a strong opinion.

Copy link
Contributor

@changlei-li changlei-li Jan 27, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. I understand the issue now.
Then there is the last minor point: I suggest using --reset-interface-name-rules (default True) which is clearer. If you accept the name, the help and log should be updated too.

Copy link
Author

@sgerag sgerag Jan 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Let me know if the (force-pushed) log message is ok.

Btw,I noticed (Python 3.6.8) an unexpected behavior that is related with parameters that contain any dashes, most probably related to parse_args(). For example, if the user passes --mode-v (without 6) or --reset-inter, then there is no error and the script proceeds. The following parameters are affected: --mode-v6, --gateway-v6, --reset-interface-name-rules.

This is obviously part of another discussion, but if we want to avoid this behavior for this parameter with a quick fix, we can use a name without dashes. Let me know your thoughts.

Copy link
Contributor

@changlei-li changlei-li Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah there are some errors in the new commit.
Let me state it clearer:

  • What does interface-rename script do?
    Sort and rename the interfaces to ethN.
  • What does the interface-rename --reset-to-install do?
    Copy the interface-rename-data/.from_install/static(and dynamic)-rules.conf to interface-rename-data/ to reset the rules to the content when the host is installed.
  • What does the static-rules.conf do?
    Its content is like eth0:mac="6c:92:cf:2f:ca:60" , eth1:mac="6c:92:cf:2f:ca:61" which is passed by host-installer that shows the user defined mapping of interface mac and interface name. interface-rename will take the rule in priority. While interface-rename --update provides a method to modify it.
  • What is the difference of new introduced networkd sorting?
    The new introduced networkd sorting start to work if interface-rename is dropped on the host. The mapping rule passed by host-installer is stored at initial_rules_file_path. Now no direct mechanism to update it and so there is no the issue to determine if the mapping rules need to restored from install.

Based on this, I suggest the option name reset-interface-name-rules. If the user has updated the rules file, it should be a clear option name.
If we are on the same stage, I think

  1. help description Reset the management interface name is misleading. Maybe the mapping rules doesn't contain the management interface.
  2. The log Rename interface: Yes. Rename interface here is hard to understand
  3. The logic is wrong.

Copy link
Contributor

@changlei-li changlei-li Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the args parse, I think it is not urgent. It's legacy behavior and there is a message with all the configurations to be confirmed by the user.

Copy link
Author

@sgerag sgerag Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation.

Not sure we are on the same page. Although I get your description on the path forward, to be honest, I am not really aware of how the transition for the new networkd will take place in relation to e.g. network reset. If I get it correctly, xe-reset-networking will stop working (due to the absence of interface-rename) after that transition, right?

All in all, my original commit was about providing the user the ability to prevent resetting the interface name in the current (pre-transition) state. On your side you suggest to port this ability to the new state, correct? If so, maybe it is better to merge the initial PR to the "old" codebase (as you initially suggested) and maybe proceed afterwards with another PR to port it to the "new" codebase.

Copy link
Contributor

@changlei-li changlei-li Jan 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

xe-reset-networking also wok in new networkd sorting with absence of interface-rename. But your new added option doesn't work. So I add with interface-rename.py only in the option help.
For xapi itself, it supports interface-rename or new networkd sorting with absence of interface-rename, no matter the old or new code base. It's OK into master and back port.
For the new networkd sorting, we can leave it to the future. I am not sure if we need update and restore mapping rules in the new networkd sorting feature, because the interface name is not ethN in the feature. I point it out just for background. Sorry for confusing you. You can ignore what I say about the new networkd sorting.
We can just focus on the interface-rename part in this PR.


# Reboot
os.system("mount -o remount,rw / && reboot -f")