5.2. About Desktops and Templates

5.2.1. Supported Desktop Operating Systems
5.2.2. About Templates and Revisions
5.2.3. About Desktop and Virtual Machine States

The term desktop refers to an instance of an operating system running on a virtualization host. It is delivered to a user and accessed using a Sun Ray Client. Oracle VDI manages desktops on any of the following virtualization platforms:

Desktops may be created one-by-one for each user, but in most situations there are groups of users that require the same applications. Oracle VDI allows you to prepare and use a desktop template, and clone as many desktops as needed from the template. For more on templates, refer to the Section 5.2.2, “About Templates and Revisions” section.

5.2.1. Supported Desktop Operating Systems

The following table shows the desktop operating systems that are supported for each desktop provider type. Pay particular attention to the notes that follow this table.

Table 5.7. Supported Desktop Operating Systems by Desktop Provider Type

Desktop Operating System

Oracle VM VirtualBox

VMware vCenter

Microsoft Hyper-V

Windows 8 (32-bit and 64-bit) [a]

Windows 7 SP1 Enterprise Edition (32‑bit and 64‑bit)  [b]

Windows XP SP2 (64-bit) and SP3 (32-bit)

Oracle Linux 6.3



Oracle Solaris 11.1



Oracle Solaris 10, at least release 10/09



SUSE Linux Enterprise Desktop 11



Ubuntu 12.04 (Precise Pangolin)



Ubuntu 10.04 (Lucid Lynx)



[c] VirtualBox RDP (VRDP) only.

The supported desktops for Microsoft Remote Desktop provider are described in Section 4.2.4, “System Requirements for Microsoft Remote Desktop Services”.

The features that can be used with a virtual desktop depend on the RDP protocol selected for the pool and the method used to access Oracle VDI. For more information, see the following:

Windows 8 Support

Oracle VDI is tested on and supports Windows 8 Enterprise Edition. Other editions of Windows 8 can be used, but in the event of an issue, you must be able to reproduce the issue in Windows 8 Enterprise Edition.

If Microsoft RDP is selected as the desktop protocol, only Windows 8 Professional and Enterprise editions can be used. If VirtualBox RDP is selected, all editions of Windows 8 can be used.

Windows 7 Support

Oracle VDI is tested on and supports Windows 7 SP1 Enterprise Edition. Other editions of Windows 7 can be used, but in the event of an issue, you must be able to reproduce the issue in Windows 7 SP1 Enterprise Edition.

If Microsoft RDP is selected as the desktop protocol, only Windows 7 Professional, Ultimate, or Enterprise editions can be used. If VirtualBox RDP is selected, all editions of Windows 7 can be used.

If Microsoft RDP is selected as the desktop protocol, multiple monitor and audio recording (input audio) are only available in Windows 7 Ultimate and Enterprise editions. Windows 7 Professional does support a single desktop spanned across multiple monitors (spanned mode).

5.2.2. About Templates and Revisions

Desktops that are designed to be used as master copies from which clones can be propagated are called templates. A template consists of a guest operating system profile, a hardware profile, and one or more virtual hard disks. The use of templates makes it easier to perform and control administrative tasks such as filling a pool with available desktops and propagating updates to them. For more about desktops, refer to Section 5.2, “About Desktops and Templates” .

Each platform has slightly different requirements for selecting and managing templates. Oracle VDI offers template management for Oracle VM VirtualBox and Microsoft Hyper-V desktop pools. VMware Infrastructure, however, has its own template management conventions, so for this purpose, Oracle VDI offers access to the list of available templates in VMware vCenter.

For Oracle VM VirtualBox and Microsoft Hyper-V desktop pools, Oracle VDI also offers template revisions. Template revisions facilitate the proliferation of software updates and other changes to pools of cloned desktops. Oracle VDI saves a revision history of your templates. You can use template revisions to add software applications, to correct errors, and to provide fresh instances of a given desktop. You can also test revisions before cloning on a large scale and revert to earlier revisions if needed.


It is best to perform virus scanning on templates and the storage rather than on individual desktops. Local virus scanning adversely affects desktop performance by consuming both CPU and memory resources.

When a template is upgraded and declared as the new master revision, Oracle VDI deletes and replaces desktops that are not assigned to a user and those desktops that are in an idle state (see Section, “Desktop States” with a new version based on the new master template.

However, desktops that are in use at the time are not affected by the template revision mechanism until the user logs out. When the user logs out, the desktop reverts to an idle state. At that point, the desktop is deleted and replaced with a new version.

Nominating a new master for desktop cloning is not an immediate operation but rather a scheduled one. You can set the date and time when existing desktops should be replaced, and you can determine whether desktops in use are recreated at the scheduled time, or when the user logs out and the desktop returns to an idle state. To avoid disrupting the work of connected users, be sure to schedule the master revision change at a time when the load on the desktop pool is limited.

Figure 5.1. Templates and Revisions

Diagram showing templates and revisions, and desktops in pools created from the designated master.

5.2.3. About Desktop and Virtual Machine States

In Oracle VDI, a user is assigned to one or several virtual desktops and can use these desktops from everywhere as if they were running on a traditional personal computer. Oracle VDI provides advanced management and lifecycle features which allow the effective management of thousands of desktops. Desktops transition through states defined by settings in Oracle VDI.

Virtual machines are used to run the operating systems which render the desktops. They are controlled by a hypervisor, such as Oracle VM VirtualBox, Microsoft Hyper-V, and VMware Infrastructure. They cycle through traditional machine states such as powered off and running. Virtual Machine States

Virtual machine states are defined by the virtualization platform.

  • Running

    Running desktops are registered and started on a single hypervisor host. The host that a virtual machine is running on can be determined using the Desktop Summary page in Oracle VDI Manager. A running virtual machine is connected directly to the storage.

  • Powered Off

    Powered off virtual machines reside in two places in the Oracle VDI environment, the database and the storage. The Oracle VDI database contains the desktop configuration information to register the desktop on a hypervisor. The storage server contains the desktop's hard disk data.

    Powered off virtual machines are typically not associated or registered on any hypervisor host. This strategy enables Oracle VDI to select the best suited host on every start of a virtual machine. This setup helps ensure a distribution of virtual machines across the available VirtualBox or Microsoft Hyper-V hosts minimizing resource usage on each.

  • Suspended

    Suspended virtual machines have been suspended by the hypervisor.

  • Paused, Aborted, or Stuck

    These machine states are specific to VirtualBox.

  • Unknown

    This state typically indicates that either a VMware vCenter server cannot be contacted to retrieve the state information, or a VirtualBox host returns null.

  • Active or Disconnected

    These machine states apply to Microsoft Remote Desktops only. Oracle VDI does not control the machine state, just the connection to the desktop. Desktop States

The desktop states are used to accomplish the following:

  • Implement the desktop lifecycle.

  • Synchronize Oracle VDI hosts and virtualization platform.

  • Serve as a tool for monitoring and analyzing the system state.

The following figure depicts a simplified version of the lifecycle of a flexibly assigned desktop.

Figure 5.2. Lifecycle of a Flexibly-Assigned Desktop

The diagram shows the lifecycle of a desktop, from being cloned from a template, then alternating between the used and idle states, and then finally being recycled or deleted.

Possible desktop states are:

  • Available - The first state

    A desktop is added to the database and then set to the Available state after being cloned from a template. After becoming Available, the desktop is ready to be assigned to users. If the recycle policy is set to Reuse Desktop or Reset to Snapshot, the desktop is returned to this state.

  • Idle - The intermediate state

    The desktop is in this state whenever the desktop is assigned and the user is not using it, for example, when the desktop is assigned and the user has not logged in yet or when the desktop is assigned and the user just logged out. A desktop is recycled after it remains in that state for a configurable amount of time.

    The VMware vCenter desktop provider has two additional Idle states: when the desktop is assigned and either the virtual machine is suspended or the guest OS goes into standby through the vCenter option Keep VM Running on Guest OS Standby.

  • Used - The active state

    A desktop enters the Used state as soon as the user has logged in to the desktop. The desktop stays in this state while the user logs in, uses the desktop, and logs out.

  • Reserved - The maintenance state

    A desktop is Reserved when it is being worked on by Oracle VDI. This desktop state usually occurs when the desktop is the source of a manual copy operation or the desktop is recycled. The desktop becomes Available after leaving the Reserved state.

  • Unresponsive - The quarantine state

    The desktop enters the Unresponsive state whenever Oracle VDI determines a severe problem with the desktop. An unresponsive desktop is outside the desktop lifecycle and is either automatically deleted (flexible desktops only) or it requires manual action by an administrator. See Section, “Unresponsive Desktops” for more details. Unresponsive Desktops

When a desktop is in the Unresponsive state, users cannot access that desktop until the desktop state changes. The state can be changed as the result of automatic processing by Oracle VDI, or it can be the result of a manual action by an Oracle VDI administrator, for example if an administrator puts a storage in maintenance mode.

Although a desktop's state is shown as Unresponsive, Oracle VDI actually differentiates between whether the desktop is simply unresponsive, for example because the storage is unresponsive, or whether the desktop is defective.

Only unresponsive or defective personal desktops require manual actions.

If the cause of the unresponsive or defective state is removed, for example because the storage becomes responsive, the desktop is automatically returned to its normal state in the desktop lifecycle. This applies to personal and flexible desktops.

If a flexible desktop is defective, the desktop remains in the Unresponsive state for 60 minutes and then it is automatically deleted.

If a flexible desktop is unresponsive, the desktop remains in the Unresponsive state for the duration specified by the unresponsive desktop timeout and then it is automatically deleted. The default unresponsive desktop timeout is 30 minutes. The unresponsive desktop timeout is configurable, as follows:

/opt/SUNWvda/sbin/vda settings-setprops -p desktop.unresponsive.timeout=mins

The manual actions an Oracle VDI administrator can perform on a desktop in the Unresponsive state are: