Description of problem:

If a host becomes non-operational after previously becoming non-responsive and being fenced the 
two flows (vdsNotResponding and SetNonOperationalVdsCommand) can leave one or more guests marked 
in a non-responsive state instead of down.

Version-Release number of selected component (if applicable):
3.0.3

How reproducible:
Unable to reproduce internally as yet.

Steps to Reproduce:
[ Work In Progress ]
1. Use a locally shared NFS mount as a SD.
2. Disable the NFS services at reboot.
3. Have a number of running guests on the host at the time.
4. Block vdsmd to force a non-responsive treatment to be started.
5. Host should be fenced and should become non-operational shortly after booting.
6. One or more guests should be marked as non-responsive instead of down.
  
Actual results:
Guests marked as non-responsive.

Expected results:
Guests should be marked as down.

Additional info:

Customer logs with an example of this will following in a private comment.

Given the need for a host to become non-operational after fencing and the fact that the guests can easily be corrected I am only assigning a medium prio to this bug. 

My recommendation at this time would be that InitVdsOnUpCommand destroy any competing threads for the same host to avoid situations like this but I am not sure if this is appropriate for every use case.