Bug 987285 - [vdsm] SetupNetwork failure on ifup doesn't rollback network from libvirt
[vdsm] SetupNetwork failure on ifup doesn't rollback network from libvirt
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
3.3.0
Unspecified Unspecified
unspecified Severity high
: ---
: 3.3.0
Assigned To: Antoni Segura Puimedon
Meni Yakove
network
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-23 03:24 EDT by Moti Asayag
Modified: 2016-02-10 14:50 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-23 07:31:31 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)
vdsm.log (895.62 KB, text/x-log)
2013-07-23 03:24 EDT, Moti Asayag
no flags Details
supervdsm.log (7.75 KB, text/x-log)
2013-07-23 03:25 EDT, Moti Asayag
no flags Details

  None (edit)
Description Moti Asayag 2013-07-23 03:24:59 EDT
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:
Comment 1 Moti Asayag 2013-07-23 03:25:45 EDT
Created attachment 777199 [details]
supervdsm.log
Comment 2 Antoni Segura Puimedon 2013-09-18 04:34:45 EDT
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.
Comment 3 Moti Asayag 2013-09-23 07:31:31 EDT
(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.

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