Virtual Storage Address Translation in Proprietary Hypervisors
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Proprietary virtualization hypervisors do not provide mechanisms for third-party software or physical device manufacturers to translate or map virtual storage device addresses to physical device addresses, limiting the ability to add value or functionality to I/O streams without destabilizing the hypervisor or relying on proprietary mechanisms.
Innovation Solution
A method that adds functionality at both the virtual storage device layer and the physical storage device driver layer to translate virtual storage device addresses to physical storage device addresses, allowing third-party software or physical devices to manage I/O processing without the proprietary hypervisor's support, by recording contextual information and using it to determine the mapping from virtual to physical addresses.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If third-party software or physical device manufacturers attempt to add functionality to proprietary virtualization hypervisors by modifying core intellectual property, then additional functionality can be added to I/O streams, but the hypervisor stability deteriorates and legal issues arise
Solution Approach 1:
The patent introduces an intermediary mechanism in the form of a translation layer that sits between the virtual storage device address space and the physical storage device address space. This intermediary enables third-party software and physical device manufacturers to add functionality without directly modifying the proprietary hypervisor core. The translation mechanism captures I/O requests, determines virtual-to-physical address mappings, and forwards requests appropriately, thereby mediating between external functionality additions and internal hypervisor stability.
2Adaptability or versatility
If reverse engineering and patching of the proprietary virtualization hypervisor is attempted to provide translation functionality, then mapping capability can be achieved, but technical and legal risks increase and the approach is prone to failure with new releases
Solution Approach 1:
The patent segments the address translation functionality into a separate, independent component that operates alongside the proprietary hypervisor rather than within its core. By dividing the system into distinct functional layers (virtual storage device layer, translation mechanism, physical storage device layer), the invention eliminates the need for reverse engineering and patching the hypervisor core. This segmentation allows the translation capability to be added as a standalone module that works with the hypervisor without modifying its internal structure.
3Adaptability or versatility
If the proprietary file system mapping mechanisms are accessed directly, then translation functionality can be provided, but the system becomes dependent on unpublished, proprietary, or changing mechanisms
Solution Approach 1:
The patent extracts the address translation functionality from the proprietary file system mechanisms and creates an independent translation layer. Instead of relying on the hypervisor's internal file system mappings which are unpublished and may change, the invention captures I/O requests before they enter the proprietary file system, determines the virtual-to-physical address mappings externally, and forwards the requests. This extraction eliminates dependency on the proprietary mechanisms while maintaining translation capability.
Data Source
AI summary
A method and system to translate virtual storage device addresses to physical storage device addresses without the cooperation of the proprietary virtualization hypervisor is disclosed herein. The method of the present invention allows additional functionality to be added to the I/O processing of a closed/proprietary virtualization hypervisor by third party software or physical storage devices on the basis of individual virtual storage devices.