Virtual desktop administrators run into all kinds of problems, from network failures and application performance to virtual machine monitoring and resource overutilization. Of course, you can't forget the most notable nuisance of all -- the user.
What are some common application stability issues?
Alastair Cooke: They tend to be the same issues that you get on a desktop PC: An application starts to use a lot of CPU or memory, and the desktop becomes unresponsive. The big difference is, with a VDI deployment, that affects the user's ability to see the desktop because the remote display protocol gets starved of CPU.
More on VDI problems and deployment issues
Avoiding VDI deployment problems
Top desktop virtualization project pitfalls
VDI pilot project guide
If that's a frequent problem for you, create a dual-processor VM [virtual machine] rather than a single processor. So, if an application saturates one CPU core, there's a second core available that the remote display protocol can use. This is a best practice in VMware View if you're using graphically intensive applications. It decreases the number of desktops you can provision per virtualization host, but if it means that the desktops are always available, you may choose to do this for a subset of users that need high-CPU load applications.
How can you make sure users don't install apps that shouldn't be there?
Cooke: In a VDI environment, you usually provide the user with a very locked environment. We want all their desktops to be the same, so we use Windows Group Policy and security settings to constrain users so they can't install their own applications.
This is a double-edged sword because then, users find it more difficult to solve problems by finding their own applications. Hopefully the IT team is responsive to end users' requests for applications, particularly early on in a VDI deployment, to learn what the users actually need.
Application virtualization can also be extremely helpful. It's really good for applications that are used by a small number of users. If you have four or five staff who need access to a payroll application, then virtualizing that application is better than carving off four or five VMs to dedicate to the payroll team.
User profile management is often a sore spot. Why is that?
Cooke: If you set up an environment where the users get what VMware calls a "floating assignment" pool -- meaning any user can use any desktop -- then you need a clean logoff to retrieve the user persona (especially if you're using Windows roaming profiles). If something goes wrong at logoff, the profile doesn't get loaded out of the desktop, and the next time they log in, they get an empty profile.
The other problem you could encounter is with the "dedicated assignment" pool, where a specific VM belongs to a specific user. The user can get to their desktop only if that VM is available. It's beneficial for the user profile because the profile stays inside the desktop, but if the desktop's unavailable for any reason -- a network problem, for instance -- then the user can't get into their desktop at all.
How can IT use profile management tools to solve those problems?
Cooke: There's Windows roaming profiles, which people have the most issues with. VMware's Persona Management, which came out of their acquisition of RTO Software, can do a periodic upload so you don't need a clean logoff to get the profile data onto the profile share. It's uploaded every few minutes while the user is logged on.
Another product that people are using is Liquidware Labs' ProfileUnity. It helps with problems around one-off applications -- apps that are used by only a small number of users -- because it has some functionality for user-installed applications.
What other VDI problems arise with dedicated VMs?
Cooke: If the VM that's dedicated to the virtual desktop is unavailable, the user can't log onto the desktop. One of the classic reasons a VM becomes unavailable is you run out of IP addresses. Provisioning VMs can use a lot of IP addresses -- far more than a conventional desktop environment would have.
Another thing is desktops coming up in maintenance mode -- a mode where they're not available to users. … Users can also turn their own computers off; they could take their virtual desktop and shut it down. On occasions, that can make the VM not start up correctly when you log back in. That can cause delays and take 5 minutes for a desktop to come up.
How can you keep users from causing virtual desktop downtime?
More Q&As with Alastair Cooke
Considering virtual desktop recovery methods
Explaining application streaming vs. remote delivery
Cooke: To prevent users from accidentally powering off VMs, VMware View has a power setting where you can set the VMs in a pool to always be powered on. If a user shuts them down, they start back up again. However, that means every single VM is powered on all the time and using resources. Even though staff members only work 8 hours a day, 5 days a week … that's still significantly fewer hours than there are in the week, so the VMs are powered on a lot longer than is necessary.
What are some tips for managing debug information?
Cooke: Debug information is usually plentiful. Event logs will tell you a great deal about what's going on, but some of the logs can be very verbose. There may be hundreds of records going through every minute, particularly in a large-scale environment. You need to parse those logs and turn them into really useful information. Something like Splunk, a tool for managing logs, can also integrate with desktop virtualization products.
What are some other problems that plague VDI deployments?
Cooke: One thing that can become an issue in a very large-scale environment -- we're talking thousands of users -- is the replication between connection servers, particularly in VMware View. I had a customer that had a real problem with their replication getting broken [due to network connectivity issues]. To resolve it, they used custom event filters to view the events under Windows and Active Directory Application Mode management tools.