Thin Client GUI Reinitialization via Virtual Desktop Monitoring
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional network-based computer architectures face inefficiencies due to underutilization of resources and complex management, particularly in thin or zero client systems where users must power down and restart the client to reboot the local graphical user interface after terminating a virtualized desktop session, resulting in wasted time and resources.
Innovation Solution
A computing device with a system on chip, video card, and RAM, configured to communicate with a virtual machine hosted by a remote hypervisor, includes a monitoring application that determines the execution status of a virtual desktop client and reinitializes or relaunches the local graphical user interface upon termination, allowing seamless switching between local and virtual machine interfaces without powering down the device.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If the local graphical user interface is terminated to access the virtualized desktop, then resource utilization is improved, but the ability to access the local GUI is lost and the entire system must be powered down to reboot
Solution Approach 1:
The system separates the local GUI process from the virtual desktop client process, allowing them to be independently managed. The local GUI can be terminated when entering virtual desktop mode, and independently restarted when needed, without affecting the entire system or requiring a full power cycle.
Solution Approach 2:
The local GUI is kept in a suspended or saved state in memory before termination, allowing for quick restoration. This preliminary preservation of state enables the GUI to be rapidly reinitialized without full system reboot, maintaining both resource efficiency and operational flexibility.
2Ease of operation
If the entire thin client is powered down and restarted to reboot the local GUI, then the local GUI can be accessed, but time and system resources are wasted
Solution Approach 1:
The local GUI state is preserved in memory before termination, and a restart process is initiated that only reloads the GUI components rather than the entire system. This preliminary preservation and selective restarting dramatically reduces the time required to access the local GUI compared to a full system reboot.
Solution Approach 2:
The local GUI restart process is extracted from the full system reboot process. Only the necessary GUI components and processes are reinitialized, while other system functions remain active, thereby reducing overall reboot time and resource consumption.
3Ease of operation
If the entire thin client is powered down and restarted to reboot the local GUI, then the local GUI can be accessed, but system resources are wasted
Solution Approach 1:
The system divides the restart operation into segmented components, where only the local GUI process is terminated and restarted rather than the entire system. This allows other system components to remain active and avoid unnecessary power consumption associated with a full system shutdown and restart cycle.
Solution Approach 2:
The GUI restart function is extracted as an independent operation from the full system power cycle. This extraction enables the system to maintain power to essential components while only cycling the GUI subsystem, thereby reducing overall energy waste while still providing access to the local interface.
Data Source
AI summary
Technologies are described herein for alternating between a local graphical user interface (UI) and a virtual machine interface, on a computing device such as a thin client or a zero client. In particular, a virtual desktop client (VDC), which is in communication with a virtual machine hosted by a hypervisor on a remote computer system, receives desktop video display signals from the virtual machine. A monitoring application monitors the execution status of the VDC. Upon determining that the VDC has been terminated, the monitoring application is configured to present the UI by re-initializing, relaunching, or rebooting the UI, by retrieving display data associated with the UI from a RAM device, or by other means.


