DETAILED ACTION
Claims 1-20 are pending in this application.
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 .
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, 8, 9, 12, 17, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2013140524 A1 to Shimada et al. in view of U.S. Pat. No. 10,949,241 B2 issued to Hildebrand et al. and further in view of U.S. Pub. No. 20120109897 A1 to Janakiraman et al.
As to claim 1, Shimada teaches A method to manage available capacity for a cloud service provider (CSP) (Cloud 100) and reduce capacity fragmentation, the method comprising:
determining hypervisors (HVs) (VMMs 91) and information associated with virtual machines (VMs) hosted by the HVs, wherein the information includes a number of the VMs (For example, the number of mountable VMs 92 is 24, but is not limited to this) and a type of the VMs for individual ones of the HVs (“…The physical server 2 includes virtualization software (VMM: Virtual Machine Monitor) 91 and a virtual machine (VM: Virtual Machine) 92. The VMM 91 is necessary software for operating the VM 92, and allocates resources such as a CPU (Central Processing Unit) and memory mounted on the physical server 2 to each VM 92. The number of VMMs 91 corresponds to the number of physical servers 2, but is not limited to the illustrated one and can be changed. For example, the number of VMMs 91 is 128, but is not limited thereto. In addition, the number of VMs 92 that can be mounted on one physical server 2 is not limited to that illustrated, and can be changed. For example, the number of mountable VMs 92 is 24, but is not limited to this…”);
determining HV candidates from the HVs for defragmentation (Step S31) (“…[Move source VMM selection processing procedure]…Next, the procedure of the migration source VMM selection process in step S22 in FIG. 10 will be described with reference to FIG. FIG. 11 is a flowchart illustrating a processing procedure for selecting a migration source VMM…The VM migration planning unit 23 acquires the VM configuration information for each VMM from the VM configuration information table 13 (step S31)…”);
determining one or more selected HVs from the HV candidates to defragment (Step S33) (“…Then, the VM migration planning unit 23 selects a VMM 91 whose degree of variation is not calculated (step S32). The variation degree is, for example, entropy…Subsequently, the VM migration planning unit 23 calculates the degree of variation in the memory usage frequency of the selected VMM 91 (step S33). For example, the VM migration planning unit 23 selects the VM 92 on the selected VMM 91 from the VM configuration information. Then, the VM movement planning unit 23 uses the trend period 12b for each selected VM 92 stored in the VM trend table 12 to indicate the degree of variation in the memory usage frequency for the trend period 12b of each VM 92 on the selected VMM 91. calculate…”); and
causing one or more VMs (VM 92) of the one or more selected HVs to be migrated to one or more different HVs to reduce a capacity fragmentation of the one or more selected HVs (Step S23) (“…First, the VM migration planning unit 23 determines whether or not a migration plan for the VM 92 has been requested (step S21). When it is determined that the movement plan for the VM 92 is not requested (step S21; No), the VM movement planning unit 23 repeats the determination process until the movement plan for the VM 92 is requested. On the other hand, when it is determined that the migration plan of the VM 92 is requested (step S21; Yes), the VM migration planning unit 23 selects the migration source VMM 91 (step S22)…Then, the VM migration planning unit 23 selects the VM 92 to be migrated from the VMs 92 on the selected VMM 91 (Step S23). Further, the VM migration planning unit 23 selects a migration destination VMM 91 to which the selected VM 92 is to be migrated (step S24)…”).
Shimada is silent with reference to wherein the information includes a type of the VMs for individual ones of the HVs and defragmentation based at least in part on the type of the VMs.
Hildebrand teaches wherein the information includes a type of the VMs for individual ones of the HV (VM Type 380) (“…The primary VM manager 322 at the VMM 320 may maintain an active log of each VM instance 350P deployed into the pool of primary VM instances 350P, the VM type 380 of each VM instance 350P, and the corresponding individual service instance 362 executing on each primary VM instance 350P…In some examples, all of the primary VM instances 350P in the pool of primary VM instances 350P include the same rate of unavailability. In other examples, the primary VM instances 350P associated with the type A VM type 380 include a rate of unavailability that is different than a rate of unavailability for the primary VM instances 350P associated with the type B VM type 380. As set forth in the remarks above, each primary VM instance 350P may include the corresponding MTTF value, indicating how long (e.g., a number of days) the primary VM instance 350P is expected to be operational before incurring a failure, and the stock-out value, indicating an expected length of time to re-create the primary VM instance 350P. The MTTF value and the stock-out value may be derived from observed monitoring data as well as machine learning algorithms that observe execution of similar VM instances 350 over time…” Col. 10 Ln. 3-8, 42-57).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Shimada with the teaching of Hildebrand because the teaching of Hildebrand would improve the system of Shimada by providing a technique for allowing varying types of virtual machines to be executed on virtual machine manager and thus providing diverse computation.
Janakiraman teaches defragmentation based at least in part on the type of the VMs (Virtual Machine (VM) Format Detection Module 866) (“…Deallocation module 850 includes timer module 852, timer signal receiving module 854, deallocation request receiving module 856, deallocated regions determination module 858, file table updating module 860, zero writing module 862, data structure update module 864, and virtual machine (VM) format detection module 866. Timer module 852 is operable to send a timer signal after a predetermined amount of time (e.g., periodically). Timer signal receiving module 854 is operable to receive a timer signal from timer module 852 and provides the signal to deallocated regions determination module 858. Deallocated regions determination module 858 is operable to determine regions on a storage medium that correspond to deleted or moved during defragmentation files, folders, or VM disk files and deallocated space. Deallocated region determination module 858 is operable to signal zero writing module 862 after determining regions corresponding to deallocated space. Deallocation request receiving module 856 is operable to receive a request to delete data on a storage medium (e.g., files, folders, VM disk file, etc.) or move data (e.g., during defragmentation) and signal zero writing module 862. VM format detection module 866 is operable to receive a format command (e.g., to format a virtual machine disk file or to format a partition) and signal zero writing module 862 when a file system for a virtual hard disk (or partition thereof) will not write zeros to each region in performing a format command…” paragraph 0098).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Shimada and Hildebrand with the teaching of Janakiraman because the teaching of Janakiraman would improve the system of Shimada and Hildebrand by providing a technique that allows for garbage collection and better organization of storage resources.
As to claim 8, Shimada teaches method of claim 1, determining capacity fragmentation and memory fragmentation for each of the HV candidates, and wherein the one or more selected HVs is based on one or more of the memory fragmentation, or the capacity fragmentation (“…Subsequently, the VM migration planning unit 23 calculates the degree of variation in the memory usage frequency of the selected VMM 91 (step S33)…”).
As to claim 9, Shimada teaches the method of claim 1, wherein determining the HV candidates is based on one or more of VM capacity reservations, a core usage, or a memory usage (“…Subsequently, the VM migration planning unit 23 calculates the degree of variation in the memory usage frequency of the selected VMM 91 (step S33)…”).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2013140524 A1 to Shimada et al. in view of U.S. Pat. No. 10,949,241 B2 issued to Hildebrand et al. and further in view of U.S. Pub. No. 2012/0109897 A1 to Janakiraman et al. as applied to claim 2 above, and further in view of U.S. Pub. No. 2013/0219030 A1 to Szabo et al.
As to claim 2, Shimada as modified by Hildebrand and Janakiraman teaches the method of claim 1, however it is silent with reference to reference to wherein determining the one or more selected HVs comprising prioritizing at least one of the selected HVs for defragmentation.
Szabo teaches wherein determining the one or more selected HVs comprising prioritizing at least one of the selected HVs for defragmentation (priority scores) (“…At block 1108, in at least one of the various embodiments, upgrade priority scores may be generated for each hypervisor node. In at least one of the various embodiments, this may require executing one or more algorithms that may generate a priority score for each hypervisor nodes in the hardware cluster. In at least one of the various embodiments, hypervisor nodes may receive priority scores based on a variety of factors, including when they joined the cluster, the version of the software running on the hypervisor node, name or identifier sort order, network address, assignment by a system administrator, or the like. In at least one of the various embodiments the priority scores may be stored and retrieved as required. Further, in at least one of the various embodiments, priority scores may be generated by assigning a numeric identifier to each hypervisor node…” paragraph 0094).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Shimada, Hildeband and Janakiraman with the teaching of Szabo because the teaching of Szabo would improve the system of Shimada, Hildeband and Janakiraman by providing a technique for prioritizing which hypervisor is selected for migration or update.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2013140524 A1 to Shimada et al. in view of U.S. Pat. No. 10,949,241 B2 issued to Hildebrand et al. and further in view of U.S. Pub. No. 2012/0109897 A1 to Janakiraman et al. and further in view of U.S. Pub. No. 2013/0219030 A1 to Szabo et al. as applied to claim 2 above, and further in view of W.O. No. 2017049617 A1 to Dong et al.
As to claim 3, Shimada as modified by Hildebrand and Janakiraman teaches the method of claim 2, however it is silent with reference to reference to wherein causing the one or more VMs of the one or more selected HVs to be migrated to the different HV, comprises causing a first VM from the one or more selected HVs to be live-migrated to the one or more different HVs before causing a second VM from the selected HV to be live-migrated to the one or more different HVs.
Dong teaches causing the one or more VMs to be migrated to the different HV, comprises causing a first VM from the one or more HVs to be live-migrated to the one or more different HVs before causing a second VM from the HV to be live-migrated to the one or more different HVs (determining a sequence of what order to live migrate VMs from the source node/server to the destination node/server) (“…Live migration techniques such as those mentioned above may be used to move all VMs from a near end-of-life cycle source node/server to a more dependable (e.g., farther from end-of- life cycle) destination node/server. Following live VM migration of all VMs to the destination node/server the source node/server may be retired. However, determining a sequence of what order to live migrate VMs from the source node/server to the destination node/server and doing so with little to no disruption in supported network services is difficult. Therefore a need exists for determining a sequence of migrating VMs such that high availability or RAS requirements can be met when operating large numbers of nodes/servers supporting many VMs. It is with respect to these challenges that the examples described herein are needed…” paragraph 0019).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Shimada, Hildeband, Janakiraman and Szabo with the teaching of Dong because the teaching of Dong would improve the system of Shimada, Hildeband, Janakiraman and Szabo by providing an organized and ordered sequence of migrating virtual machines between partitions.
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2013140524 A1 to Shimada et al. in view of U.S. Pat. No. 10,949,241 B2 issued to Hildebrand et al. and further in view of U.S. Pub. No. 2012/0109897 A1 to Janakiraman et al. as applied to claims 1 and 12 above, and further in view of W.O. No. 2013105217 A1 to Doi.
As to claim 7, Shimada as modified by Hildebrand and Janakiraman teaches the method of claim 1, however it is silent with reference to reference to (However, Doi teaches) determining a defragmentation technique to reduce the capacity fragmentation, wherein the defragmentation technique is determined from one or more of:
a single HV defragmentation technique that live-migrates VMs of a selected HV before selecting a different HV for defragmentation;
a single VM defragmentation technique that live-migrates a first VM before live-migrating a second VM (live migration); or
a rack defragmentation technique that migrates HVs on an identified rack to one or more different racks (“…In step 1004, an arrangement plan is formulated by the arrangement planning unit 1212 in the arrangement management unit 312 (1210). As an example of an arrangement plan, virtual machines are rearranged in ascending order of estimated cost (estimated value of memory transfer time). Then, an arrangement plan is made so that live migration is executed in order from the first virtual machine in this order. As the destination physical machine, a machine having the smallest physical machine operation rate may be selected or may be determined in advance. Alternatively, operator designation may be considered...”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Shimada, Hildeband and Janakiraman with the teaching of Doi because the teaching of Doi would improve the system of Shimada, Hildeband and Janakiraman by providing live migration of virtual machine to allow instant resolution of performance issues.
As to claim 16, see the rejection of claim 7 above.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2013140524 A1 to Shimada et al. in view of U.S. Pat. No. 10,949,241 B2 issued to Hildebrand et al. and further in view of U.S. Pub. No. 2012/0109897 A1 to Janakiraman et al. as applied to claim 12 above, and further in view of U.S. Pub. No. 2023/0029074 A1 to Chawla et al.
As to claim 14, Shimada as modified by Hildebrand and Janakiraman teaches the system of claim 12, however it is silent with reference to reference to (However, Chawla teaches) wherein determining the HV candidates comprises one or more of determining that individual ones of the VMs hosted by an associated HV are live migratable (Steps 350/355/360),
determining that individual ones of the VMs hosted by the associated HV have not failed live migration in a specified time period,
determining that one or more of the individual ones of VMs have not been live migrated in a second specified time period, or
determining that individual ones of the VMs are older than a third specified time period (“…At 350, source host 310 indicates the shadow live migration is ready to replicate or migrate the virtual machine and starts a watchdog timer. The shadow live migration may be ready during the copy of the memory dirty pages and the watchdog timer may also be started at this point. After smartNIC 315 is finished with copying the dirty memory pages, it coordinates with source host 310 to start the watchdog time which may run on both smartNIC 315 and source host 310. The watchdog timer may monitor the system memory, hypervisor, and/or the information handling system that hosts the virtual machine to determine if there is a failure. There may be more than one watchdog timer such that one is associated with the system memory, another with the hypervisor, and yet another with the host of the virtual machine. For example, the watchdog timer associated with the virtual machine may have a heartbeat that checks on the virtual machine to make sure it has not crashed or failed…At block 355, if one of the watchdog timer(s) detects a failure, such as an operating system failure, the watchdog timer may expire. The expiration of the watchdog timer may trigger a live migration of the virtual machine at 360 where smartNIC 315 executes a memory copy of the virtual machine memory data from the source host 310 to a smartNIC memory in destination host 320. If smartNIC 315 detects a failure, such as a host failure, a hypervisor failure, or a virtual machine failure, then smartNIC 315 may initiate a switchover phase. If source host 310 detects failure of smartNIC 315, then source host 310 may stop setting the dirty pages in the bitmap and stop exception handling of the memory writes. Source host 310 may also stop the shadow live migration of memory 220 to memory 235. For example, source host 310 may bring the status of the virtual machines to normal…” paragraphs 0048/0049).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Shimada, Hildeband and Janakiraman with the teaching of Chawla because the teaching of Chawla would improve the system of Shimada, Hildeband and Janakiraman by providing a timer technique for monitoring and resolving virtual machine migrating failures.
Allowable Subject Matter
Claims 4-6, 10, 11, 13,15 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Reasons for allowance
The following is an examiner’s statement of reasons for allowance:
The closest prior art of records, (W.O. No. 2013140524 A1 to Shimada et al. and U.S. Pat. No. 10,949,241 B2 issued to Hildebrand et al.), taken alone or in combination do not specifically disclose or suggest the claimed recitations (claims 4-6, 10, 11, 13, and 19), when taken in the context of claims as a whole.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Response to Arguments
Applicant’s arguments with respect to claims 1-3, 7-9, 12, 14-18 and 20 have been considered but are moot because the new ground of rejection replies on additional reference not applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
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, KEVIN YOUNG can be reached at 571-270-3180. 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.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194
