Created attachment 1062416 [details] logs.tgz Description of problem: When adding host the ERROR message appeared: "VDSM <fqdn-of-my-host> command failed: Policy reset" In the vdsm.log nor supervdsm.log can't see any error. engine.log: 2015-08-13 09:50:42,094 INFO [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [1fcd3382] Connecting to <FQDN-of-my-host>/<IP-of-my-host> 2015-08-13 09:50:42,147 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-7-thread-3) [20127663] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VDSM <FQDN-of-my-host> command failed: Policy reset 2015-08-13 09:50:42,147 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (org.ovirt.thread.pool-7-thread-3) [20127663] Command 'PollVDSCommand(HostName = <FQDN-of-my-host>, VdsIdVDSCommandParametersBase:{runAsync='true', hostId='b9ce9025-8b15-4b96-89eb-7c607e7361f6'})' execution failed: VDSGenericException: VDSNetworkException: Policy reset 2015-08-13 09:50:42,147 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (org.ovirt.thread.pool-7-thread-3) [20127663] Error: VDSGenericException: VDSNetworkException: Policy reset Version-Release number of selected component (if applicable): rhevm-3.6.0-0.11.master.el6.noarch vdsm-4.17.2-1.el7ev.noarch (rhel: engine 6.7, host 7.2) How reproducible: Steps to Reproduce: 1. add host with using FQDN into engine through webadmin 2. 3. Actual results: Non-descriptive Error about Policy. Expected results: Additional info:
Policy reset it is standard behavior of the engine when we attempt to run setupNetworks. We make sure that connection to vdsm is health by sending heartbeat but when we run setupNetworks we know that were are about to have networking issues so we need to reset policy and stop expecting heartbeats. There is only one way in the engine to pass that information to higher layers by throwing an exception. What would be acceptable description for you?
I don't understand why ERROR is mentioned in the log when it is expected behaviour. I'd rather see proper severity, thus if using kinda semaphore as communication - shouldn't scare user.
Ok, let's check severity for this specific message.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
*** Bug 1273408 has been marked as a duplicate of this bug. ***
*** Bug 1273407 has been marked as a duplicate of this bug. ***
How is it possible that this bug has all the referenced patches merged up to 3.6.0 branch and it's still missing all the required acks?
Please note that even if the fix has been merged in 3.6.0 branch, since this is not approved as blocker it won't cause a rebuild for 3.6.0 GA. Please either approve this as blocker or postpone to 3.6.1.
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset. Please set the correct milestone or add the z-stream flag.
Fixed bug tickets must have target milestone set prior to fixing them. Please set the correct milestone and move the bugs back to the previous status after this is corrected.
In oVirt testing is done on single release by default. Therefore I'm removing the 4.0 flag. If you think this bug must be tested in 4.0 as well, please re-add the flag. Please note we might not have testing resources to handle the 4.0 clone.
Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.
Verified on 3.6.2.6-0.1.el6