надо рассмотреть каждую ситуацию в частности.
1. если хост работает, но контрольная сеть упала и до него не достучаться. в таком случае будет stonith который для виртуалки ничем не будет отличаться от полноценного reset железа, или не будет ничего, пока админ сам не восстановит сеть (это уже зависит от настроек). типичный failover cluster в принципе сводит все сбои к упавшему железу и перезапуску сервисов на другом хосте, и плоха та виртуалка которая не способна пережить reset без серьезных потерь.
2. если хост упал, и виртуалку перезапустили на другом - в принципе она пострадала не более чем если бы бежала на том самом упавшем железе, плюс автоматический перезапуск. Короче сплошной профит, HA это все таки не FT
3. если упал сторедж - место кончилось, fabric отказал - не важно со стороны хоста или стореджа или свичей. любая проблема которая выдасть при попытке писать или читать виртуальный диск error (EIO, ENOSPACE если в терминах ядра). qemu-kvm в этом случае моментально отправляет VM в паузу, чтоб не генерировать IO и дополнительные сбои. Таким образом in flight IO замораживаются а не теряются. Чиним сторедж, выводим VM из паузы, и щсе продолжается как будто ничего не случилось.
Кстати, #3 это главная причина использования nfs hard mount под виртуалки, чтоб проблемы с доступом к дискам сразу отображались гипервизором а не уходили в буфер.