Created attachment 963266 [details] Engine and vdsm logs Description of problem: After reboot the host, vdsm does not run and the host locked on status Non Responsive Version-Release number of selected component (if applicable): 3.5 vt11 How reproducible: 100% Steps to Reproduce: 1. Reboot the host 2. On host tab confirm ‘Host has been Rebooted’ Actual results: The vdsm does not run Expected results: Vdsm should run
According to the engine log, the host was down, but then was up again. Then, it had some failures until it was elected to be the SPM. For how long was the host in Non Responsive state? Didn't it move to Up? The log shows that InitVdsOnUp procedure was called, which is usually triggered when a host moves to Up.
I also see according to the vdsm log, that it was started at December 1st, 10:54, which fits the time in which InitVdsOnUp was called.
(In reply to Oved Ourfali from comment #1) > According to the engine log, the host was down, but then was up again. > Then, it had some failures until it was elected to be the SPM. > For how long was the host in Non Responsive state? > Didn't it move to Up? > The log shows that InitVdsOnUp procedure was called, which is usually > triggered when a host moves to Up. The host stuck in Non Responsive until i started the vdsm via service (service vdsmd start) Please find attached another logs from other reproduction
Created attachment 964487 [details] logs
sort of duplicate with Bug 1168689 , although the output is different after installing and see an exception, vdsmd can run fine. but the installation skipped the chkconfig part due to the error this was fixed as part of the dup bug *** This bug has been marked as a duplicate of bug 1168689 ***
keeping it open for verification. the fix is already merged
currently cannot verify this bug, as another bz (https://bugzilla.redhat.com/show_bug.cgi?id=1149832) which I had to re-open occurs during this scenario. although that bug occurs, basically this bug seems to have been resolved as vdsm is up upon reboot. Let me know if I should verify or put 1149832 as a blocker.
Verified with rhevm-3.5.0-0.27.el6ev.noarch. on the rebooted host: vdsm-4.16.8.1-4.el7ev.x86_64. 1) have 2 hosts in 2 clusters. 2) stop one of the hosts manually. 3) host becomes non responsive. 4) power up the host. 5) choose 'confirm host has been rebooted' on rhevm. 6) host starts. 7) host state goes back to 'up' in rhevm.
rhev 3.5.0 was released. closing.