Hi John, this is the patch fixing your problem [1]. It can be found at the top of that bz page. It's really a simple change, so if you want you can just change it manually on your system without waiting for a patches version. --Jirka [1] http://gerrit.ovirt.org/#/c/31510/2/ovirt_hosted_engine_ha/agent/states.py On 08/18/2014 12:17 AM, John Gardeniers wrote:
Hi Jirka,
Thanks for the update. It sounds like the same bug but with a few extra issues thrown in. e.g. Comment 9 seems to me to be a completely separate bug, although it may affect the issue I reported.
I can't see any mention of how the problem is being resolved, which I am interested in, but will keep an eye on it.
I'll try the patched version when I get the time and enthusiasm to give it another crack.
regards, John
On 14/08/14 22:57, Jiri Moskovcak wrote:
Hi John, after a deeper look I realized that you're probably facing [1]. The patch is ready and I will also backport it to 3.4 branch.
--Jirka
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1093638
On 07/29/2014 11:41 PM, John Gardeniers wrote:
Hi Jiri,
Sorry, I can't supply the log because the hosts have been recycled but I'm sure it would have contained exactly the same information that you already have from host2. It's a classic deadlock situation that should never be allowed to happen. A simple and time proven solution was in my original post.
The reason for recycling the hosts is that I discovered yesterday that although the engine was still running it could not be accessed in any way. Upon further finding that there was no way to get it restarted I decided to abandon the whole idea of self-hosting until such time as I see an indication that it's production ready.
regards, John
On 29/07/14 22:52, Jiri Moskovcak wrote:
Hi John, thanks for the logs. Seems like the engine is running on host2 and it decides that it doesn't have the best score and shuts the engine down and then neither of them want's to start the vm until you restart the host2. Unfortunately the logs doesn't contain the part from host1 from 2014-07-24 09:XX which I'd like to investigate because it might contain the information why host1 refused to start the vm when host2 killed it.
Regards, Jirka
On 07/28/2014 02:57 AM, John Gardeniers wrote:
Hi Jira,
Version: ovirt-hosted-engine-ha-1.1.5-1.el6.noarch
Attached are the logs. Thanks for looking.
Regards, John
On 25/07/14 17:47, Jiri Moskovcak wrote:
On 07/24/2014 11:37 PM, John Gardeniers wrote: > Hi Jiri, > > Perhaps you can tell me how to determine the exact version of > ovirt-hosted-engine-ha.
Centos/RHEL/Fedora: rpm -q ovirt-hosted-engine-ha
> As for the logs, I am not going to attach 60MB > of logs to an email,
- there are other ways to share the logs
> nor can I see any imaginagle reason for you wanting > to see them all, as the bulk is historical. I have already included > the > *relevant* sections. However, if you think there may be some other > section that may help you feel free to be more explicit about > what you > are looking for. Right now I fail to understand what you might > hope to > see in logs from several weeks ago that you can't get from the last > day > or so. >
It's a standard way, people tend to think that they know what is a relevant part of a log, but in many cases they fail. Asking for the whole logs has proven to be faster than trying to find the relevant part through the user. And you're right, I don't need the logs from last week, just logs since the last start of the services when you observed the problem.
Regards, Jirka
> regards, > John > > > On 24/07/14 19:10, Jiri Moskovcak wrote: >> Hi, please provide the the exact versions of ovirt-hosted-engine-ha >> and all logs from /var/log/ovirt-hosted-engine-ha/ >> >> Thank you, >> Jirka >> >> On 07/24/2014 01:29 AM, John Gardeniers wrote: >>> Hi All, >>> >>> I have created a lab with 2 hypervisors and a self-hosted engine. >>> Today >>> I followed the upgrade instructions as described in >>> http://www.ovirt.org/Hosted_Engine_Howto and rebooted the >>> engine. I >>> didn't really do an upgrade but simply wanted to test what would >>> happen >>> when the engine was rebooted. >>> >>> When the engine didn't restart I re-ran hosted-engine >>> --set-maintenance=none and restarted the vdsm, ovirt-ha-agent and >>> ovirt-ha-broker services on both nodes. 15 minutes later it still >>> hadn't >>> restarted, so I then tried rebooting both hypervisers. After an >>> hour >>> there was still no sign of the engine starting. The agent logs >>> don't >>> help me much. The following bits are repeated over and over. >>> >>> ovirt1 (192.168.19.20): >>> >>> MainThread::INFO::2014-07-24 >>> 09:18:40,272::brokerlink::108::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify) >>> >>> >>> >>> >>> Trying: notify time=1406157520.27 type=state_transition >>> detail=EngineDown-EngineDown hostname='ovirt1.om.net' >>> MainThread::INFO::2014-07-24 >>> 09:18:40,272::brokerlink::117::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify) >>> >>> >>> >>> >>> Success, was notification of state_transition >>> (EngineDown-EngineDown) >>> sent? ignored >>> MainThread::INFO::2014-07-24 >>> 09:18:40,594::hosted_engine::327::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring) >>> >>> >>> >>> >>> Current state EngineDown (score: 2400) >>> MainThread::INFO::2014-07-24 >>> 09:18:40,594::hosted_engine::332::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring) >>> >>> >>> >>> >>> Best remote host 192.168.19.21 (id: 2, score: 2400) >>> >>> ovirt2 (192.168.19.21): >>> >>> MainThread::INFO::2014-07-24 >>> 09:18:04,005::brokerlink::108::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify) >>> >>> >>> >>> >>> Trying: notify time=1406157484.01 type=state_transition >>> detail=EngineDown-EngineDown hostname='ovirt2.om.net' >>> MainThread::INFO::2014-07-24 >>> 09:18:04,006::brokerlink::117::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify) >>> >>> >>> >>> >>> Success, was notification of state_transition >>> (EngineDown-EngineDown) >>> sent? ignored >>> MainThread::INFO::2014-07-24 >>> 09:18:04,324::hosted_engine::327::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring) >>> >>> >>> >>> >>> Current state EngineDown (score: 2400) >>> MainThread::INFO::2014-07-24 >>> 09:18:04,324::hosted_engine::332::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring) >>> >>> >>> >>> >>> Best remote host 192.168.19.20 (id: 1, score: 2400) >>> >>> From the above information I decided to simply shut down one >>> hypervisor >>> and see what happens. The engine did start back up again a few >>> minutes >>> later. >>> >>> The interesting part is that each hypervisor seems to think the >>> other is >>> a better host. The two machines are identical, so there's no >>> reason I >>> can see for this odd behaviour. In a lab environment this is >>> little >>> more >>> than an annoying inconvenience. In a production environment it >>> would be >>> completely unacceptable. >>> >>> May I suggest that this issue be looked into and some means >>> found to >>> eliminate this kind of mutual exclusion? e.g. After a few >>> minutes of >>> such an issue one hypervisor could be randomly given a slightly >>> higher >>> weighting, which should result in it being chosen to start the >>> engine. >>> >>> regards, >>> John >>> _______________________________________________ >>> Users mailing list >>> Users@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> >> >> ______________________________________________________________________ >> >> >> This email has been scanned by the Symantec Email Security.cloud >> service. >> For more information please visit http://www.symanteccloud.com >> ______________________________________________________________________ >> >> >
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________