Protection of authentication data of a server cluster

- VMware, Inc.

This disclosure describes a process for securely instantiating a virtual machine on a server cluster. The virtual machine just after instantiation has access to persistent storage that includes an encrypted region and lacks access to an encryption key configured to provide access to data stored within the encrypted region. The virtual machine receives a communication from a management server associated with the server cluster that includes the encryption key configured to provide access to the data stored within the encrypted region. After the virtual machine receives the encryption key, the server cluster runs services that depend upon the data stored within the encrypted region to operate after receiving the communication from the management server.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
Description
FIELD

The present disclosure relates generally to keeping encryption keys stored as plain text from being saved to persistent storage of accessible server cluster systems.

BACKGROUND

Server clusters often host a large number of diverse users making network security important. Server clusters that incorporate Kubernetes clusters and container constructs can include an even larger number of users. Oftentimes individual hosts and/or virtual machines of the server cluster require elevated access to a management server in order to perform tasks needed to ensure smooth operation of the server cluster. For this reason, security of authentication data such as the encryption keys used by the hosts to access the management server is important. For at least this reason ways of improving security of the encryption keys is desirable.

SUMMARY

This disclosure describes mechanisms for protecting authentication data used by a server cluster.

A computer implemented method is described and includes the following: instantiating a virtual machine on a server cluster, wherein the virtual machine has access to persistent storage that includes an encrypted region and wherein the virtual machine lacks access to an encryption key configured to provide access to data stored within the encrypted region; receiving a communication at the server cluster from a management server associated with the server cluster that includes the encryption key configured to provide access to the encrypted region of the persistent storage; storing the encryption key received from the management server in non-persistent storage accessible by the virtual machine; decrypting the data stored within the encrypted region using the encryption key; and running services that depend upon the data stored within the encrypted region to operate after decrypting the stored data.

A non-transitory computer-readable storage medium that stores instructions configured to be executed by one or more processors of a computing device is disclosed. The non-transitory computer-readable storage medium when executed by the one or more processors cause the computing device to carry out steps that include: instantiating a virtual machine on the server cluster, wherein the virtual machine has access to persistent storage that includes an encrypted region and wherein the virtual machine lacks access to an encryption key configured to provide access to authentication data stored within the encrypted region; receiving a communication from a management server associated with the server cluster that includes the encryption key configured to provide access to the encrypted region of the persistent storage; and running services that depend upon the authentication data stored within the encrypted region to operate after receiving the communication from the management server.

A server cluster is disclosed and includes one or more processors; persistent storage, comprising an encrypted region; non-persistent storage; and memory storing one or more programs configured to be executed by the one or more processors, the one or more programs including instructions for: instantiating a virtual machine on the server cluster, wherein the virtual machine has access to the persistent storage and lacks access to an encryption key configured to provide access to data stored within the encrypted region; receiving a communication at the server cluster from a management server associated with the server cluster that includes the encryption key configured to provide access to the encrypted region of the persistent storage; storing the encryption key received from the management server in the non-persistent storage, which is accessible by the virtual machine; decrypting the data stored within the encrypted region; and running services that utilize the data stored within the encrypted region to operate after decrypting the stored data.

Other aspects and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings which illustrate, by way of example, the principles of the described embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements.

FIG. 1 shows a diagram illustrating an exemplary server cluster suitable for use with the embodiment described herein.

FIG. 2 shows another exemplary computing environment that includes multiple server clusters in communication with a management server.

FIGS. 3A-3C shows a series of states of a master virtual machine and a management server in accordance with the described embodiments.

FIG. 4 shows a flow diagram illustrating a process for securely providing a newly instantiated virtual machine access to authentication data that includes passwords and encryption keys.

 DETAILED DESCRIPTION

Certain details are set forth below to provide a sufficient understanding of various embodiments of the invention. However, it will be clear to one skilled in the art that embodiments of the invention may be practiced without one or more of these particular details. Moreover, the particular embodiments of the present invention described herein are provided by way of example and should not be used to limit the scope of the invention to these particular embodiments. In other instances, hardware components, network architectures, and/or software operations have not been shown in detail in order to avoid unnecessarily obscuring the invention.

Server clusters running under a management server such as VMWare vCenter® often need privileged access to the management server to perform tasks such as creating virtual machines (VMs), disks and other resources. Unfortunately, storing authentication data such as the passwords and/or encryption keys needed to access the management server and other potentially sensitive systems of the server cluster in an unencrypted region of the persistent storage can result in a user with access to the persistent storage gaining unauthorized access to the passwords and/or encryption keys, thereby allowing the user to gain unauthorized and elevated privilege on the server cluster.

One solution to this issue is to configure rules that prevent VMs and other virtual constructs of a server cluster from writing encryption keys and passwords to persistent storage in an unencrypted state. In order to successfully implement this type of rule, the VMs of the server cluster should still be able to gain access to at least one encryption key in order to access authentication data providing access to the various resources and services they need to conduct normal operations. The encryption key granting access to the encrypted areas on the server cluster can be provided by the management server. The management server is configured to monitor the server clusters and when it detects startup of a master virtual machine (VM) it sends the encryption key to the master VM where it gets stored in non-persistent storage, thereby allowing the master VM to gain access to encrypted authentication data stored on persistent storage. Master VM will also be configured to delay operations requiring access to the encrypted authentication data until it receives the encryption key from the management server, thereby avoiding unnecessary errors resulting from a lack of encryption keys or passwords.

These and other embodiments are discussed below with reference to FIGS. 1-4; however, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes only and should not be construed as limiting.

FIG. 1 shows a block diagram illustrating an exemplary server cluster 100 suitable for use with the embodiment described in this disclosure. Server cluster 100 can include hosts 102, 112, 122 and 132. While a four host system is shown for exemplary purposes it should be appreciated that server cluster 100 could include a larger or smaller number of hosts. Each host 102-132 includes host hardware 110-140, which can include a designated amount of processing, memory, network and/or storage resources. In some embodiments, each of the hosts provide the same amount of resources, and in other embodiments, the hosts are configured to provide different amounts of resources to support one or more virtual machines (VMs) running on the hosts. Each of the VMs can be configured to run a guest operating system that allows for multiple applications or services to run within the VM.

Each of hosts 102, 112, 122 and 132 are capable of running virtualization software 108, 118, 128 and 138, respectively. The virtualization software can run within a virtual machine (VM) and includes management tools for starting, stopping and managing various virtual machines running on the host. For example, host 102 can be configured to stop or suspend operations of virtual machines 104 or 106 utilizing virtualization software 108. Virtualization software 108, commonly referred to as a hypervisor, can also be configured to start new virtual machines or change the amount of processing or memory resources from host hardware 110 that are assigned to one or more VMs running on host 102. Host hardware 110 includes one or more processors, memory, storage resources, I/O ports and the like that are configured to support operation of VMs running on host 102. In some embodiments, a greater amount of processing, memory or storage resources of host hardware 110 is allocated to operation of VM 104 than to VM 106. This may be desirable when, e.g., VM 104 is running a larger number of services or running on a more resource intensive operating system than VM 106. Clients 140 and 150 are positioned outside server cluster 100 and can request access to services running on server cluster 100 via network 160. Responding to the request for access and interacting with clients 140 and 150 can involve interaction with a single service or in other cases may involve multiple smaller services cooperatively interacting to provide information requested by clients 140 and/or 150.

Hosts 102, 112, 122 and 132, which make up server cluster 100, can also include or have access to a storage area network (SAN) that can be shared by multiple hosts. The SAN is configured to provide storage resources as known in the art. In some embodiments, the SAN can be used to store log data generated during operation of server cluster 100. While description is made herein with respect to the operation of the hosts 110-140, it will be appreciated that those of hosts 110-140 provide analogous functionality, respectively.

FIG. 2 shows another exemplary computing environment 200 that includes multiple server clusters 202 and 204 in communication with a management server 206. In some embodiments, server clusters 202 and 204 can take the form of supervisor clusters that use virtual machines (VMs) to implement both control plane nodes and compute objects managed by the Kubernetes® control plane. For example, Kubernetes® pods are implemented as “pod VMs,” each of which includes a kernel and container engine that supports execution of containers. The Kubernetes® control plane of the supervisor cluster is extended to support VM objects in addition to pods, where the VM objects are implemented using native VMs (as opposed to pod VMs). In some embodiments, management server 206 can take the form of a VMWare vCenter® Server that is able to communicate and perform administrative tasks to keep each of the cluster and hosts within their respective clusters functioning properly. In some embodiments, each of clusters 202 and 204 can include virtualization components and various hardware similar to those described in cluster 100 depicted in FIG. 1; however, for purposes of focus and clarity some of those components have been omitted from FIG. 2. Cluster 202 includes at least hosts 208 and 210, however, it should be appreciated that many more hosts could be included in each of the depicted clusters. In particular, host 208 can include virtualization software that facilitates the creation of a master virtual machine (VM) 212. Master VM 212 can operate on a modified Kubernetes framework that allows it to govern and administer over a number of VMs, Pods and native Kubernetes clusters running contained within a VM. It should be noted that the master VM does not have to run on a Kubernetes framework and that this is merely one implementation example. Master VM 212 will include an authentication module allowing for the secure authentication of some users and particularly administrators. In some embodiments, these authentication components can include tools for interacting with and receiving login credentials taking many forms. For example, login credentials can be received from any of the following: (1) a reader capable of transmitting credentials stored on an identification badge, security card or electronic device; (2) one or more biometric readers configured to scan and transmit one or more identifying features of a user by analyzing a user's retina, finger prints and/or voice; and (3) a user input device configured to allow the user to enter a username and password. Some services can require a user to submit multiple forms of authentication from one or more of the aforementioned categories.

Host 208 can run different types of virtual constructs that include VMs 214 and pods 216. Pods 216 can run natively on virtualization software associated with hosts 208 and 210 of cluster 202. Multiple containers can be instantiated and run within each of pods 216. Other virtual construct options include running a Kubernetes cluster taking the form of a guest cluster 218 within one of VMs 214. Guest clusters include a master VM 222, a standard Kubernetes® control plane and associated nodes, as well as components for interfacing the underlying supervisor cluster. The guest cluster executes within compute objects managed by the supervisor cluster (e.g., native VMs or both native VMs and pod VMs) and utilizes networking and storage exposed by the supervisor cluster. In this manner, a guest cluster is a virtual extension of an underlying management cluster (i.e., the supervisor cluster). Guest cluster 218 allows a service administrator to instantiate a desired number of containers 220 to support the service. In some embodiments, each of VMs 214, pods 216 and guest clusters 218 can be configured with different security rules that allow users different levels of access to content hosted on the same host and/or server. To support this type of functionality users are often required to provide credentials when initially accessing a different service. In some embodiments, a service running on one VM or container may be able to auto-scale across different hosts or clusters to give a user access to another VM or container running the same service without requiring the user to provide a new set of login credentials.

FIGS. 3A-3C shows a series of states of a master VM and a management server in accordance with the described embodiments. FIG. 3A shows a first state of master VM 212 prior to shut down. This can occur where a host or server cluster upon which the master VM is running needs to shut down or reboot for applying updates and/or performing maintenance. As depicted, master VM 212 can include a non-persistent storage 302 where multiple encryption keys 304 and passwords 306 are saved. In some embodiments, non-persistent storage 302 can take the form of a portion of the physical RAM of host 208 allocated to master VM 212. Master VM 212 also has access to persistent storage 308, which can take the form of an allocated portion of a physical storage device of host 208 or a storage area network (SAN) that is shared by multiple hosts or clusters of exemplary computing environment 200. A portion of persistent storage 308 can be encrypted with one of encryption keys 304, preventing unauthorized access to authentication data or other sensitive data stored within.

Prior to shutdown, master VM 212 can optionally send a communication 312 to management server 206 informing management server 206 of an imminent shutdown. This communication 312 can also be part of a standard synchronization transmission carried out between the host upon which master VM 212 runs and management server 206. In some embodiments, communication 312 can include an estimated time of its next scheduled instantiation. Communication 312 can also include a copy of the encryption key needed to access encrypted region 310 of persistent storage 308 for safe keeping. Prior to shutdown master VM 212 can also save any updates to encryption keys 304 and passwords 306 within encrypted region 310 of persistent storage 308, which may contain older versions of the encryption keys and/or passwords. In some embodiments, transmission of the encryption key associated with encryption region 310 to management server 206 can be unnecessary where management server 206 is responsible for issuing and updating the encryption keys for encrypted region 310 of persistent storage 308. In some embodiments, each master VM running in a cluster can use the same encryption key on account of persistent storage 308 being shared across the server cluster.

FIG. 3B shows master VM 212 in a second state after master VM 212 has been shut down. Non-persistent storage 302 associated with VM 212 is purged on shutdown of master VM 212, leaving only encrypted region 310 of persistent storage 308 with current versions of encryption keys 304 and passwords 306. Management server 206 monitors a state of master VM 212 as part of a synchronization process between management server 206 and the host upon which master VM 212 runs that includes reports of any new VM instantiations, allowing management server 206 to determine when master VM 212 has been instantiated. In some embodiments, a frequency with which management server 206 synchronizes with the various hosts making up the server cluster to check on the status of master VM 212 can increase after a threshold period of time or around the time master VM 212 informed management server 206 it estimated being instantiated again. In some embodiments, this synchronization process can be part of a regular process that always runs on the server at a fixed interval of between 10 and 30 seconds. Once master VM 212 is instantiated it includes no encryption keys to communicate securely with management server 206 or any other devices or services since all its encryption keys 304 and passwords 306 are stored within encrypted region 310 of persistent storage 308 and the encryption key needed to access encrypted region 310 of persistent storage 308 is also unavailable. To prevent the generation of unnecessary errors, a service running within VM 212 can be configured to interrupt the execution of services dependent on authentication data stored within encrypted region 310 by master VM 212 until management server 206 initiates a transmission 314 over a secure channel that includes an encryption key 316 to master VM 212. The encryption key is configured to provide access to encrypted region 310 of persistent storage 308.

It should be noted that while encryption key is depicted as being transmitted directly to master VM 212, encryption key 316 can be initially received by the virtualization software responsible for managing VMs on host 208, sometimes referred to as a hypervisor, which can then be responsible for delivering encryption key 316 to master VM 212. In some embodiments, the transmission 314 can include instructions for the virtualization software regarding timing of when encryption key 316 should be delivered to master VM 212. For example, delivery of encryption key 316 can be delayed until master VM 212 is ready to initiate guest operations.

FIG. 3C shows master VM 212 in a third state after encryption key 316 has been transmitted back to instantiated master VM 212. Once encryption key 316 is received and stored in non-persistent storage 302, master VM 212 can access and retrieve encryption keys 304 and passwords 306 from encrypted region 310 of persistent storage 308. In this way, master VM 212 can return to normal operation without ever placing unencrypted authentication data onto persistent storage 308. Management server 206 can retain encryption key 316 in storage in the event master VM 212 suffers an unexpected crash and needs to regain access to encrypted region 310 of persistent storage 308. In embodiments where encrypted region 310 is shared across a number of different master VMs, management server 206 can be responsible for periodically updating encryption key 316 in order to improve security.

FIG. 4 shows a flow diagram 400 illustrating a process for securely providing access to authentication data that includes passwords and encryption keys to a newly instantiated virtual machine. The process can be performed by a server cluster in communication with a management server. At 402, a virtual machine is instantiated on a server cluster. The virtual machine can be a master VM, which is configured to run with elevated privileges that allow it to assist in the administration of various virtual constructs such as other VMs, Pods and guest clusters running on the cluster. However, in order to keep the server cluster secure, persistent storage, which the newly instantiated VM has access to, does not contain any encryption keys to provide the VM the access it needs to perform the tasks for which it is responsible. Authentication data including passwords and encryption keys capable of giving the VM the access it needs are stored on an encrypted portion of the persistent storage that is inaccessible to the VM without a private encryption key. At 404, a management server paired and in communication with the server cluster upon which the virtual machine is instantiated can be configured to repeatedly synchronize with the server cluster. During the synchronization the server cluster can report any changes made to the management server. These changes can include the instantiation of VMs, pods and guest clusters and the termination of the same. After receiving a report of the VM instantiated at 402, a communication is received from the management server that includes an encryption key for providing access to the encrypted region of the persistent storage to the VM. In some embodiments, the communication can include timing instructions requesting virtualization software managing operation of the server cluster delay delivery of the encryption key until the VM reaches a predetermined state of readiness. For example, the encryption key can be delivered only after the VM is ready to conduct guest operations. At 406, once the VM is given access to the encryption key and uses the encryption key to decrypt the authentication data stored within the encrypted region of the persistent storage, the VM can be configured to begin running services on the server cluster that depend on the authentication data.

The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the described embodiments. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the described embodiments. Thus, the foregoing descriptions of specific embodiments are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the described embodiments to the precise forms disclosed. It will be apparent to one of ordinary skill in the art that many modifications and variations are possible in view of the above teachings.

Claims

1. A computer implemented method performed on a server cluster, comprising:

instantiating a virtual machine on the server cluster, wherein the virtual machine has access to persistent storage that includes an encrypted region and wherein the virtual machine lacks access to an encryption key configured to provide access to authentication data stored within the encrypted region;
receiving a communication at the server cluster from a management server associated with the server cluster that includes the encryption key configured to provide access to the encrypted region of the persistent storage;
storing the encryption key received from the management server in non-persistent storage accessible by the virtual machine;
decrypting the authentication data stored within the encrypted region using the encryption key; and
running a plurality of different services using the authentication data stored within the encrypted region to operate after decrypting the authentication data, wherein the authentication data is separate and distinct from the encryption key.

2. The computer implemented method as recited in claim 1, wherein the communication received from the management server is delivered to the virtual machine by virtualization software running on a host associated with the virtual machine.

3. The computer implemented method as recited in claim 2, wherein the communication received from the management server directs the virtualization software to delay delivery of the encryption key to the virtual machine until the virtual machine reaches a predetermined state in which it is ready to initiate guest operations.

4. The computer implemented method as recited in claim 1, further comprising:

elevating privileges of the virtual machine on the server cluster using the authentication data,
wherein running the plurality of different services comprises administering a plurality of virtual constructs comprising a plurality of virtual machines.

5. The computer implemented method as recited in claim 1, wherein all data stored on the persistent storage is within the encrypted region.

6. The computer implemented method as recited in claim 1, wherein the authentication data stored on the encrypted region of the persistent storage comprises encryption keys and passwords.

7. The computer implemented method as recited in claim 1, wherein the encryption key is never written to the persistent storage of the server cluster in an unencrypted state.

8. The computer implemented method as recited in claim 1, further comprising shutting down the virtual machine without saving the encryption key to persistent storage.

9. A non-transitory computer-readable storage medium storing instructions configured to be executed by one or more processors of a server cluster cause the server cluster to carry out steps that include:

instantiating a virtual machine on the server cluster, wherein the virtual machine has access to persistent storage that includes an encrypted region and wherein the virtual machine lacks access to an encryption key configured to provide access to authentication data stored within the encrypted region;
obtaining a communication from a management server associated with the server cluster that includes the encryption key configured to provide access to the encrypted region of the persistent storage; and
running a plurality of different services using the authentication data stored within the encrypted region to operate after decrypting the authentication data, wherein the authentication data is separate and distinct from the encryption key.

10. The non-transitory computer-readable storage medium as recited in claim 9, wherein the steps carried about by the server cluster further comprise:

storing the encryption key received from the management server in non-persistent storage accessible by the virtual machine; and
decrypting the data stored within the encrypted region.

11. The non-transitory computer-readable storage medium as recited in claim 9, wherein the server cluster includes virtualization software configured to deliver the encryption key to the virtual machine.

12. The non-transitory computer-readable storage medium as recited in claim 9, wherein the encryption key is never written to the persistent storage of the server cluster in an unencrypted state.

13. The non-transitory computer-readable storage medium as recited in claim 9, wherein the data stored on the persistent storage comprises encryption keys and passwords associated with one or more services configured to run on the server cluster.

14. The non-transitory computer-readable storage medium as recited in claim 9, wherein the steps carried about by the server cluster further comprise shutting down the virtual machine without saving the encryption key to persistent storage.

15. A server cluster, comprising:

one or more processors;
persistent storage, comprising an encrypted region;
non-persistent storage; and
memory storing one or more programs configured to be executed by the one or more processors, the one or more programs including instructions for: instantiating a virtual machine on the server cluster, wherein the virtual machine has access to the persistent storage and lacks access to an encryption key configured to provide access to authentication data stored within the encrypted region; receiving a communication at the server cluster from a management server associated with the server cluster that includes the encryption key configured to provide access to the encrypted region of the persistent storage; storing the encryption key received from the management server in the non-persistent storage, which is accessible by the virtual machine; decrypting the authentication data stored within the encrypted region; and running a plurality of different services that utilize the authentication data stored within the encrypted region to operate after decrypting the stored authentication data,
wherein the stored authentication data is separate and distinct from the encryption key.

16. The server cluster as recited in claim 15, wherein the authentication data stored on the encrypted region of the persistent storage comprises encryption keys and passwords associated with the plurality of different services.

17. The server cluster as recited in claim 15, wherein the authentication data stored on the encrypted region of the persistent storage comprises an encryption key facilitating secure two-way communication between the virtual machine and the management server.

18. The server cluster as recited in claim 15, wherein the virtual machine is a master virtual machine and the server cluster comprises a plurality of master virtual machines.

19. The server cluster as recited in claim 15, wherein the encryption key is never written to the persistent storage in an unencrypted state.

20. The server cluster as recited in claim 15, wherein receiving the communication from the management server comprises delivering the communication to the virtual machine by virtualization software running on the server cluster.

Referenced Cited
U.S. Patent Documents
8060703 November 15, 2011 Desai
9292376 March 22, 2016 Ren
9584517 February 28, 2017 Roth
9864874 January 9, 2018 Shanbhag
9954680 April 24, 2018 Machani
10223538 March 5, 2019 Cignetti
10348693 July 9, 2019 Auradkar
10402578 September 3, 2019 Roth
10491568 November 26, 2019 Roth
10521360 December 31, 2019 Gibson
10521566 December 31, 2019 Choi
10684888 June 16, 2020 Sethuramalingam
10691619 June 23, 2020 Gibson
10841089 November 17, 2020 Neerumalla
11057496 July 6, 2021 Jambure
11340797 May 24, 2022 Murray
11343247 May 24, 2022 Ozarkar
11344504 May 31, 2022 Frederick
11347868 May 31, 2022 Araya
20050081066 April 14, 2005 Lahdensivu
20050278525 December 15, 2005 Douceur
20070113078 May 17, 2007 Witt
20070180449 August 2, 2007 Croft
20070192329 August 16, 2007 Croft
20080256645 October 16, 2008 Choi
20080320316 December 25, 2008 Waldspurger
20090282266 November 12, 2009 Fries
20100086134 April 8, 2010 Ureche
20110107331 May 5, 2011 Evans
20110154023 June 23, 2011 Smith
20110202765 August 18, 2011 McGrane
20110276806 November 10, 2011 Casper
20120066460 March 15, 2012 Bihani
20120173882 July 5, 2012 Horn
20130145477 June 6, 2013 Matsushima
20140059379 February 27, 2014 Ren
20140108786 April 17, 2014 Kreft
20140283010 September 18, 2014 Rutkowski
20140331060 November 6, 2014 Hayton
20140344420 November 20, 2014 Rjeili
20150128233 May 7, 2015 Nechytaylo
20150150125 May 28, 2015 Dulkin
20160127336 May 5, 2016 Cignetti
20160277368 September 22, 2016 Narayanaswamy
20160306815 October 20, 2016 Hertz
20160344582 November 24, 2016 Shivanna
20170061128 March 2, 2017 Novak
20170061138 March 2, 2017 Lambert
20170169233 June 15, 2017 Hsu
20180069844 March 8, 2018 Cignetti
20180150646 May 31, 2018 Roth
20180167204 June 14, 2018 Wall
20180255090 September 6, 2018 Kozloski
20180337991 November 22, 2018 Kumar
20190044708 February 7, 2019 Dewan
20190068561 February 28, 2019 Caragea
20190102568 April 4, 2019 Hausauer
20190171379 June 6, 2019 Van Riel
20190196731 June 27, 2019 Sapuntzakis
20190229908 July 25, 2019 Peddada
20190318102 October 17, 2019 Araya
20190340136 November 7, 2019 Irwin
20190349346 November 14, 2019 Curtis
20190349347 November 14, 2019 Curtis
20200034245 January 30, 2020 Kohler
20200073826 March 5, 2020 Tsirkin
20200073829 March 5, 2020 Tsirkin
20200133791 April 30, 2020 Liu
20200241906 July 30, 2020 Tsirkin
20200310845 October 1, 2020 Liguori
20200310850 October 1, 2020 Liguori
20210034791 February 4, 2021 Singh
20210049260 February 18, 2021 Misaizu
20220006620 January 6, 2022 Bursell
20220006787 January 6, 2022 Bursell
Foreign Patent Documents
3447667 October 2020 EP
WO-2005022821 March 2005 WO
WO-2020198539 October 2020 WO
Patent History
Patent number: 11611540
Type: Grant
Filed: Jul 1, 2020
Date of Patent: Mar 21, 2023
Patent Publication Number: 20220006792
Assignee: VMware, Inc. (Palo Alto, CA)
Inventors: Michal A. Jankowski (Sunnyvale, CA), Benjamin J. Corrie (Woodinville, WA), George Hicken (Palo Alto, CA), Christian Lita (Lakeway, TX)
Primary Examiner: David R Lazaro
Assistant Examiner: Berhanu Shitayewoldetadik
Application Number: 16/918,760
Classifications
Current U.S. Class: Using A Replacement Algorithm (epo) (711/E12.07)
International Classification: H04L 29/06 (20060101); H04L 29/08 (20060101); H04L 15/16 (20060101); G06F 15/16 (20060101); G06F 9/455 (20180101); G06F 9/50 (20060101); G06F 21/62 (20130101); H04L 9/32 (20060101); H04L 9/40 (20220101); H04L 67/1097 (20220101);