First, that an intermittent issue occurs at the failing server, requiring a reboot or a process restart. In this event, a few minutes of downtime waiting for the server to come back online is all the end user will have to deal with; not completely unlike rebooting a conventional PC. The chances that this sort of issue will happen on a server, though, are usually far less than on a PC as most all servers use higher-grade components, error correcting memory, redundant network interfaces and so on.

The second and more problematic scenario is when the server crashes entirely and cannot be recovered via a reboot. In this event, the user's VM is now stuck on a local store that is no longer accessible. Clearly, this is a troublesome outcome because, in order to restore the user's session, the entire VM needs to be re-created and access to the user's data needs to be restored too. But as with all things in IT, one can't rush to conclusions. It turns out you can architect things in a way that makes even this scenario not quite as disastrous as it appears at first blush.

To understand how, let's look at what a user typically has on their PC, or on their VM. There is an operating system of course, layered with , drivers, updates and configuration information. On top of this, there are user-specific environment settings -- or profile data. And finally, there is user data.

CASE STUDY:

A typical network of desktops uses methodologies like roaming profiles, or NAS-resident user data repositories (i.e. where your "Documents" folder points to a network location). If you use Active Directory or a similar centralized permissioning and authentication system, you can typically log into different systems and the group policies ensure your Documents and data folders are accessible and that they point to the correct NAS location.