Speculative VM Resource Scheduling via Lockstep Duplication

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing virtual machine schedulers base migration decisions on past resource usage, leading to potential incorrect decisions and costly resource wastage and time delays due to the time-consuming nature of VM migration.

Innovation Solution

A speculative virtual machine resource scheduler creates duplicate VMs on secondary hosts and runs them in lockstep with the primary VM, allowing real-time resource monitoring to determine the most advantageous host for continued operation, thereby enabling instantaneous migration based on current resource availability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If VM migration decisions are based on past resource usage, then scheduling simplicity is maintained, but decision accuracy deteriorates leading to incorrect migration decisions

Engineering Contradiction:
Improvescheduling complexityVSAvoidmigration decision accuracy
Core Design Contradiction:
Device complexityVSMeasurement precision

Solution Approach 1:

The system performs preliminary actions by creating duplicate VM instances on secondary hosts before making final migration decisions. These duplicate VMs are run in lockstep with the primary VM, allowing the system to evaluate current resource conditions and predict future performance without committing to migration until the decision is confirmed advantageous.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system creates duplicate copies of the VM on secondary hosts to evaluate migration potential. These copies allow the system to test resource compatibility and performance predictions without affecting the primary VM operation, enabling accurate decision-making based on actual current conditions rather than historical data alone.

Inventive Principle:
Principle #26Copying

2Speed

If VM migration is performed based on historical data, then processing speed is maintained, but resource allocation efficiency deteriorates due to time delays

Engineering Contradiction:
Improvemigration processing speedVSAvoidresource allocation efficiency
Core Design Contradiction:
SpeedVSProductivity

Solution Approach 1:

The system performs preliminary resource evaluation and duplicate VM execution in parallel with the primary VM operation. This allows migration decisions to be made rapidly based on current real-time conditions rather than historical data, simultaneously improving processing speed and resource allocation efficiency.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system continuously monitors resource conditions and performance metrics of duplicate VMs, using this feedback to make informed migration decisions. This real-time feedback mechanism enables both fast processing and efficient resource allocation by base(ing) decisions on current actual conditions rather than outdated historical information.

Inventive Principle:
Principle #23Feedback

3Measurement precision

If duplicate VMs are created and run in lockstep for speculative scheduling, then migration decision accuracy is improved, but device complexity increases

Engineering Contradiction:
Improvemigration decision accuracyVSAvoidscheduling system complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The system creates duplicate copies of the VM to evaluate migration options. While this increases complexity, the copies are run in lockstep using efficient synchronization mechanisms and can be terminated once a decision is made, limiting the duration and impact of the additional complexity.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The duplicate VMs are run in lockstep with the primary VM, allowing continuous evaluation of resource conditions without interrupting service. This continuous parallel operation enables accurate migration decisions while maintaining system availability and minimizing the functional impact of the increased complexity.

Inventive Principle:
Principle #20Continuity of useful action

4Productivity

If real-time resource monitoring is implemented for speculative scheduling, then resource allocation efficiency is improved, but energy consumption increases

Engineering Contradiction:
Improveresource allocation efficiencyVSAvoidmonitoring energy consumption
Core Design Contradiction:
ProductivityVSUse of energy by moving object

Solution Approach 1:

The system implements partial monitoring by focusing resources on monitoring only those hosts and resources relevant to potential migration decisions, rather than monitoring the entire infrastructure continuously. This selective monitoring approach maintains resource allocation efficiency while reducing overall energy consumption compared to comprehensive continuous monitoring.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The system performs preliminary evaluation using duplicate VMs that consume resources locally on secondary hosts, reducing the need for continuous real-time monitoring and data transfer across the network. This preliminary action approach improves resource allocation efficiency while minimizing the energy required for ongoing monitoring.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS8019861B2Speculative virtual machine resource scheduling
Publication Date: 2011.09.13 VMWARE INC
  • US8019861B2 patent drawing
  • US8019861B2 patent drawing
  • US8019861B2 patent drawing

AI summary

A speculative virtual machine (“VM”) resource scheduler for a VM that is hosted by a primary host server initiates the creation of at least one duplicate VM on a secondary host server. The VM and the duplicate VM are run substantially in lockstep while the scheduler monitors resources on the primary host server and the secondary host server. The scheduler then determines an advantageous host server among the primary host server and the secondary host server and, based at least in part on the determination, initiates the powering down of either the VM on the primary host server or the duplicate VM on the secondary host server.