On Fri, Jun 14, 2019 at 3:02 PM Strahil <hunter86_bg(a)yahoo.com&gt; wrote: Yes, it just restarts vdsmd service using SSH connection. In the past we had several cases, where VDSM was non-responsive, but VMs were running fine, that's why we added this as the 1st step in non-responding treatment flow. We try to connect to host using SSH, restarts VDSM and waits if host start communicate again. If there is an error during SSH connection or service restart, we immediately continue to next phase of the treatment. The manager, this flow is started from host monitoring if there a network error or connection timeout ... So if engine cannot communicate with host, we don't know the reason, so there are several steps in non-responding treatment: 1. SSH Soft Fencing 2. Kdump detection (if it's configured for the host and we detecte host is dumping, we can restart HA VMs on different host) 3. Power Management restart - according to cluster fencing policy we can skip restarting host if for exampl host is renewing its storage lease or gluster cluster is healing - this part is executed on different host in the same cluster/data center If you want to know more about fencing in oVirt, please take a look at below links: Host fencing in oVirt - Fixing the unknown and allowing VMs to be highly available https://www.youtube.com/watch?v=V1JQtmdleaM Integrating kdump into oVirt https://www.youtube.com/watch?v=RAGV_za_Qvw Automatic fencing in oVirt https://www.ovirt.org/develop/developer-guide/engine/automatic-fencing.html Fence-kdump integration in oVirt https://www.ovirt.org/develop/release-management/features/infra/fence-kdu... And course feel free to ask questions Martin -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.