Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1669464

Summary: [OVS] Host network out of sync after adding DNS to logical network ovirtmgmt
Product: [oVirt] ovirt-engine Reporter: Netbulae <info>
Component: BLL.NetworkAssignee: Ales Musil <amusil>
Status: CLOSED CURRENTRELEASE QA Contact: Michael Burman <mburman>
Severity: low Docs Contact:
Priority: unspecified    
Version: 4.3.0CC: amusil, bugs, dholler
Target Milestone: ovirt-4.4.3Flags: pm-rhel: ovirt-4.4+
pm-rhel: ovirt-4.5?
dholler: devel_ack+
mburman: testing_ack+
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-11 06:39:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1195208    
Attachments:
Description Flags
server.log with JDBC errors
none
engine.log none

Description Netbulae 2019-01-25 11:15:24 UTC
Created attachment 1523492 [details]
server.log with JDBC errors

Description of problem:

We have a second OVS ovirtmgmt network for our new cluster, when I set the DNS servers on this logical network the interface becomes out of sync.

It doesn't matter if I set the DNS for the logical network or only for the specific hosts. Same results.

The hosts says everything ok:

2019-01-25 11:10:44,436+0100 INFO  (periodic/3) [vdsm.api] FINISH repoStats return={} from=internal, task_id=d82a7cdc-6022-4879-a837-e696646a74df (api:54)
2019-01-25 11:10:46,608+0100 INFO  (jsonrpc/7) [api.network] START setupNetworks(networks={u'ovirtmgmt-OVS': {u'ipv6autoconf': True, u'nameservers': [u'*.*.*.*', u'*.*.*.*'], u'ipaddr': u'*.*.*.*', u'bonding': u'bond0', u'mtu': 1500, u'switch': u'ovs', u'netmask': u'255.255.255.0', u'dhcpv6': False, u'bridged': u'false', u'gateway': u'*.*.*.*', u'defaultRoute': True}}, bondings={}, options={u'connectivityCheck': u'true', u'connectivityTimeout': 120, u'commitOnSuccess': True}) from=::ffff:*.*.*.*2,56050 (api:48)
2019-01-25 11:10:46,626+0100 INFO  (jsonrpc/6) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:10:47,145+0100 INFO  (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:10:47,659+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:10:48,172+0100 INFO  (jsonrpc/5) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:10:48,678+0100 INFO  (jsonrpc/2) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:11:15,366+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:11:15,366+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:11:15,366+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:11:15,366+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:11:15,367+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:11:15,367+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:11:15,367+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.01 seconds (__init__:312)
2019-01-25 11:11:15,367+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:11:15,368+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:11:15,368+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:11:15,368+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)
2019-01-25 11:11:16,063+0100 INFO  (jsonrpc/7) [api.network] FINISH setupNetworks return={'status': {'message': 'Done', 'code': 0}} from=::ffff:*.*.*.*2,56050 (api:54)
2019-01-25 11:11:16,063+0100 INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC call Host.setupNetworks succeeded in 29.45 seconds (__init__:312)
2019-01-25 11:11:16,732+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.confirmConnectivity succeeded in 0.00 seconds (__init__:312)

But on the engine I see JDBC errors in the server.log and JsonRpc errors in engine.log

2019-01-25 11:11:09,216+01 INFO  [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] No interaction with host 'node12.netbulae.internal' for 20000 ms.
2019-01-25 11:11:15,371+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "72d492c2-83b3-4a03-8186-16d5c503de55" result: true>
2019-01-25 11:11:15,371+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "24de8e1b-756b-422f-967c-3bf7f7d947b8" result: true>
2019-01-25 11:11:15,400+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "319c8a8f-f846-413c-a919-e218d1dc087d" result: true>
2019-01-25 11:11:15,400+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "47746430-e421-4f1b-8162-7a705ac126b3" result: true>
2019-01-25 11:11:15,902+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "ed3e3159-9aed-4edf-8241-15881b909e80" result: true>
2019-01-25 11:11:16,064+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "70b0713c-80ab-4f64-b6da-7c65db0625bf" result: true>
2019-01-25 11:11:16,420+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "79c476b6-ba11-4eb3-a87f-c36f199965f3" result: true>
2019-01-25 11:11:16,554+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "8f0cab83-f9aa-474f-a172-12e460e7571a" result: true>
2019-01-25 11:11:16,554+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "29cc4a61-84e7-494b-97c6-d87e8381cf2c" result: true>
2019-01-25 11:11:16,555+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "cf1789f3-fcd6-4992-bcc5-cbb7167b69d5" result: true>
2019-01-25 11:11:16,555+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "dd1808fe-0275-45ae-a70d-7ad92f2a6ca8" result: true>
2019-01-25 11:11:16,644+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "ee577e45-3d9b-4f22-86f5-554a1b21305a" result: true>
2019-01-25 11:11:16,645+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "a6a13b40-71ea-4100-92c7-d970edcf7daa" result: true>
2019-01-25 11:11:16,645+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "ebad86f8-9685-4917-8991-7636b48247ae" result: true>
2019-01-25 11:11:16,651+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "8bc2eccd-5c04-4a57-be5c-1803077e3850" result: true>
2019-01-25 11:11:16,651+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "52114b07-9efc-4dd8-8bd4-ba310126985c" result: true>
2019-01-25 11:11:16,651+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "8b236e7e-ffb7-4d1f-a68d-c04599f4ddc0" result: true>
2019-01-25 11:11:16,652+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "ceaf391e-7d44-4ff5-81b0-04c65461ad8d" result: true>
2019-01-25 11:11:16,652+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "221ccbca-de49-47e4-a333-2d991d1a48c7" result: true>
2019-01-25 11:11:16,732+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "af26353f-6fc2-4d83-be69-b38bda794675" result: true>
2019-01-25 11:11:16,732+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "d630ce78-da53-40ee-938c-84cb6222e094" result: true>
2019-01-25 11:11:16,733+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "da1f0d41-f9c6-4f97-8e0b-0c817524604d" result: true>
2019-01-25 11:11:16,735+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "5262fe29-560a-41ec-afba-af5f383c377d" result: true>
2019-01-25 11:11:16,735+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "4688c862-a19e-4af3-bd9f-057a58d42972" result: true>
2019-01-25 11:11:16,736+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "36205791-1017-4950-95a5-2590b9a4cb9d" result: true>
2019-01-25 11:11:16,939+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "79bc5c6f-0145-4934-8b4a-ffa7e2b4610b" result: true>
2019-01-25 11:11:16,939+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "b4c25b14-fadb-4162-af71-99dafcae3ce4" result: true>
2019-01-25 11:11:16,939+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "d031d10e-bb6a-4da2-bce7-e0a95b362df6" result: true>
2019-01-25 11:11:16,939+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "48df4700-f0b7-4c9b-a486-9d3e2801ea08" result: true>
2019-01-25 11:11:16,939+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "5105e73b-d8de-45a0-b857-9423641a2a23" result: true>
2019-01-25 11:11:16,939+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "611f47af-81c2-45df-a5a4-c4a76b9a7333" result: true>
2019-01-25 11:11:17,109+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "5472b5dd-6f45-4a06-93dc-31d28bb1d987" result: true>
2019-01-25 11:11:17,109+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "564664c4-ad2a-4948-9397-ef78fa66c72e" result: true>
2019-01-25 11:11:17,452+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "c9a76dfd-77ce-42dd-afc0-c970131a36a4" result: true>
2019-01-25 11:11:17,452+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "ba2ca2d0-16e3-4aed-a711-61ba356d805a" result: true>
2019-01-25 11:11:17,487+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "d2bdb5a0-65fc-4a58-8707-12f9e64a5726" result: true>
2019-01-25 11:11:17,487+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "8c21c501-6e91-4961-b1e7-3d6f143ccce5" result: true>
2019-01-25 11:11:17,613+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "6f100ae4-9192-4968-8346-82d7ba6379d2" result: true>
2019-01-25 11:11:17,615+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "26b00d6f-fb67-43ef-a72c-cdea49992c10" result: true>
2019-01-25 11:11:17,617+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "2754674d-bff0-4c3c-a85a-1e0d101aa22c" result: true>
2019-01-25 11:11:17,905+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "31c4ace5-7813-4b2f-91ff-2f5775bf5626" result: true>
2019-01-25 11:11:17,907+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "d5f5978b-54f0-4066-bb8b-19ef55c8fac7" result: true>
2019-01-25 11:11:17,909+01 WARN  [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for <JsonRpcResponse id: "f7dd2be4-517d-4fd4-8504-faab77b28b43" result: true>
2019-01-25 11:11:19,094+01 INFO  [org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand] (EE-ManagedThreadFactory-engine-Thread-5042) [90a935b4-bc35-4158-b08c-5487ed14752d] Host setup networks finished. Lock released. Monitoring can run now for host 'node9' from data-center 'EN'
2019-01-25 11:11:19,096+01 INFO  [org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand] (EE-ManagedThreadFactory-engine-Thread-5042) [90a935b4-bc35-4158-b08c-5487ed14752d] Lock freed to object 'EngineLock:{exclusiveLocks='[HOST_NETWORK328989a6-f5ba-4d1c-a002-8e0fc32479cb=HOST_NETWORK]', sharedLocks=''}'

Comment 1 Netbulae 2019-01-25 11:15:45 UTC
Created attachment 1523493 [details]
engine.log

Comment 2 Dominik Holler 2019-01-26 21:46:05 UTC
As documented in 
https://ovirt.org/develop/release-management/features/network/openvswitch/native-openvswitch.html#limitations
setting DNS is not yet implemented for OVS clusters.
Let me check if there is already a bug to track this.

Comment 3 Netbulae 2019-01-27 16:39:39 UTC
Ah so we really shouldn't use OVS yet with all these limitations, should we better switch back to legacy?

DNS is pretty basic, currently the node cannot find the ovirt engine as there is no dns. Setting them in the hosts file is no problem but it's a bit old fashioned and with deployment through foreman assigning ip's can get messy really quickly.

Or do you mean it's not yet supported setting DNS through the engine gui? Please disable all non supported networking options in the Gui when using OVS (the current default), if it's not supported you shouldn't be able to set the options IMHO.

Comment 4 Ales Musil 2019-01-28 14:35:46 UTC
(In reply to Netbulae from comment #3)
> Ah so we really shouldn't use OVS yet with all these limitations, should we
> better switch back to legacy?

If do you need anything that is mentioned in the limitations then probably yes. 

> 
> DNS is pretty basic, currently the node cannot find the ovirt engine as
> there is no dns. Setting them in the hosts file is no problem but it's a bit
> old fashioned and with deployment through foreman assigning ip's can get
> messy really quickly.

We are currently working on bringing the DNS support for OvS. You can manully edit the /etc/resolv.conf for the time being. 
But be aware the DNS will work only for static IP. Because the dhclient is rewriting the /etc/resolv.conf on it's own. 

> 
> Or do you mean it's not yet supported setting DNS through the engine gui?
> Please disable all non supported networking options in the Gui when using
> OVS (the current default), if it's not supported you shouldn't be able to
> set the options IMHO.

Disabling things in UI for single use case can get really messy in the source code.

Comment 5 Michael Burman 2019-01-28 14:47:22 UTC
OVS is a tech preview and it's not officially supported nor tested. Base on that lowering severity.

Comment 6 Netbulae 2019-01-28 15:29:50 UTC
My bad, I thought OVS was the new default setting for 4.3. Shouldn't think to much and RTFM ;-)

We'll keep things on the old bridge networking for now as there are too many limitations for us to put it into production. 

Thanks for the attention though!

Comment 7 Dominik Holler 2019-01-28 15:35:28 UTC
(In reply to Netbulae from comment #6)
> My bad, I thought OVS was the new default setting for 4.3. Shouldn't think
> to much and RTFM ;-)
> 
> We'll keep things on the old bridge networking for now as there are too many
> limitations for us to put it into production. 
> 

Not related to the bug, but maybe a helpful information:
While OVS for physical interfaces is not yet complete, OVS for VM interfaces
via external OVN networks is stable already.

Comment 8 Netbulae 2019-01-28 15:42:33 UTC
Ah thanks, again I "thought" mixing legacy and OVS networks was not supported. OVS for VM interfaces will be good enough for now as that's the part that didn't scale to good the "Legacy" way...

Comment 9 Ales Musil 2019-01-28 15:50:33 UTC
(In reply to Netbulae from comment #8)
> Ah thanks, again I "thought" mixing legacy and OVS networks was not
> supported. OVS for VM interfaces will be good enough for now as that's the
> part that didn't scale to good the "Legacy" way...

But please be aware that Provider Physical Network [1] requires underlying OvS host.


[1] https://ovirt.org/develop/release-management/features/network/provider-physical-network.html

Comment 10 Dominik Holler 2019-01-29 09:40:50 UTC
propagating target milestone from bug 1195208

Comment 11 Netbulae 2019-01-29 11:24:32 UTC
(In reply to Ales Musil from comment #4)
> (In reply to Netbulae from comment #3)
> > Ah so we really shouldn't use OVS yet with all these limitations, should we
> > better switch back to legacy?
> 
> If do you need anything that is mentioned in the limitations then probably
> yes. 
> 
> > 
> > DNS is pretty basic, currently the node cannot find the ovirt engine as
> > there is no dns. Setting them in the hosts file is no problem but it's a bit
> > old fashioned and with deployment through foreman assigning ip's can get
> > messy really quickly.
> 
> We are currently working on bringing the DNS support for OvS. You can
> manully edit the /etc/resolv.conf for the time being. 
> But be aware the DNS will work only for static IP. Because the dhclient is
> rewriting the /etc/resolv.conf on it's own. 
> 
> > 
> > Or do you mean it's not yet supported setting DNS through the engine gui?
> > Please disable all non supported networking options in the Gui when using
> > OVS (the current default), if it's not supported you shouldn't be able to
> > set the options IMHO.
> 
> Disabling things in UI for single use case can get really messy in the
> source code.

Well then maybe generate an error message? There is a lot of validation going on when I press save, so an error "this option is currently not supported when using OVS" when "cluster switch type == OVS" shouldn't be that difficult I think.

We try to read all the release notes, bugzilla and ovirt design documents but it's not always easy to keep up with what's supported and what not.

Comment 12 Michael Burman 2020-11-02 09:57:24 UTC
Verified on - 
vdsm-4.40.35.1-1.el8ev.x86_64
nmstate-0.3.4-13.el8_3.noarch
NetworkManager-1.26.0-10.el8_3.x86_64
openvswitch2.11-2.11.3-72.el8fdp.x86_64

and
vdsm-4.40.35.1-1.el8ev.x86_64
nmstate-0.4.1-2.el8.noarch
NetworkManager-1.28.0-0.1.el8.x86_64
openvswitch2.11-2.11.3-72.el8fdp.x86_64

ovirtmgmt is in sync after setting a static DNS via the RHV engine UI. 
All changes applied as expected and ovirtmgmt is in sync as expected.

Comment 13 Sandro Bonazzola 2020-11-11 06:39:47 UTC
This bugzilla is included in oVirt 4.4.3 release, published on November 10th 2020.

Since the problem described in this bug report should be resolved in oVirt 4.4.3 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.