Physical vs virtual: What's your poison?
Power management and VDI
The differences between physical desktops and virtual ones can be in some cases stark, in others so insignificant as to be nearly indistinguishable. My most recent IT project has centered on trying to wring power savings out of my network, in an effort largely to reduce the cooling load our equipment requires. It is here, in attempting to configure my network for power conservation and Lights Out Management (LOM) that I encountered some of the more frustrating differences between VDI deployments and physical desktops.
It should be noted that there are other remote working solutions. Terminal Services, Citrix and similar offerings would suffer the same issues as VDI. I use VDI as the discussion point in this article entirely because it’s what I have deployed in my environment. (Why I chose VDI over other competitive offerings is reserved for a future set of articles.)
Perhaps the biggest frustration with virtual machines, be they servers or desktops, is that when the operating system has crashed, the users can’t simply go and restart a computer to have it all back up and running. I am sure the very concept of users rebooting servers will have some people flooding the comments with outrage, but I seriously dislike having to wake up at four in the morning just to poke some system in the eye. (Some applications to which we have no alternative are fairly flaky. BSODing a computer, be it physical or virtual, happens about once a quarter.)
With virtualization, the only way to start, restart or otherwise control a virtual machine is through the management software for whatever flavour of virtualization the host system is running. Giving users access to this software is generally a Bad Plan. Even if you were to do so, training them in how to use it properly is no easy task.
This entered my radar on the power management and LOM project with Windows 7. By default, Windows 7 suspends your computer after an inactivity of about half an hour. When a Windows 7 guest sends the sleep signal to the host, the host suspends that VM, making in inaccessible to the user. This is an easily correctable problem; but a perfect example of how power management considerations are different when using VDI.
If that Windows 7 system had been a physical computer under the desk of the user they could have pushed the power button to turn it on in the morning. More importantly, I would have been able to sleep in.
Another consideration is that the implementation of VDI has caused our entire workforce to become very familiar with the concept of remote accessing a computer. Everyone does it everyday and it seems perfectly normal to them. With increasing frequency, various staff are requesting (and requiring) the ability to access work systems from home. Leaving aside the discussion of the security concerns, it has some interesting power management, LOM and even maintenance repercussions.
If all the desktops were physical, then those users who were not set-up for home access could have their systems programmed to automatically power down at the end of the work day, and come back on-line just before the doors opened. The folks who needed remote access would have their systems available for a longer access window. While we can now do this with the thin clients on everyone’s desk, the real power consumption has moved from under the desktop into the server room.
If none of my users remoted into the network during off hours, the servers themselves could be powered down at the end of the business day; suspending all non-essential VMs, and shutting down their host systems. With a mixture of users who access their systems from home after hours, and users who nine-to-five it, much closer attention to virtual machine distribution needs to be paid if I want to power down any of the host systems during off hours.