In the event that a hardware failure occurs on the running your VM, you can use these live migration techniques to transfer a VM to a different server, thus maintaining continuity of service. These features don't, however, make you immune to application crashes, OS crashes or many of the inherent instabilities in the OS and platform stack that don't have anything to do with hardware.

So, even with live migration and a SAN backend it's not as if you're getting complete immunity from downtime. Yes, hardware issues on your host server are eliminated from the downtime equation, but this improvement in uptime comes at a premium. SANs are costly when purchased from the category leaders. There are smaller companies offering more economic solutions, but regardless of the vendor, this class of storage is considerably more expensive when compared to distributed or local storage.

Distributed storage can be defined as self-contained islands of local storage associated with multiple servers, such that each local store remains accessible only to the server it is attached to, but where the aggregate capacity of all such islands can be used to store the total set of VMs required.

For example, if the servers are implementing a collection of hypervisors for VDI, then individual user VMs may find themselves mapped to specific local stores. The aggregate of all local stores is the distributed storage capacity. The big advantages are setup is simple, no SAN or specialized storage management tools are necessary, the server configuration is fairly simple to order and support and the cost per terabyte is much lower than for SAN based centralized storage solutions.

The downside is uptime. If the hypervisor running your VM crashes, then you cannot move that VM to a different hypervisor using live migration and the end user will experience some downtime. But in order to truly understand the real world implications of this kind of failure, we need to consider two cases under which this situation may occur.