## Description of problem:

If I change my DNS (or /etc/hosts) entry to point host1 => host2 and restart ovirt-engine, any HA VM's on host1 will be immediately started on host2.  They are also still running on host1, so filesystem corruption will usually ensue.  There doesn't seem to be any sanity checking that host1 really is host1 (checking host UUID, etc).  Nor does there seem to be any safeguards provided by sanlock (ie, would host1 still be updating the lease for the VM device?)

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

ovirt-engine-4.0.4.4-0.1.el7ev.noarch
rhevm-4.0.4.4-0.1.el7ev.noarch

## How reproducible:

Always

## Steps to Reproduce:

1. Enable HA on a VM and start it on host1
2. Update /etc/hosts so that host1 has the same IP as host2
3. restart ovirt-engine

## Actual results:

ovirt-engine thinks that 'host1' and host2 are actually running, but really, it's just talking to host2 twice.  It sees that the HA VM is not running, so starts it on host2.  But it's already running on the real host1...

## Expected results:

Ideally, ovirt-engine should be able to tell that what it thinks is 'host1' is not really host1, and allow the administrator to take some sort of corrective action.

When ovirt-engine initiates a connection to a hypervisor, can we get it to check the host UUID against it's database entry so it knows for sure it's talking to the expected host?

Can sanlock be used to ensure that nothing else is updating a VM resource lease?  If so, then perhaps a fencing workflow can be invoked before HA restarts happen.

## Additional info:

I have tested this and can reproduce this by changing /etc/hosts on the manager, however it should work with DNS also.  I don't have fencing configured in my environment, but I don't think this will help, as the hosts are actually up, and the manager doesn't see any as down or not responding.