Virtual Disk Swapping for VM Software Upgrades
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current software upgrade processes for large-scale virtual machine (VM) deployments in SaaS environments face issues such as increased network load, storage bloat, and difficulty in tracking patch status due to concurrent patch downloads and applications, leading to potential failures and performance issues.
Innovation Solution
The approach involves creating a template VM with an initial software binary VMDK and cloning it to create linked clone VMs, which are then upgraded by swapping the original software binary VMDK with a new one containing the updates, eliminating the need for each VM to download and apply patches independently.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If each VM downloads and applies patches independently from a central update server, then the software can be upgraded in each VM, but the network load on the central update server increases significantly and download speeds decrease
Solution Approach 1:
The patent merges the patch storage and distribution function into the virtual disk image itself. Instead of each VM downloading patches independently from a central server, the patched virtual disk image is created once and then copied to multiple VMs simultaneously, combining the distribution process into a single operation that serves all VMs.
Solution Approach 2:
The patent uses copying of the patched virtual disk image to multiple VMs instead of having each VM download patches separately. The virtual disk image containing the software update is copied to the appropriate VMs, which significantly reduces network bandwidth consumption compared to individual patch downloads.
2Reliability
If each VM downloads and stores patches independently, then the software can be upgraded, but storage bloat occurs due to multiple patch copies in backend storage
Solution Approach 1:
The patent merges the patch data into a single virtual disk image that is then copied to multiple VMs. This approach consolidates the patch storage into one location (the patched VMDK file) rather than storing separate patch files for each VM, significantly reducing backend storage consumption.
Solution Approach 2:
Instead of storing multiple patch copies in backend storage, the patent creates one patched virtual disk image and copies it to the necessary VMs. This copying approach reduces storage bloat by eliminating redundant patch files while still providing update capability to all VMs.
3Productivity
If many VMs attempt to apply resource-intensive patches concurrently, then the software can be upgraded across the infrastructure, but host-side performance issues occur
Solution Approach 1:
The patent performs the resource-intensive patching operation in advance by creating a patched virtual disk image before deploying it to multiple VMs. This preliminary action consolidates the computational burden into a single pre-processing step, allowing concurrent deployment to multiple VMs without overwhelming host system resources during the actual update process.
4Productivity
If a large number of VMs are in the process of applying patches, then the infrastructure can be upgraded, but it becomes difficult to track the status of each VM to identify and address patch failures
Solution Approach 1:
The patent extracts the patch data from individual VM operations and consolidates it into a centralized patched virtual disk image. This extraction approach allows the system to track updates at the image level rather than monitoring individual patch applications in each VM, significantly simplifying status tracking for large-scale deployments.
Data Source
AI summary
In one embodiment, a computer system creates a first template VM that includes a first OS VMDK and a first software binary VMDK, and clones the first template VM to create a linked clone VM. The linked clone VM executes a guest OS by accessing the first OS VMDK and a software application by accessing the first software binary VMDK. The computer system further creates a second template VM that includes a second software binary VMDK, where the second software binary VMDK includes one or more upgrades to the software application that are not included in the first software binary VMDK. The computer system then detaches the first software binary VMDK from the linked clone VM and attaches the second software binary VMDK to the linked clone VM. The linked clone VM thereafter executes the software application by accessing the second software binary VMDK.