Runtime VM Cloning via Application-Initiated Fork

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Traditional virtual machine creation requires administrative effort, limiting the use of virtualization in environments where short-lived virtual machines are needed, such as for testing, and increasing security and development costs due to the lack of isolated execution environments.

Innovation Solution

A virtual machine generator that dynamically creates virtual machines during runtime, allowing applications to invoke VM creation through a 'vmfork' operation, which clones a running VM, allocates necessary resources, determines the location for the clone, and copies the state of the original VM, enabling efficient and automated VM creation without human intervention.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional administrative VM creation is used, then VM isolation and security are improved, but operational complexity and time consumption increase

Engineering Contradiction:
ImprovesecurityVSAvoidoperational complexity
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The system enables applications to automatically request and create VM clones through the vmfork operation without requiring administrator intervention. The application itself serves as the requester and beneficiary, eliminating the need for manual administrative actions while maintaining security through the hypervisor-enforced isolation boundaries.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The base VM is pre-configured with necessary security configurations, isolation settings, and hardware mappings before cloning operations. This preliminary setup ensures that all cloned VMs inherit proven secure configurations, maintaining reliability while enabling rapid automated deployment without requiring administrators to reconfigure security settings for each new VM.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If traditional administrative VM creation is used, then VM isolation and security are improved, but time consumption increases

Engineering Contradiction:
ImprovesecurityVSAvoidtime consumption
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system creates VM clones by copying the state and configuration of an existing base VM through the vmfork operation. This copying mechanism rapidly replicates proven secure VM configurations without requiring time-consuming administrative setup procedures, reducing deployment time while maintaining security through inheritance of isolation settings.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

Security configurations, hardware mappings, and isolation settings are pre-established in the base VM before cloning operations begin. This preliminary action ensures that all subsequent clones inherit these secure configurations immediately, eliminating the time required for administrators to manually configure security settings for each new VM.

Inventive Principle:
Principle #10Preliminary action

3Productivity

If automated VM creation is implemented, then operational efficiency is improved, but resource allocation complexity increases

Engineering Contradiction:
Improveoperational efficiencyVSAvoidresource allocation complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The base VM serves as a universal template that can be cloned multiple times for different applications and purposes. The vmfork operation provides a universal interface for resource allocation that handles hardware mapping, memory allocation, and CPU assignment automatically, simplifying resource management while enabling high operational efficiency through repeated cloning operations.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The hypervisor acts as an intermediary between the application's vmfork request and the physical hardware resources. It automatically handles the complex resource allocation, mapping virtual hardware to physical resources, and managing memory and CPU assignment, thereby hiding the complexity of resource management from applications while enabling efficient automated VM creation.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Adaptability or versatility

If VM cloning is performed dynamically, then adaptability is improved, but system complexity increases

Engineering Contradiction:
ImproveadaptabilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system enables dynamic VM cloning where applications can request VM creation at runtime based on actual needs. The vmfork operation dynamically allocates resources, maps hardware configurations, and creates isolated environments on-demand, providing high adaptability to changing application requirements while the hypervisor manages the underlying system complexity automatically.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The hypervisor serves as an intermediary that manages the complexity of dynamic resource allocation, hardware mapping, and VM state management. It receives simple vmfork requests from applications and automatically handles the complex tasks of resource provisioning and configuration, thereby enabling system adaptability without requiring applications to manage the underlying complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS8336046B2Dynamic VM cloning on request from application based on mapping of virtual hardware configuration to the identified physical hardware resources
Publication Date: 2012.12.18 INTEL CORP
  • US8336046B2 patent drawing
  • US8336046B2 patent drawing
  • US8336046B2 patent drawing

AI summary

Methods and apparatuses enable creation of a virtual machine (VM) clone initiated through application or service logic. The application requests generation of a VM clone from within the runtime execution of the application. The request is serviced by a VM generator, which identifies a state of the VM to clone and identifies hardware resources on which to create the VM clone. Based on a determination of what resources on which to generate the VM clone, the VM generator creates the VM clone on the determined resources, having the identified state. In one embodiment, a use case of resource copy or reference copy is selected for each resource. In one embodiment, the VM generator considers a number of factors in determining where to instantiate the VM clone. The parameters may include hints or preference parameters sent by the application and/or resource loading or performance.