vm: recover must finish with libvirt connection

bz106336 highlights an scenario on which a Vm can
go Up without a proper libvirt connection established (_dom
attribute initialized), and this can lead to a split-brain.

If a running vm is reported as not running by vdsm, the
engine may start another instance of the same vm on another
host, which will likely cause data corruption when two
vm are writing to the same shared storage.

Description of the scenario:
* while VM is running, storage becomes blocked or not responding.
* the user restarts VDSM while the storage is still blocked.
* VDSM does recovery after restart, but given the fact
  that storage was still not responding,
  _normalizeVdsmImg() inside buildConfDevices() fails.
* due the way exception are handled, this leads to the
  skip of the libvirt connection step, leaving the _dom
  attribute at its default value (None), thus
* the VM is disconnected from libvirt and out of sync.

We cannot avoid this sequence of events, nor we can
prohibit users from restarting VDSM, but we can
take measures to avoid to go out of sync.

When starting a new VM, storage failure/unavailability is fatal;
when recovering, we should handle those kinds of error
and ensure we do have a libvirt connection on every Vm object.

This patch excplitely handle this storage not responsive
condition and let the initialization process continue, in
order to make sure we obtain a libvirt handle.

Bug-Url: https://bugzilla.redhat.com/1063336
Change-Id: I6c33a62c29fc70170b6f802a20b6016b301e96de
Signed-off-by: Francesco Romani <fromani@redhat.com>
Reviewed-on: http://gerrit.ovirt.org/24423
Reviewed-by: Nir Soffer <nsoffer@redhat.com>
Reviewed-by: Michal Skrivanek <michal.skrivanek@redhat.com>
Reviewed-by: Dan Kenigsberg <danken@redhat.com>
Reviewed-by: Federico Simoncelli <fsimonce@redhat.com>
Reviewed-by: Vinzenz Feenstra <vfeenstr@redhat.com>
Reviewed-on: http://gerrit.ovirt.org/24821
Reviewed-by: Yaniv Bronhaim <ybronhei@redhat.com>