DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending in this application.
Information Disclosure Statement
The IDS filed on 02/06/2024 has been considered.
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-20 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.
As per claims 1, 15, and 18 (line numbers refer to claim 1):
Lines 13-14, 16, and 20-21 recite “the subset of the plurality of virtualized computing instances” but it is unclear what this refers to since line 9 recite “a different subset of the plurality of virtualized computing instances”.
Lines 14, 17, and 21 recite “the given virtualized computing instance workload group” and it is unclear if this refers to “a given one of the two or more virtualized computing instance workload groups”.
Lines 18-19 recite “input-output requests” and it is unclear if this refers to input-output requests in line 13.
Line 22 recites “the different priority levels” and it is unclear if this refers to “different input-output priority levels”.
Claims 2-14, 16-17, and 19-20 are dependent claims of claims 1, 15, and 18, and fail to resolve the deficiencies of claims 1, 15, and 18, so they are rejected for the same reasons.
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, 6, 7, 15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Shih et al. (US 20190222522 A1 hereinafter Shih) in view of Chanda et al. (US 20250077297 A1 hereinafter Chanda).
As per claim 1, Shih teaches the invention substantially as claimed including an apparatus comprising: at least one processing device comprising a processor coupled to a memory; the at least one processing device being configured (Fig. 1; [0011] Data center 105 includes management server(s) 110, a quality of service (QoS) controller 112, one or more host computers 115, one or more switches 150, and storage 120; [0015] Hardware 125 includes one or more processors 126 (“CPU(s)”), data storage and memory 128,):
to identify, for each of a plurality of virtualized computing instances issuing input-output requests to a shared storage system, an input-output workload classification ([0034] each I/O request generated by an application running on a VM 135 is tagged with one of these defined QoS classifications, which helps the switch fabric prioritize the I/O request accordingly and also determine the appropriate network path configured for carrying the I/O request. These classifications also help the storage array (e.g., storage 120) to prioritize and assign appropriate resources when servicing an I/O request based on the I/O request's QoS classification; [0002] various types of application I/O traffic with different QoS requirements may share and compete for the same resources; [0040] FIG. 2 illustrates example I/O requests being transmitted by the VMs of the host computer of FIG. 1 (e.g., host computer 115) to the storage array (e.g., storage 120));
to determine two or more virtualized computing instance workload groups based at least in part on the identified input-output workload classifications of the plurality of virtualized computing instances, each of the two or more virtualized computing instance workload groups comprising a different subset of the plurality of virtualized computing instances ([0023] As described above, VMs 135 may use the pool of storage provided by storage 120, for example, to store virtual disks that are accessed by VMs 135 during their operation through a converged network, such as a FCoE or RoCE network. For example, applications running on a VM 135 may generate read or write requests to a storage stack provided by an underlying virtualization software (shown in FIG. 2) for transmission to storage 120 over the SAN. In some cases, one or more VMs 135 may run applications or workloads with a higher quality of service (QoS) requirements than applications being run by other VMs; [0034] each I/O request generated by an application running on a VM 135 is tagged with one of these defined QoS classifications, which helps the switch fabric prioritize the I/O request accordingly and also determine the appropriate network path configured for carrying the I/O request. These classifications also help the storage array (e.g., storage 120) to prioritize and assign appropriate resources when servicing an I/O request based on the I/O request's QoS classification;);
to generate, for at least a given one of the two or more virtualized computing instance workload groups, an input-output queue associated with a different input-output priority level ([0065] In some embodiments, each queue is allocated to processing data frames of different QoS classifications. For example, each egress port within a switch may have three queues including a high priority, a medium priority, and a low priority queue; [0023] In some cases, one or more VMs 135 may run applications or workloads with a higher quality of service (QoS) requirements than applications being run by other VMs; [0034] each I/O request generated by an application running on a VM 135 is tagged with one of these defined QoS classifications, which helps the switch fabric prioritize the I/O request accordingly and also determine the appropriate network path configured for carrying the I/O request. These classifications also help the storage array (e.g., storage 120) to prioritize and assign appropriate resources when servicing an I/O request based on the I/O request's QoS classification).
Shih fails to teach to generate, for at least a given one of the two or more virtualized computing instance workload groups, two or more input-output queues associated with different input-output priority levels; to sort input-output requests received from the subset of the plurality of virtualized computing instances in the given virtualized computing instance workload group into the two or more input-output queues, wherein a given one of the input-output requests received from a given virtualized computing instance in the subset of the plurality of virtualized computing instances of the given virtualized computing instance workload group is placed in a given one of the two or more input-output queues based at least in part on information characterizing servicing of input-output requests by the shared storage system; and to process the input-output requests received from the subset of the plurality of virtualized computing instances in the given virtualized computing instance workload group based at least in part on the different priority levels associated with the two or more input-output queues.
However, Chanda teaches to generate, for at least a given one of the two or more virtualized computing instance workload groups, two or more input-output queues associated with different input-output priority levels (Fig. 1B; [0067] A first set of containers 125 (e.g., the first container 125a and the second container 125b) in the internal memory 124 may be used to submit commands to the first data transform engines 126a and a second set of containers 125 (e.g., the third container 125c, the fourth container 125d, and the fifth container 125e) may be used to submit commands to the second data transform engines 126b; [0068] the first data transform engines 126a may be associated with the first class of service queue 130a and the second class of service queue 130b, and the second data transform engines 126b may be associated with the third class of service queue 130c and the fourth class of service queue 130d; [0071] the first class of service queue 130a has a higher priority than the second class of service queue 130b; [0116] containers 415 that may be assigned to the virtual machines 444; [0114] the first container 415a is assigned to the first virtual machine 444a and the second container 415b is assigned to the second virtual machine 444b, the first virtual machine software 446a may submit commands to the first container 415a and the second virtual machine software 446b may submit commands to the second container 415b; [0098] The first command address may point to a first command and first input data; [0023] process the input data using the command addresses associated with the commands; [0066] some lower priority commands (e.g., a write command) may be cached in memory so higher priority commands (e.g., a read command, a decode command, etc.) may be performed);
to sort input-output requests received from the subset of the plurality of virtualized computing instances in the given virtualized computing instance workload group into the two or more input-output queues, wherein a given one of the input-output requests received from a given virtualized computing instance in the subset of the plurality of virtualized computing instances of the given virtualized computing instance workload group is placed in a given one of the two or more input-output queues based at least in part on information characterizing servicing of input-output requests by the shared storage system ([0070] Commands from the command pointer rings may be fetched from these queues and processed by the transform engines using the priority of the queues. Commands in the containers 125 may be fetched from the class of service queues 130 and may processed by the associated data transform engines 126 using the priority of the class of service queues 130. In some instances, the commands may include a command tag that may be used to identify a class of service to which the command may belong; [0098] The first command address may point to a first command and first input data; [0069] The class of service queues may be configured with a priority and a peak bandwidth limit for strict priority arbitration and/or a weight for WRR arbitration, to share the bandwidth of the associated data transform engines 126; [0071] Using strict priority arbitration, commands from a highest priority class of service queue may be processed by the associated data transform engines 126 first. Commands from lower priority class of service queues may be processed after all the commands from higher priority class of service queues (e.g., at least the highest priority class of service queue) have been processed, or after commands from the higher priority class of service queues have exhausted peak bandwidth limit associated with the higher priority class of service queues. For example, in instances in which the first class of service queue 130a and the second class of service queue 130b each have a waiting command and the first class of service queue 130a has a higher priority than the second class of service queue 130b; [0067] A first set of containers 125 (e.g., the first container 125a and the second container 125b) in the internal memory 124 may be used to submit commands to the first data transform engines 126a and a second set of containers 125 (e.g., the third container 125c, the fourth container 125d, and the fifth container 125e) may be used to submit commands to the second data transform engines 126b; [0068] the first data transform engines 126a may be associated with the first class of service queue 130a and the second class of service queue 130b, and the second data transform engines 126b may be associated with the third class of service queue 130c and the fourth class of service queue 130d; [0116] containers 415 that may be assigned to the virtual machines 444; [0114] the first container 415a is assigned to the first virtual machine 444a and the second container 415b is assigned to the second virtual machine 444b, the first virtual machine software 446a may submit commands to the first container 415a and the second virtual machine software 446b may submit commands to the second container 415b; [0069] The class of service queues may be configured with a priority and a peak bandwidth limit for strict priority arbitration and/or a weight for WRR arbitration, to share the bandwidth of the associated data transform engines 126.); and
to process the input-output requests received from the subset of the plurality of virtualized computing instances in the given virtualized computing instance workload group based at least in part on the different priority levels associated with the two or more input-output queues ([0025] The software on the virtual machine may be operable to transmit the first command address from the first container to at least one data transform accelerator associated with the virtual machine. The data transform accelerator may be operable to obtain a first command and first input data using the first command address; [0116] containers 415 that may be assigned to the virtual machines 444; [0114] the first container 415a is assigned to the first virtual machine 444a and the second container 415b is assigned to the second virtual machine 444b, the first virtual machine software 446a may submit commands to the first container 415a and the second virtual machine software 446b may submit commands to the second container 415b; [0071] Using strict priority arbitration, commands from a highest priority class of service queue may be processed by the associated data transform engines 126 first. Commands from lower priority class of service queues may be processed after all the commands from higher priority class of service queues (e.g., at least the highest priority class of service queue) have been processed; [0067] A first set of containers 125 (e.g., the first container 125a and the second container 125b) in the internal memory 124 may be used to submit commands to the first data transform engines 126a and a second set of containers 125 (e.g., the third container 125c, the fourth container 125d, and the fifth container 125e) may be used to submit commands to the second data transform engines 126b; [0068] the first data transform engines 126a may be associated with the first class of service queue 130a and the second class of service queue 130b, and the second data transform engines 126b may be associated with the third class of service queue 130c and the fourth class of service queue 130d; [0071] the first class of service queue 130a has a higher priority than the second class of service queue 130b;).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Shih with the teachings of Chanda to reduce latency (see Chanda [0022] the system as described in the present disclosure may experience improved throughput and/or reduced latency in the data transform operations.).
As per claim 4, Shih and Chanda teach the apparatus of claim 1. Chanda teaches wherein processing the input-output requests received from the subset of the plurality of virtualized computing instances in the given virtualized computing instance workload group comprises utilizing a multi-priority input-output scheduling algorithm (Fig. 1B; [0071] Using strict priority arbitration, commands from a highest priority class of service queue may be processed by the associated data transform engines 126 first. Commands from lower priority class of service queues may be processed after all the commands from higher priority class of service queues (e.g., at least the highest priority class of service queue) have been processed, or after commands from the higher priority class of service queues have exhausted peak bandwidth limit associated with the higher priority class of service queues. For example, in instances in which the first class of service queue 130a and the second class of service queue 130b each have a waiting command and the first class of service queue 130a has a higher priority than the second class of service queue 130b, the first class of service queue 130a may be serviced until the first class of service queue 130a is empty; [0098] The first command address may point to a first command and first input data; [0066] some lower priority commands (e.g., a write command) may be cached in memory so higher priority commands (e.g., a read command, a decode command, etc.) may be performed; [0067] A first set of containers 125 (e.g., the first container 125a and the second container 125b) in the internal memory 124 may be used to submit commands to the first data transform engines 126a and a second set of containers 125 (e.g., the third container 125c, the fourth container 125d, and the fifth container 125e) may be used to submit commands to the second data transform engines 126b; [0068] the first data transform engines 126a may be associated with the first class of service queue 130a and the second class of service queue 130b, and the second data transform engines 126b may be associated with the third class of service queue 130c and the fourth class of service queue 130d; [0114] the first container 415a is assigned to the first virtual machine 444a and the second container 415b is assigned to the second virtual machine 444b, the first virtual machine software 446a may submit commands to the first container 415a and the second virtual machine software 446b may submit commands to the second container 415b;).
As per claim 6, Shih and Chanda teach the apparatus of claim 1. Shih teaches wherein the plurality of virtualized computing instances and the shared storage system run on common physical infrastructure in an information technology infrastructure environment (Fig. 1; [0023] the host computer(s) 115 and storage 120 may be configured with a storage I/O control (SIOC) functionality that enables the allocation of more resource shares to VMs; [0012] Data center 105 also includes one or more host computers 115. Each host 115 includes hardware 125, virtualization software layer 130 (also referred to as a hypervisor), and virtual machines (VMs); [0011] Data center 105 includes management server(s) 110, a quality of service (QoS) controller 112, one or more host computers 115, one or more switches 150, and storage 120).
As per claim 7, Shih and Chanda teach the apparatus of claim 1. Chanda teaches wherein sorting the input-output requests received from the subset of the plurality of virtualized computing instances in the given virtualized computing instance workload group into the two or more input-output queues comprises placing ones of the input-output requests having a responsible ratio greater than a threshold value in a first one of the two or more input-output queues associated with a first priority level and placing ones of the input-output requests having a responsible ratio less than or equal to the threshold value in a second one of the two or more input-output queues associated with a second priority level ([0070] In some instances, the commands may include a command tag that may be used to identify a class of service to which the command may belong. For example, the DMA controllers 128 may obtain a command tag associated with a command and the DMA controllers 128 may be operable to sort the command into one of the class of service queues 130; [0055] In some instances, the weights may be predetermined based on priorities established relative to the host device 110 and/or the data transform accelerator 120. For example, a read operation may have a higher priority than a write operation, as a write data transform operation may be longer than a read data transform operation; Fig. 1B; [0067] A first set of containers 125 (e.g., the first container 125a and the second container 125b) in the internal memory 124 may be used to submit commands to the first data transform engines 126a and a second set of containers 125 (e.g., the third container 125c, the fourth container 125d, and the fifth container 125e) may be used to submit commands to the second data transform engines 126b; [0068] the first data transform engines 126a may be associated with the first class of service queue 130a and the second class of service queue 130b, and the second data transform engines 126b may be associated with the third class of service queue 130c and the fourth class of service queue 130d; [0071] the first class of service queue 130a has a higher priority than the second class of service queue 130b; [0116] containers 415 that may be assigned to the virtual machines 444; 0114] the first container 415a is assigned to the first virtual machine 444a and the second container 415b is assigned to the second virtual machine 444b, the first virtual machine software 446a may submit commands to the first container 415a and the second virtual machine software 446b may submit commands to the second container 415b;).
As per claim 15, it is a computer program product claim of claim 1, so it is rejected for similar reasons. Additionally, Shih teaches a computer program product comprising a non-transitory processor-readable storage medium having stored therein program code of one or more software programs, wherein the program code when executed by at least one processing device causes the at least one processing device ([0084] One or more embodiments may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media. The term computer readable medium refers to any data storage device that can store data which can thereafter be input to a computer system computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer.).
As per claim 18, it is a method claim of claim 1, so it is rejected for similar reasons.
Claims 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Shih and Chanda, as applied to claim 1 above, in view of Shibayama et al. (US 20200104153 A1 hereinafter Shibayama).
As per claim 2, Shih and Chanda teach the apparatus of claim 1.
Shih and Chanda fail to teach wherein the plurality of virtualized computing instances and the shared storage are part of a hyperconverged infrastructure environment.
However, Shibayama teaches wherein the plurality of virtualized computing instances and the shared storage are part of a hyperconverged infrastructure environment ([0008] The resource allocation determination method determines allocation of at least one of a virtual machine, a container, and a volume in a system of a hyperconverged infrastructure environment; [0054] In the HCl environment, an application VM that operates an application, and storage VMs that operates a container and a storage controller are provided in the same node, and share a computer resource (such as a CPU or a memory).).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Shih and Chanda with the teachings of Shibayama since a hyperconverged infrastructure environment promotes scalability.
As per claim 3, Shih, Chanda, and Shibayama teach the apparatus of claim 2. Shih teaches wherein the plurality of virtualized computing instances comprise software containers ([0013] In some embodiments, host 115 may include operating system level virtualization software containers such as those provided by companies such as Docker. In other embodiments, host 115 includes both VMs and software containers.).
Additionally, Shibayama teaches wherein the hyperconverged infrastructure environment comprises a container-based hyperconverged infrastructure environment (Abstract a virtual machine, a container, and a volume in a system of the HCl environment).
As per claims 16 and 19, they are computer program product and method claims of claim 3, so they are rejected for similar reasons.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Shih and Chanda, as applied to claim 4 above, in view of Chen et al. (CN117111835A hereinafter Chen).
The portions of Chen are pulled from a translation of CN117111835A.
As per claim 5, Shih and Chanda teach the apparatus of claim 4.
Shih and Chanda fail to teach wherein the multi-priority input-output scheduling algorithm is implemented utilizing a Non-Volatile Memory Express driver of the shared storage system.
However, Chen teaches wherein the multi-priority input-output scheduling algorithm is implemented utilizing a Non-Volatile Memory Express driver of the shared storage system ([0061] Alternatively, in some implementations, the NRD configuration tool, the applications of the shared storage device, or the host NVMe driver can be used to set the priority of the resources of each virtual storage device. For example, priorities can be set for I/O queues, allowing storage devices to schedule I/O requests on each I/O queue according to their priorities.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Shih and Chanda with the teachings of Chen since the non-volatile memory express efficiently parses data.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Shih and Chanda, as applied to claim 7 above, in view of Inakoshi (US 20110179417 A1).
As per claim 8, Shih and Chanda teach the apparatus of claim 7.
Shih and Chanda fail to teach wherein the responsible ratio for a given one of the input-output requests received from the given virtualized computing instance is determined based at least in part on a total wait time associated with input-output requests received from the given virtualized computing instance and an amount of time taken to process the given input-output request.
However, Inakoshi teaches wherein the responsible ratio for a given one of the input-output requests received from the given virtualized computing instance is determined based at least in part on a total wait time associated with input-output requests received from the given virtualized computing instance and an amount of time taken to process the given input-output request ([0163] Therefore, in the virtual OS, the statistical information on the kernel execution time and the I/O wait execution time when executing the I/O process get approximate to the statistical information under the condition similar to the case of being measured by the actual physical computer. Namely, as illustrated in FIG. 5, when the guest OS 10B inputs and outputs the data to the I/O device via the virtual machine monitor 1, the ratio of the I/O wait time recognized by the guest OS 10B to the processing time other than the I/O wait time becomes approximate to the ratio of the I/O wait time recognized by the virtual machine monitor 1 to the processing time other than the I/O wait time.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Shih and Chanda with the teachings of Inakoshi to provide effective metrics (see Inakoshi [0071] The computer system according to the embodiment provides the more effective statistical information than by the computer system 300 according to the comparative example in terms of the performance tuning of the application program and the middleware owing to the mechanism for correcting the timer mechanism.).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Shih and Chanda, as applied to claim 7 above, in view of Ayandeh (US 20190334792 A1).
As per claim 9, Shih and Chanda teach the apparatus of claim 7. Shih teaches resources of physical infrastructure on which the plurality of virtualized computing instances and the shared storage system run (Fig. 1; [0023] the host computer(s) 115 and storage 120 may be configured with a storage I/O control (SIOC) functionality that enables the allocation of more resource shares to VMs; [0012] Data center 105 also includes one or more host computers 115. Each host 115 includes hardware 125, virtualization software layer 130 (also referred to as a hypervisor), and virtual machines (VMs); [0011] Data center 105 includes management server(s) 110, a quality of service (QoS) controller 112, one or more host computers 115, one or more switches 150, and storage 120).
Shih and Chanda fail to teach wherein the threshold value comprises a value range determined based at least in part on analyzing a flow of the input-output requests and available resources of physical infrastructure.
However, Ayandeh teaches wherein the threshold value comprises a value range determined based at least in part on analyzing a flow of the input-output requests and available resources of physical infrastructure ([0022] The drop threshold may be determined based on a pre-determined percentage of available buffer space in the shared buffer memory 103; [0021] each queue may be associated with various thresholds that help determine activity on the queue (e.g., a dynamic max queue size, a dynamic monitoring threshold, a dynamic drop threshold, and/or other threshold value; [0014] A queue associated with an I/O port could be an input queue, an output queue, an I/O shared memory queue; [0028] the monitoring engine 130 may, responsive to receiving a first packet in a first queue associated with a first input/output (“I/O”) port, determine a first drop threshold for the first queue based on a first available amount of memory in a buffer memory communicably coupled to the first queue; [0021] A queue may have a dynamic max queue size as a threshold to prevent acceptance of packets into a given queue past its storage capabilities; [0021] Packets may be dropped in a queue responsive to the throughput exceeding the dynamic drop threshold.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Shih and Chanda with the teachings of Ayandeh to prevent overutilization (see Ayandeh [0014] a threshold to prevent acceptance of packets into a given queue past its storage capabilities).
Claims 10, 13, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Shih and Chanda, as applied to claim 1 above, in view of Sakdeo et al. (US 20160299693 A1 hereinafter Sakdeo).
As per claim 10, Shih and Chanda the apparatus of claim 1. Chanda teaches wherein the information characterizing servicing of input-output requests by the shared storage system comprises (i) a time to service the given input-output request given available resources of the shared storage system ([0054] The weights may be decided based on a workload (e.g., latency of execution) of the command type; [0098] The first command address may point to a first command and first input data; [0074] Following the establishment of the class of service queues 130, a subset of the containers 125 may be individually mapped to the class of service queues 130, where the containers 125 may share the time slot resources assigned to the individual class of service queues 130;[0110] weight to share the bandwidth between multiple classes).
Shih and Chanda fail to teach wherein the information characterizing servicing of input-output requests by the shared storage system comprises (i) a time to service the given input-output request given available resources of the shared storage system and (ii) wait times for input-output requests received from the subset of the plurality of virtualized computing instances of the given virtualized computing instance workload group.
However, Sakdeo teaches wherein the information characterizing servicing of input-output requests by the shared storage system comprises (i) a time to service the given input-output request given available resources of the shared storage system and (ii) wait times for input-output requests received from the subset of the plurality of virtualized computing instances of the given virtualized computing instance workload group ([0036] testing is conducted to characterize storage system performance across requests of different sizes (e.g., 8 kB, 16 kB, 32 kB, 64 kB, 256 kB, etc.) (302). For example, for a given request size, increasing numbers of requests (IOPS) may be submitted, and the storage system latency (e.g., time to complete requests) at varying workloads may be observed. [0047] In some embodiments, requests will spend time waiting in VM queues as shown in FIG. 5, 506, such latency attributed by VM's I/O request determines the measure of contention experienced by this VM for storage resources (sometimes referred to herein as “contention latency”); [0044] storage system resources have been allocated among the five VMs as indicated by the respective number of “shares” (see first populated row) ascribed to each, i.e., 10, 80, 20, 60, and 40 shares, respectively; [0043] Requests place in respective ones of a plurality of virtual machine-specific queues 506 are scheduled by a proportional scheduler 508 to be added to a pipeline 510 of requests to be processed. For example, a next available location 512 in pipeline 510 may be filled by pulling a next-scheduled request from among the queues 506 and adding it to the pipeline 510 in position 512. An I/O engine 514 pulls requests from the pipeline 510 and services each request in turn, e.g., by reading data from an associated file and/or writing data to an associated file.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Shih and Chanda with the teachings of Sakdeo to provide reports about wait times for requests (see Sakdeo [0049] Reports and/or visualizations may be generated and provide to report contention latency, throttle latency, or both on a per-VM basis).
As per claim 13, Shih, Chanda, and Sakdeo teach the apparatus of claim 10. Sakdeo teaches wherein the information characterizing the wait times for the input-output requests received from the given virtualized computing instance comprises at least one of: a number of input-output requests received per second from the given virtualized computing instance over a designated period of time; and an amount of data written to the shared storage system by the given virtualized computing instance over a designated period of time ([0037] FIG. 3B is a diagram illustrating an example of a graph of storage system performance in an embodiment of a virtual machine-aware system. In the example shown, in graph 320 latency is plotted against increasing workload (“performance”) such as number of IOPS of a given request size or data throughput based on requests of a given size (e.g., 8 kB); [0050] FIG. 9 is a flow chart illustrating an embodiment of a process to report normalized storage system performance on a per-VM basis. As described herein, different VMs and/or hypervisors may be configured to submit read and/or write requests of different sizes (e.g., 8 kB, 256 kB, etc.) As a result, the most familiar traditional measure of storage system performance, “IOPS” or “I/O operations per second”, may not fully and accurately reflect the performance achieve across workloads of varying size. In various embodiments, therefore, a “normalized IOPS” may be computed and reported, in addition to and/or instead of IOPS or other performance measures, such as throughput (e.g., how many bytes have been read and/or written in a given period)).
As per claims 17 and 20, they are computer program product and method claims of claim 10, so they are rejected for similar reasons.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Shih, Chanda, and Sakdeo, as applied to claim 10 above, in view of Antony (US 20140365816 A1).
As per claim 11, Shih, Chanda, and Sakdeo teach the apparatus of claim 10.
Shih, Chanda, and Sakdeo fail to teach wherein the information characterizing the wait times for the input-output requests received from the given virtualized computing instance comprises an average responsible time for each of the input-output requests received from the given virtualized computing instance over a designated period of time.
However, Antony teaches wherein the information characterizing the wait times for the input-output requests received from the given virtualized computing instance comprises an average responsible time for each of the input-output requests received from the given virtualized computing instance over a designated period of time ([0031] I/O latency module 406 continuously monitors the I/O latency for all data stores in the HA cluster on which virtual machine disks (VMDKs) 412A-C resides (e.g., in milliseconds) for a predetermined time interval (e.g., 8 hours) and then computes an average of the I/O latency; [0022] virtual machines VM2 and VM6 as requiring I/O cache memory.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Shih, Chanda, and Sakdeo with the teachings of Antony to improve performance (see Antony [0042] The systems and methods as described in FIGS. 1-6 improve I/O performance of the virtual machines.).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Shih, Chanda, and Sakdeo, as applied to claim 10 above, in view of Reynolds et al. (US 20120203890 A1 hereinafter Reynolds).
As per claim 12, Shih, Chanda, and Sakdeo teach the apparatus of claim 10.
Shih, Chanda, and Sakdeo fail to teach wherein the information characterizing the wait times for the input-output requests received from the given virtualized computing instance comprises an average wait time for each of the input-output requests received from the given virtualized computing instance over a designated period of time.
However, Reynolds teaches wherein the information characterizing the wait times for the input-output requests received from the given virtualized computing instance comprises an average wait time for each of the input-output requests received from the given virtualized computing instance over a designated period of time ([0078] Additionally, some embodiments provide that the number of reads that were completed during the last time period may be determined. An average of read wait time per read may be generated by dividing the total read wait time, corresponding to a sum of all of the T4-T5 values during the time period, by the number of completed reads in that period; [0114] Collector application 200 may then create, for each enumerated operating system virtualization container 1115 and 1120, a named pipe that is accessible for writing from within each of operating system virtualization containers 1115 and 1120, and from which collector application 200 may read).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Shih, Chanda, and Sakdeo with the teachings of Reynolds to identify metrics for improvement (see Reynolds [0076] Additionally, another metric that may be determined is the read wait time 414, which is the elapsed time between when the client 401 is ready to read a response to the request T5 and when the response to the request is actually read T4. In some embodiments, the read wait time may represent a portion of the client measured server response time 410 that may be improved upon by improving performance of the server 402.).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Shih, Chanda, and Sakdeo, as applied to claim 10 above, in view of Gupta et al. (US 11941454 B1 hereinafter Gupta).
As per claim 14, Shih, Chanda, and Sakdeo teach the apparatus of claim 10.
Shih, Chanda, and Sakdeo fail to teach wherein the information characterizing the wait times for the input-output requests received from the given virtualized computing instance comprises a rate of random write input-output requests received from the given virtualized computing instance over a designated period of time.
However, Gupta teaches wherein the information characterizing the wait times for the input-output requests received from the given virtualized computing instance comprises a rate of random write input-output requests received from the given virtualized computing instance over a designated period of time (Col. 2 lines 50-56 The volume characteristics may include one or more of a volume type, a volume size, an average input/output operations per second (“IOPS”), an average seek time, an average raw read speed, an average raw write speed, an average request latency, a number of pending input/output operations, a random read speed, a random write speed; Col. 2 lines 40-41 A user of the virtual machine can request the provisioning or allocation of block storage volumes).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Shih, Chanda, and Sakdeo with the teachings of Gupta to improve systems (see Gupta Col. 7 lines 56-58 the present disclosure represents an improvement on computing systems providing block storage volumes).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HSING CHUN LIN whose telephone number is (571)272-8522. The examiner can normally be reached Mon - Fri 9AM-5PM.
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 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.
/H.L./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights