Description of problem: Document how to restore original network configuration of removed vdsm host. Why? One could add a host into engine and one minute later decide to remove it. But the host would have ovirtmgmt bridge and various vdsm network hacks which are not clear how to remove. So let's document how to "clear" previously used host from vdsm network configuration. (For example I see vdsm put some things in /etc/dhcp/dhclient.d/sourceRoute.sh, it configured libvirt and who knows where it is still kept.) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. add a host into engine 2. remove host into engine 3. read docs to know how to de-vdsmize the host from its network changes 4. follow docs' steps to put back previous configuration 5. restart network (systemctl restart network) 6. does network work? check if there's ovirtmgmt bridge or previously used ifaces Actual results: it's magic to "clear" a host after removal Expected results: should be readable and understandable Additional info:
Do you have a flow to share on how to do this?
Who can help us with getting this content?
Petr, please provide a script to remove all vdsm networks (apart of one, ovirtmgmt).
Just to clarify, we will not be able to restore the node to the "original" state, for that we need to "remember" the original state, which we do not. The suggested "cleaning" may even be wrong, as it may remove acquired configuration (like pre existing bridges, bonds, IP/s.. etc). If we bring NM in the picture, after this "cleaning", it will not control the previously acquired devices, manual intervention is needed to do so. I guess the documentation needs to reflect all this, suggests way to continue manually patching things after the "automatic" step is finished.
INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [No relevant external trackers attached] For more info please contact: rhv-devops
Verified on - vdsm-4.20.7-37.gitfb0d1c3.el7.centos.x86_64
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:1489
BZ<2>Jira Resync