Created attachment 777198 [details] vdsm.log Description of problem: When setupNetworks fails to configure network on the host due to ifup failure, vdsm doesn't rollback the changes done to libvirt and the network remains on libvirt, causing next attempt to configure the network to fails with 'network already exists'. In addition, the failure appears on supervdsm.log, however the failure doesn't reflected to vdsm.log. Version-Release number of selected component (if applicable): vdsm-4.12.0-rc2.5.git980ca1a.fc18.x86_64 libvirt-1.0.5.2-1.fc19.x86_64 How reproducible: always. Steps to Reproduce: 1. Add a network with setupNetwork on fedora 19, when NetworkManager service is running. Actual results: VDSM reverts the new network configuration from the initscripts but leaves the new network configuration on libvirt. Expected results: The atomicity of the action should be kept: vdsm should clear the network definition from libvirt as well. Additional info:
Created attachment 777199 [details] supervdsm.log
After studying the logs, one can see, in supervdsm.log, that the addNetwork process backs up a previously existing ovirtmgmt network (the same network name that was being added) with content: MainProcess|Thread-16::DEBUG::2013-07-22 17:44:40,294::ifcfg::252::root::(_persistentNetworkBackup) backing up network ovirtmgmt: <network> <name>vdsm-ovirtmgmt</name> <uuid>b87a7656-6aa0-45f0-b326-528f54ceff21</uuid> <forward mode='bridge'/> <bridge name='ovirtmgmt' /> </network> This goes on to show that the ovirtmgmt network that was subject of the setupNetworks command was a pre-existing bridged network and that is what in the end we rolled back to. According to that, I'm inclined to say that there was just old configuration remaining and that due to that, the events shown in the logs can't be considered to expose a bug.
(In reply to Antoni Segura Puimedon from comment #2) > After studying the logs, one can see, in supervdsm.log, that the addNetwork > process backs up a previously existing ovirtmgmt network (the same network > name that was being added) with content: > MainProcess|Thread-16::DEBUG::2013-07-22 > 17:44:40,294::ifcfg::252::root::(_persistentNetworkBackup) backing up > network ovirtmgmt: <network> > <name>vdsm-ovirtmgmt</name> > <uuid>b87a7656-6aa0-45f0-b326-528f54ceff21</uuid> > <forward mode='bridge'/> > <bridge name='ovirtmgmt' /> > </network> > This goes on to show that the ovirtmgmt network that was subject of the > setupNetworks command was a pre-existing bridged network and that is what in > the end we rolled back to. > > According to that, I'm inclined to say that there was just old configuration > remaining and that due to that, the events shown in the logs can't be > considered > to expose a bug. Attempt to reproduce this bug with a fresh f19 copy failed. Therefore I'm closing this bug.