Introduction to Managing Pools and Desktops
Version: Horizon View 5.1
As we saw in earlier chapters, creating pools is a very simple process – and the main pool node will show you all the pools you have created. A simple Edit button allows you to modify some (but not all) of your settings generated by the Add pool wizard. The notable value that cannot be modified after the pool has been created is the pool ID parameter as this is a unique identifier for the pool in the database.
Every pool comes with a Status button with the options to both “Disable Pool…” and “Disable Provisioning…”.
These menus do change, especially if a problem occurs during the provisioning process. They can also be used to re-trigger the provisioning process if those issues have been resolved – you will see the status option change from Disable Provisioning to Enable Provisioning.
Un-assign Users from Dedicated Pools
One of the management issues of dedicated pools is un-assigning users. As you might recall, with a Dedicated Pool, a user is randomly assigned to a desktop from the pool when they first connect. This desktop then becomes their own personal desktop that they constantly reuse. This introduces a management issue – what if the user leaves the organization, or is reassigned to a different segment of the business where they need an entirely different virtual desktop for their work? This would leave the desktop assigned to the original user, with no other user able to access that desktop. Essentially, the desktop becomes a wasted and orphaned resource in the pool. If you select the pool and navigate to the Inventory tab, the “More Commands” button exposes this option:
Maintenance Mode – Taking a Desktop Offline
As you can see from the screen grab above it is also possible to manually, on a per-desktop basis, disallow access to a specific desktop owned by a user on a dedicated pool. This does not disconnect and log out the user if they are already connected, but if the user logs out and tries to log in again, the View client tells them that their desktop is unavailable:
Resetting a Desktop
This is quite a dangerous option as no prompt is sent to the user that this is about to happen. If a virtual desktop for whatever reason becomes completely unresponsive, such that the user cannot interact with it, it is possible from the View management console to hard reboot the VM. This does NOT perform a graceful shutdown of the VM, and therefore any files the user has not saved will be lost. Remember, it’s not a default pool setting that users can reset their own desktops unless you grant it. If you don’t grant the permission, you will find the option to “Reset Desktop” in the View Client Toolbar will be dimmed.
Remember, to grant your users this privilege, you would edit the pool settings, navigate to the “Pool Settings” tab, and change “Allow users to reset their desktops:” to Yes.
If you do decide to use the reset option from the View administration tools, you will see this message when you click the option:
The actual user experience is actually quite unpleasant. Here’s what happens. When you perform a reset of the virtual desktop, the VM is hard rebooted. In Windows 7 this can be sometime detected as a fault, and cause Windows 7 to enter its repair mode. From the end-users perspective for a short period the session stays open. This is because the display protocol will complete a retry process that keeps the presentation on screen for a while in the hope that the connection will be re-established. If the user has any open and unsaved files, these applications will prompt the user to save their files. However, it will be too late. The user won’t be able to interact with their session because it isn’t there anymore. After a short period, the client session ends unceremoniously – leaving the user with this rather blunt message:
With the PCoIP protocol no such message is generated and the user is bombed out of the session without notification.
Remove a Desktop
Right next door to the Reset button on a desktop is the Remove option. This can be used to delete a virtual desktop from the pool. It will cause the user to take a new desktop from the pool as their original desktop was destroyed. Additionally, because a desktop has been removed from the pool, it’s likely to trigger the creation of a new desktop based on the pool’s provisioning settings (max, spare and min). If you click the Remove button whilst a user is connected, View will display a dialog box like so:
When you are removing a desktop you can choose between removing the VM’s from View Manager only this will ensure the virtual machines remain in the vCenter or to Delete VM’s from disk which. You are also able to choose if you wish to terminate any sessions as displayed above or you could decide to be less intrusive and let the session carry on – in this case the desktop would be deleted only when the user finished their session and logged out. With the option “Terminate” as with the reset, this is very intrusive to users, as their session is unceremoniously ended without any opportunity to save data, and the VM is then powered off and deleted. If there is spare capacity in the pool, the user will be able to reconnect to View and will simply be allocated a new desktop from the pool.
Remote Session Management
More options exist for managing user sessions from the aptly named Sessions tab that appears on the pool’s properties. The sessions are filtered by remote sessions (RDP/PCoIP), Local Sessions (Basic) and Local Sessions (Transfer). From the Session tab, it’s possible to Disconnect, Logoff, Reset and Send Messages to actively connected users. From the screen grab below, you can see all these options. Notice how the Duration column indicates that there may be a time problem with a VM if it comes up with the message “Clock Skewed”, and that my user has connected using PCoIP rather than RDP.
Important: As you have probably gathered, the View administration pages do not automatically refresh. So it’s possible to try to disconnect, logoff, reset or send a message to a session that simply doesn’t exist anymore. So, click refresh if you have been in these pages for a while
- Disconnect – Merely closes the user’s window on their virtual desktop. The user is not logged out of their VM, and files remain open in the virtual desktop. No prompt is sent to the uses that you are about to disconnect their session
- Logoff – Logs the user out of their VM. No message is sent to the user that they are being logged off, however they are prompted briefly to save any data. If they don’t respond in a timely fashion, or are unable to, the session terminates the applications within the virtual desktop without saving their data
- Reset Virtual Machine – Covered earlier
- Send Message – This sends a popup message to the user that appears within the virtual desktop. The UI allows you to categorize your messages into three types (info, warning and error). As with all messaging systems it’s wise to engage your brain before sending messages to your management team. With great power, comes great responsibility!
In this chapter we have covered some of the tasks that you will need to be aware of when managing desktop pool in VMware View, one of the most important take always from this chapter is to be sure you know the consequences of each different pool action before running ahead and disrupting your users. In our next chapter we will be looking at VMware’s “Linked Clones” technology. This a much more efficient method of creating desktop pools that merely cloning of templates allows for. We have written two chapters on the subject – the first involves there initial setup and configuration – the second concerns their longer term management.