OLVM: Two KVM Hosts Keep in Non-Responsive in Turn Everytime ovirt-engine Service Restarts (Doc ID 2750847.1)

Last updated on DECEMBER 25, 2023

Applies to:

Symptoms

There are two KVM Hosts in this scenario with SHE engine. The two KVM hosts keep in Non-Responsive in turn everytime ovirt-engine service restarts. That means, there is only one KVM host in 'UP' status.

The debug log error in engine.log is mis-leading, it reports:

2021-01-13 10:47:09,015+07 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-38) [] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), VDSM Hostxxx command Get Host Statistics failed: Message timeout which can be caused by communication issues
2021-01-13 10:47:09,022+07 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (EE-ManagedThreadFactory-engineScheduled-Thread-38) [] Unable to GetStats: VDSNetworkException: VDSGenericException: VDSNetworkException: Message timeout which can be caused by communication issues
2021-01-13 10:47:09,022+07 DEBUG [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (EE-ManagedThreadFactory-engineScheduled-Thread-38) [] Exception: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: VDSGenericException: VDSNetworkException: Message timeout which can be caused by communication issues
at org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.proceedProxyReturnValue(BrokerCommandBase.java:190)
[vdsbroker.jar:]
at org.ovirt.engine.core.vdsbroker.vdsbroker.GetStatsAsyncVDSCommand$GetStatsVDSCommandCallback.onFailure(GetStatsA
syncVDSCommand.java:56) [vdsbroker.jar:]
at org.ovirt.vdsm.jsonrpc.client.internal.ResponseTracker.lambda$remove$0(ResponseTracker.java:153) [vdsm-jsonrpc-j
ava-client.jar:]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_252]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_252]
at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141) [javax.enterprise
.concurrent-1.0.jar:]
at org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.acces
s$101(ManagedScheduledThreadPoolExecutor.java:383) [javax.enterprise.concurrent-1.0.jar:]
at org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(M
anagedScheduledThreadPoolExecutor.java:532) [javax.enterprise.concurrent-1.0.jar:]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_252]
at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) [javax.enterprise.concurrent-1.0.jar:]

However, there is no network related issue.

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.