Hibernated Pre-launch Session Management for Virtual Machines
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The quality of user experience diminishes when virtual machines need to generate additional pre-launch sessions to meet user requests for access to virtual computing environments, and the cost of hosting surplus pre-launch sessions increases as their number grows.
Innovation Solution
A virtual machine uses a session predictor and controller to predict the need for pre-launch sessions, generating or hibernating them based on demand, allowing hibernated sessions to be activated only when needed, thus reducing wait times and network resource consumption.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the virtual machine generates additional pre-launch sessions to meet user requests, then the user experience quality improves, but the hosting cost increases
Solution Approach 1:
The system dynamically adjusts the state of pre-launch sessions between active and hibernated based on real-time demand. When user requests exceed available sessions, the system activates hibernated sessions; when demand is low, sessions are hibernated to save resources. This dynamic state management resolves the contradiction by making the system adaptable to varying load conditions.
Solution Approach 2:
The system performs preliminary actions by hibernating pre-launch sessions in advance during low-demand periods, preparing them for quick activation when demand increases. This allows the system to have sessions ready beforehand without paying the full cost of keeping them continuously active, thus improving responsiveness while controlling costs.
2Loss of time
If the virtual machine generates a surplus of pre-launch sessions prior to receiving user requests, then the user can connect immediately, but the hosting cost increases as the number of pre-launch sessions increases
Solution Approach 1:
The system changes the operational parameter of pre-launch sessions from a static binary state (active/inactive) to a three-state model (active, hibernated, deleted). Hibernated sessions retain their configuration and can be quickly activated, whereas deleted sessions free up resources. This parameter expansion allows the system to optimize between responsiveness and cost by selectively hibernating rather than deleting sessions.
Solution Approach 2:
Different pre-launch sessions are assigned different states (active, hibernated, or deleted) based on local conditions such as predicted demand, current load, and session age. This localized quality assignment allows the system to maintain high-quality service for anticipated demand while economizing on sessions that are unlikely to be used.
3Speed
If the virtual machine keeps pre-launch sessions in a running state to satisfy user requests, then the connection speed is fast, but the network resources are consumed continuously
Solution Approach 1:
Instead of continuously maintaining all sessions in a running state, the system employs periodic activation of hibernated sessions based on demand patterns. Sessions are activated periodically when needed and can be hibernated when not in use, creating a rhythmic on-demand activation pattern that reduces continuous resource consumption while maintaining readiness.
Data Source
AI summary
Methods and systems for launching sessions within virtual machine instances using hibernated pre-launch sessions are described herein. A controller may compare a number of pre-launch sessions needed at a first time to a number of available pre-launch sessions. Based on the number of pre-launch sessions needed at the first time exceeding the number of available pre-launch sessions, the controller may generate and hibernate additional pre-launch sessions. The controller may compare the number of pre-launch sessions needed at the first time to a number of pre-launch sessions needed at a second time. Based on the number of pre-launch sessions needed at the first time exceeding the number of pre-launch sessions needed at the second time, the controller may delete pre-launch sessions. Based on the number of pre-launch sessions needed at the second time exceeding the number of pre-launch sessions needed at the first time, the controller may hibernate pre-launch sessions.