Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1430799 - Create script to restore original network configuration of removed vdsm host
Create script to restore original network configuration of removed vdsm host
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
4.1.0
Unspecified Unspecified
medium Severity low
: ovirt-4.2.0
: 4.2.0
Assigned To: Petr Horáček
Michael Burman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-03-09 10:44 EST by Jiri Belka
Modified: 2018-05-15 13:52 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
vdsm-tool now provides commands for VDSM network cleanup, such as `vdsm-tool clear-nets` and `vdsm-tool dummybr-remove`. You can remove networks configured by VDSM following the steps below. Note that the VDSM service does not need to be running: 1. To prevent loss of connectivity, it might be necessary to exclude the default route network from the cleanup. Look for a network providing the default route (ovirtmgmt by default): # vdsm-tool list-nets ... ovirtmgmt (default route) ... 2. Remove all networks configured by VDSM except for the default network: # vdsm-tool clear-nets --exclude-net ovirtmgmt 3. Remove the libvirt dummy bridge ;vdsmdummy; # vdsm-tool dummybr-remove 4. Now that the host is clean, you can remove VDSM.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-05-15 13:50:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 79495 master MERGED tool: list/clear networks configured by VDSM 2017-08-04 03:02 EDT
oVirt gerrit 79596 master MERGED tool: remove dummy bridge 2017-08-05 01:31 EDT
Red Hat Product Errata RHEA-2018:1489 None None None 2018-05-15 13:52 EDT

  None (edit)
Description Jiri Belka 2017-03-09 10:44:35 EST
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:
Comment 1 Yaniv Lavi 2017-03-14 08:51:16 EDT
Do you have a flow to share on how to do this?
Comment 2 Yaniv Lavi 2017-03-23 03:49:03 EDT
Who can help us with getting this content?
Comment 3 Dan Kenigsberg 2017-03-23 15:57:56 EDT
Petr, please provide a script to remove all vdsm networks (apart of one, ovirtmgmt).
Comment 5 Edward Haas 2017-07-20 09:48:32 EDT
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.
Comment 6 rhev-integ 2017-11-02 09:40:23 EDT
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@redhat.com
Comment 7 Michael Burman 2017-11-20 08:05:01 EST
Verified on - vdsm-4.20.7-37.gitfb0d1c3.el7.centos.x86_64
Comment 12 errata-xmlrpc 2018-05-15 13:50:23 EDT
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

Note You need to log in before you can comment on or make changes to this bug.