Bug 1283489 - ERROR: duplicate key value when calling setupNetworks
ERROR: duplicate key value when calling setupNetworks
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
x86_64 Linux
urgent Severity urgent
: ovirt-3.6.z-async
: ---
Assigned To: Alona Kaplan
Michael Burman
: Reopened, ZStream
Depends On:
Blocks: 1430513
  Show dependency treegraph
Reported: 2015-11-19 01:56 EST by Meni Yakove
Modified: 2017-09-14 14:32 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-09-14 14:32:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
myakove: testing_plan_complete+

Attachments (Terms of Use)
engine logs (895.47 KB, application/x-bzip)
2015-11-19 01:56 EST, Meni Yakove
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 80840 ovirt-engine-3.6 MERGED engine: Expanding monitoring lock to the whole setup networks command 2017-08-28 06:41 EDT

  None (edit)
Description Meni Yakove 2015-11-19 01:56:06 EST
Created attachment 1096501 [details]
engine logs

Description of problem:
Sometimes when calling setupNetwork the operation fails with error:
CallableStatementCallback; SQL [{call insertnetworkattachment(?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: duplicate key value violates unique constraint "network_attachments_network_id_key"

Version-Release number of selected component (if applicable):

Steps to Reproduce:
1. Run tier1 network automation test

Additional info:
Correlation-Id: labels_create_9c0a7b3d-eeb5-4b0e (for engine.log)
Comment 1 Yaniv Kaul 2015-11-20 03:02:57 EST
Meni - why is the severity high? What is the frequency and what is the scenario? Sometimes is not clear enough.
Comment 2 Meni Yakove 2015-11-25 05:13:37 EST
lower the severity to low since it's happened only few time (about 2-3 times for about 500 setupNetworks)
Comment 3 Meni Yakove 2016-02-01 07:54:14 EST
Not reproduced anymore.
Comment 6 Dan Kenigsberg 2017-08-15 06:36:12 EDT
We are trying to understand why the customer sees these exception.

However, it is important to note right now that when a freshly-built el7 node is added to a cluster with required networks it is *expected* to become non-operational. When a host is added, only the management network is attached to it by default. Further networks have to be attached explicitly via nics or label. If the cluster two which the host is added has multiple required networks, having the management network is not enough and the host becomes non-operational.
Comment 7 Alona Kaplan 2017-08-16 03:18:28 EDT
Looking at the attached log and the db dump in the SOS report I can see that the installation of the host failed due to a race.
The host was refreshed by the vdsManager during the run of HostSetupNetworkCommand.
This issue was fixed in patch https://gerrit.ovirt.org/#/c/59318/9 (bug https://bugzilla.redhat.com/1324479). The fix was introduced in 4.0.
Comment 8 Dan Kenigsberg 2017-08-16 03:40:01 EDT
Based on comment 7, I believe that it would be possible to backport the fix to 3.6, but it would not be fun.

How disruptive is this bug for the customer? Would they want to upgrade to a hot-fixed rhvm-3.6.12 in order to avoid it? Or can they keep a stiff upper lip until their VM compatibility level is 3.6, and they can upgrade to rhvm-4 ?
Comment 18 Michael Burman 2017-08-23 02:12:54 EDT
Why the target milestone is 4.2?
Comment 23 Michael Burman 2017-09-07 02:29:05 EDT
Verified on - 3.6.12-0.1.el6
Comment 24 Emma Heftman 2017-09-14 10:51:43 EDT
Comment 26 errata-xmlrpc 2017-09-14 14:32:30 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.


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