DETAILED ACTION
Claims 1-21 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 10/27/2023 and 01/31/2024 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Objections
Claim 1 is objected to because of the following informalities:
The preamble of claim 1 states “a virtue machine” which appears to be a typographical error. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The following claim language is unclear:
Claims 1, 9 and 10 recite “separately switching a first descriptor structure of the virtual machine to be upgraded and a second interrupt descriptor structure of the target virtual machine from a kernel state to a user state” it is unclear from the context of the claim what interrupt descriptor structures are and how can they be switched. For examination purposes, examiner interprets the interrupt descriptor structures as pointers, copies, or other, used to allow the created target machine to operate as if it was the virtual machine being migrated.
Claims 2-7, 11-21 are dependent on these independent claims and fail to cure the deficiencies set forth above for claims 1, 9 and 10.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 7, 9-13, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Saxena et al. (US 2021/0157624 A1) in view of Yuan et al. (US 2020/0401392 A1).
Regarding claim 1, Saxena teaches a hot-upgrading method for a virtue machine (Abstract: The disclosed techniques can be applied during an upgrade of a multi-node cluster when upgrading cluster software and/or hardware. Techniques applied include pausing a virtual machine (VM) at a first node, then communicating then-current states of the paused VM to a second node that executes a migrated clone of the paused VM. While the migrated cloned VM is running at the second node, changes to states of the cloned VM are tracked. When the upgrade of the first node has completed, then when migrating the cloned VM back to the first node, only the tracked state changes of the cloned VM are sent from the second node to the first node.; See Controller Virtual Machine Upgrade Scenario [0027] and Kernel Upgrade Scenario [0028]; Examiner notes that while Saxena teaches upgrading of virtual machines/software as cited above, the majority of examples provided in Saxena’s disclosure focusses on node/hardware upgrades. As such, although the citations will mostly show the hardware example, reference to the Abstract and [0027-28] is intended to link the example to the software upgrade aspect), wherein comprising:
creating a target virtual machine for a virtual machine to be upgraded ([0061] The destination node participates in the forward migration and cloning of the subject VM or VMs (step 313). [0067] The aforementioned live migration steps serve to communicate the VM's memory state and device states to a destination node. Such VM's memory state and device states are stored at the destination node so as to create a runnable clone of the VM at the destination node. The cloned VM is unsuspended and continues to run at the destination node (operation 12).);
causing an interrupt descriptor structure address of the second interrupt descriptor structure to point to an interrupt descriptor structure address of the first interrupt descriptor structure, so that the target virtual machine inherits interrupt descriptor information of the virtual machine to be upgraded (Fig. 1A, elements 130, 134, 142; [0034] The figure depicts a multi-node virtualized system 101 that is to be subjected to a maintenance cycle. As shown, in the forward migration path from a source node (e.g., Node1) to a destination node (e.g., Node2), all virtual memory pages 130 (e.g., page0, page1, page2, . . . , pageN−1, pageN) and all device states 134 (e.g., device1 state, . . . , deviceN state) are communicated from the source node to the destination node; [0036] In this and other embodiments, operations are performed to maintain instances of preserved states 140 at a source node (e.g., Node1) and to capture instances of tracked states 142 at a destination node (e.g., Node2). More specifically, and as shown, (1) the aforementioned instances of preserved states derive from Node1's VM memory 102 and from Node1's VM devices 104 when the VM is in a paused state, and (2) the aforementioned instances of tracked states derive from Node2's changed memory pages 112 and from Node2's changed device states 114, which changes happen when the migrated VM is running at Node2.; [0041]; [0077-78]); and
running the target virtual machine, based on a task process in the virtual machine to be upgraded, to implement hot upgrade of the virtual machine to be upgraded ([0036] In this and other embodiments, operations are performed to maintain instances of preserved states 140 at a source node (e.g., Node1) and to capture instances of tracked states 142 at a destination node (e.g., Node2).; [0038] To accomplish this sort of forward migration of a VM, followed by an upgrade of the source node; Fig. 1B, Steps 2, 3, 4, 5 Perform reboot-free upgrade; the upgrade is performed while the clone VM handles all processing to avoid downtime; Fig. 3, Step 315 Run the cloned virtual machines on the second node while keeping track of changed memory pages and changed device states).
PNG
media_image1.png
507
669
media_image1.png
Greyscale
Saxena does not explicitly teach separately switching a first interrupt descriptor structure of the virtual machine to be upgraded and a second interrupt descriptor structure of the target virtual machine from a kernel state to a user state.
However, Yuan teaches separately switching a first interrupt descriptor structure of the virtual machine to be upgraded and a second interrupt descriptor structure of the target virtual machine from a kernel state to a user state ([0025] For reasons of adding a new function, fixing an error in the existing application 120, improving the running efficiency, and the like, the application 120 may often be upgraded. In this case, how to minimize interruption time of the application 120 becomes crucial, especially for applications requested to run in 24 hours without interruption. For the ease of description, example implementations of the present disclosure will be described merely with a network virtualization management application as an example in the context of the present disclosure. For example, openvswitch may provide support for network virtualization in the virtualization scenario. There are two modes in actual deployment: in an ovs-kernel mode, the processing is completed by an operating system; in an ovs-dpdk mode, the processing is switched from a kernel state to a user state.; [0027]; [0028] In still another technical solution, a new ovs-vswitchd process is started during upgrading, and the new process may occupy the same amount of resources as the original process. This technical solution can further reduce the interruption time. However, since the solution needs to occupy a lot of resources and can only be applied to the ovs-dpdk mode, it is unable to provide a universal technical solution of upgrading.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yuan with the teachings of Saxena to perform a switching from kernel stat to user state during an upgrading process. The modification would have been motivated by the desire of allowing a secondary system i.e., clone to be able to execute the functions of the system being upgraded.
Regarding claim 2, Saxena teaches wherein after creating the target virtual machine for the virtual machine to be upgraded, the method further comprises: configuring the interrupt descriptor structure address for the created second interrupt descriptor structure of the target virtual machine based on a memory page requested from a memory pool ([0025] Phase 3: Track VM changes on the destination node. Indicate to the destination node that the VMs are temporarily running in the destination node so as to accomplish an upgrade of the source node. Responsive to the indication that the VMs are temporarily running in the destination node so as to accomplish an upgrade, and while running the VMs at the destination node, the changed memory pages are noted. Any changes made to any VMs memory is noted (e.g., the changed pages are marked as “dirty”). The virtual machines continue to run as normal, and separate metadata is maintained to record the existence and identification of changed memory pages and/or changed device states. In some cases, only a few memory pages and/or device states are modified during the VMs' temporary tenure on the destination node.; [0112] memory pool).
Regarding claim 3, Saxena teaches wherein causing the interrupt descriptor structure address of the second interrupt descriptor structure to point to the interrupt descriptor structure address of the first interrupt descriptor structure, so that the target virtual machine inherits interrupt descriptor information of the virtual machine to be upgraded comprises: using the interrupt descriptor structure address of the first interrupt descriptor structure to replace the interrupt descriptor structure address of the second interrupt descriptor structure, so that the target virtual machine inherits the interrupt descriptor information of the virtual machine to be upgraded ([0025]).
Regarding claim 4, Saxena teaches wherein after causing the interrupt descriptor structure address of the second interrupt descriptor structure to point to the interrupt descriptor structure address of the first interrupt descriptor structure, so that the target virtual machine inherits interrupt descriptor information of the virtual machine to be upgraded, the method further comprises: initializing the target virtual machine ([0023] starting the forward migrated VM at destination node.); and retaining contents in the second interrupt descriptor structure during a process of initializing the target virtual machine ([0023] Phase 2: Initiate forward migration of the VMs on the node to be upgraded. In example cases the migration of a particular VMs is a “live” migration such that a particular VM to be migrated runs at the source node until most of the image of the to-be-migrated VM has been transferred to the destination node. When most of the image of the to-be-migrated VM has been transferred to the destination node, then pause the VM at the source node, complete the transfer of the remaining portions of the image of the to-be-migrated VM from the source node to the destination node, then pausing the VM at the source node, and starting the forward migrated VM at destination node.).
Regarding claim 7, Saxena teaches wherein running the target virtual machine based on a task process in the virtual machine to be upgraded to implement hot upgrade of the virtual machine to be upgraded comprises: calling, through a fork function and an execution function, the task process in the virtual machine to be upgraded to the target virtual machine that is started for execution, so as to start the target virtual machine to implement hot upgrade of the virtual machine to be upgraded ([0077] At step 604, service routines that correspond to the context are registered (step 606). The service routines operate in parallel within a FORK/JOIN block. Specifically, and as shown, a first service routine 608 serves to continuously monitor page changes, a second service routine 610 serves to continuously monitor device state changes, and third service routine 612 serves to continuously check for a signal that indicates completion of the reboot-free actions. When such a signal is received, then service routine 608 and service routine 610 are signaled to drop into the JOIN. [0078] At step 613, changes that had been detected during processing within the FORK JOIN block are summarized and stored into data structures that are used by the source node to apply the changes to the preserved memory of the source node. Strictly as an example, the data structures may include the then-current contents of a set of virtual memory pages that had been detected as changed. As another example, the then-current contents of a particular virtual memory page can be compared to the contents of the same memory page as was received at the destination node in the forward migration. The differences can then be codified into a data structure to indicate the exact change or changes within a virtual memory page. In some cases, the exact change or changes can be described as a numeric offset (e.g., a byte or word offset) within a subject memory page, followed by a numeric length (e.g., a byte count or a word count) that serves to bound the beginning and end of the range of changes, followed by the changed data in an amount that corresponds to the specified range.).
Regarding claim 9, it is a system type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above. Further the additional limitations An electronic device, comprising: a processor, a memory storing machine-readable instructions executable by the processor, and a bus, wherein when the electronic device is running, the processor and the memory communicate through a bus; and when the machine-readable instructions are executed by the processor cause the processor to are taught by Saxena in at least claim 17 “A system for situation-aware virtual machine migration, the system comprising: a storage medium having stored thereon a sequence of instructions; and a processor that executes the sequence of instructions to cause the processor to perform acts”.
Regarding claim 10, it is a media/product type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 11-13 and 16, they are system type claims having similar limitations as claims 2-4 and 7 respectively. Therefore, they are rejected under the same rationale above.
Regarding claim 17-19, they are media/product type claims having similar limitations as claims 2-4 respectively. Therefore, they are rejected under the same rationale above.
Claims 5-6, 14-15 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Saxena and Yuan, as applied above, in further view of Riel (US 9,588,976 B1).
Regarding claim 5, Saxena teaches a process of live migration in which the source VM is paused to complete the transfer of remaining portions of the image of the to-be-migrated VM from the source node to the destination node. Saxena nor Yuan explicitly teach wherein the method further comprises: prohibiting updating an interrupt remapping table entry of the target virtual machine during the process of initializing the target virtual machine.
However, Riel teaches wherein the method further comprises: prohibiting updating an interrupt remapping table entry of the target virtual machine during the process of initializing the target virtual machine (Col. 8, lines 29-34: In one example, the migration of the first portion 222 may involve preventing changes during the migration and changes to first portion 222 that arrive during the migration may be denied (e.g., produce errors) and may be resubmitted after the migration completes.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Riel with the teachings of Saxena and Yuan to prevent changes being made while migrating an application/VM. The modification would have been motivated by the desire of ensuring transferred data is consistent when the application is resumed at a destination environment.
Regarding claim 6, Riel teaches wherein the method further comprises: retaining an interrupt request data in the interrupt descriptor structure of the target virtual machine during the process of initializing the target virtual machine (Col. 8, lines 34-38: In another example, the migration of first portion 222 may be a live migration that does not prevent changes during the migration and may queue the changes during the migration and replay the changes after the migration completes.).
Regarding claim 14-15, they are system type claims having similar limitations as claims 5-6 respectively. Therefore, they are rejected under the same rationale above.
Regarding claim 20-21, they are media/product type claims having similar limitations as claims 5-6 respectively. Therefore, they are rejected under the same rationale above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee J Li can be reached at (571)272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195