IP Library › Granted Patent US 12,619,455
Granted Patent B2
US 12,619,455 · App. 17/568,591 · Granted May 5, 2026

Robust resource removal for virtual machines

Inventors: Michael Tsirkin (Haifa, IL); Karen Lee Noel (Pembroke, NH)
Assignee: Red Hat, Inc.
G06F9/45558G06F9/4411G06F9/45545G06F11/1484G06F2009/45575G06F2009/45583
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12,619,455
App. No.
17/568,591
Filed
Jan 4, 2022
Granted
May 5, 2026
Kind
B2
Art Unit
2196
USPC
718/1
Abstract

Systems and methods providing robust resource removal for virtual machines. In one implementation, a hypervisor may receive configuration data associated with a virtual machine (VM). The hypervisor may determine, based on the configuration data, a type of support by the VM of recovery from unexpected hardware resource removal. The hypervisor may identify, based on the type of support of recovery form unexpected hardware resource removal, a type of access of the VM to one or more hardware resources. The hypervisor may launch the VM according to the type of access to the one or more hardware resources.

Claims (64)

1 . A method comprising:

launching a first virtual machine (VM) with access to memory allocated to a second VM;

tasking the first VM with identifying configuration data in the memory allocated to the second VM that indicates a type of support by the second VM of recovery from unexpected hardware resource removal and transmitting the configuration data identified by the first VM in the memory allocated to the second VM to a hypervisor operating on a host operating system;

receiving, by the hypervisor operating on the host operating system, the configuration data identified by the first VM in the memory allocated to the second VM, wherein the second VM is separate from the first VM;

determining, based on the configuration data, the type of support by the second VM of recovery from unexpected hardware resource removal;

identifying, based on the type of support of recovery from unexpected hardware resource removal, a type of access of the second VM to one or more hardware resources; and

launching the second VM according to the type of access to the one or more hardware resources.

2 . The method of claim 1 , wherein the type of support is no support, and wherein the type of access is virtual device access.

3 . The method of claim 1 , wherein the type of support is support, and wherein the type of access is direct access.

4 . The method of claim 1 , further comprising:

determining, by the hypervisor, to deallocate one of the one or more hardware resources;

responsive to determining that the type of support by the second VM is support, suspending the second VM; and

responsive to receiving an acknowledgment that the second VM has been suspended, deallocating the one of the one or more hardware resources.

5 . The method of claim 1 , further comprising:

determining, by the hypervisor, to deallocate one of the one or more hardware resources assigned to the second VM, wherein the one of the one or more hardware resources is part of a physical device; and

responsive to determining that the type of support by the second VM is support, removing the physical device from the second VM.

6 . The method of claim 1 , wherein determining, based on the configuration data, the type of support by the second VM of recovery from unexpected hardware resource removal of comprises:

identifying, in a data structure, an entry that corresponds to the configuration data; and

determining, based on the identified entry, whether the second VM supports recovery from removal of the one or more hardware resources.

7 . The method of claim 1 , further comprising:

storing, in hypervisor memory, an indicator associated with the second VM, wherein the indicator indicate the type of support by the second VM of recovery from unexpected hardware resource removal.

8 . The method of claim 1 , wherein the configuration data comprises at least one of a version of a device driver installed on the second VM, a version of a guest operating system installed on the second VM, a list of drivers installed on the second VM, or a vendor of a driver installed on the second VM.

9 . A system comprising:

a memory; and

a processing device operatively coupled to the memory, the processing device to:

launch a first virtual machine (VM) with access to memory allocated to a second VM;

task the first VM with identifying configuration data in the memory allocated to the second VM that includes information related to a device driver installed on the second VM and transmitting the configuration data identified by the first VM in the memory allocated to the second VM to a hypervisor;

receive, by the hypervisor, the configuration data identified by the first VM in the memory allocated to the second VM, wherein the second VM is separate from the second VM;

identify, by the hypervisor, the device driver installed on the second VM based on the configuration data;

determine whether at least one parameter of a plurality of parameters associated with the device driver matches a surprise removal support capability parameter, wherein the surprise removal support capability parameter indicates that the device driver supports surprise removal of one or more hardware resources supported by the device driver; and

responsive to determining that the at least one parameter of the plurality of parameters associated with the device driver matches the surprise removal support capability parameter, launching the second VM with direct access to the one or more hardware resources supported by the device driver via mapping physical device memory of the one or more hardware resources to a virtual memory address range of the second VM.

10 . The system of claim 9 , wherein the processing device is further to:

responsive to determining that the at least one parameter of the plurality of parameters associated with the device driver does not match the surprise removal support capability parameter, launch the second VM; and

providing the second VM access to the one or more hardware resources through a virtual device.

11 . The system of claim 9 , wherein the processing device is further to:

determine, by the hypervisor, to deallocate one of the one or more hardware resources assigned to the second VM;

responsive to determining that the at least one parameter of the plurality of parameters associated with the device driver matches the surprise removal support capability parameter, suspend the second VM; and

responsive to receiving an acknowledgment that the second VM has been suspended, deallocate the one of the one or more hardware resources.

12 . The system of claim 9 , wherein the processing device is further to:

responsive to determining that the at least one parameter of the plurality of parameters associated with the device driver does not match the surprise removal support capability parameter, determine that the second VM does not support recovery from unexpected removal of hardware resources;

responsive to determining that the at least one parameter of the plurality of parameters associated with the device driver matches the surprise removal support capability parameter, determine that the second VM supports recovery from unexpected removal of the hardware resources; and

store, in hypervisor memory, an indicator associated with the second VM, wherein the indicator indicates whether the second VM supports recovery from unexpected removal of the hardware resources.

13 . A non-transitory computer-readable media storing instructions that, when executed, cause a processing device to:

launch a first virtual machine (VM) with access to memory allocated to a second VM;

task the first VM with identifying configuration data in the memory allocated to the second VM that indicates a type of support by the second VM of recovery from unexpected hardware resource removal and transmitting the configuration data identified by the first VM in the memory allocated to the second VM to a hypervisor operating on a host operating system;

receive, by the hypervisor operating on the host operating system, the configuration data identified by the first VM in the memory allocated to the second VM, wherein the second VM is separate from the second VM;

determine, based on the configuration data, a type of support by the second VM of recovery from unexpected hardware resource removal;

identify, based on the type of support of recovery from unexpected hardware resource removal, a type of access of the second VM to one or more hardware resources; and

launch the second VM according to the type of access to the one or more hardware resources.

14 . The non-transitory computer-readable media of claim 13 , wherein the type of support is no support, and wherein the type of access is virtual device access.

15 . The non-transitory computer-readable media of claim 13 , wherein the type of support is support, and the type of access is direct access.

16 . The non-transitory computer-readable media of claim 13 , further comprising:

determining, by the hypervisor, to deallocate one of the one or more hardware resources assigned to the second VM, wherein the one of the one or more hardware resources is part of a physical device; and

responsive to determining that the type of support by the second VM is support, removing the physical device from the second VM.

17 . The non-transitory computer-readable media of claim 13 , wherein determining, based on the configuration data, the type of support by the second VM of recovery from unexpected hardware resource removal comprises:

identifying, in a data structure, an entry that corresponds to the configuration data; and

determining, based on the identified entry, whether the second VM supports recovery form removal of the one or more hardware resources.

18 . The non-transitory computer-readable media of claim 13 , wherein the configuration data comprises at least one of a version of a device driver installed on the second VM, a version of a guest operating system installed on the second VM, a list of drivers installed on the second VM, or a vendor of a driver installed on the second VM.

19 . The non-transitory computer-readable media of claim 13 , further comprising:

storing, in hypervisor memory, an indicator associated with the second VM, wherein the indicator indicates the type of support by the second VM of recovery from unexpected hardware resource removal.

20 . The non-transitory computer-readable media of claim 13 , further comprising:

determining, by the hypervisor, to deallocate one of the one or more hardware resources;

responsive to determining that the type of support by the second VM is support, suspending the second VM; and

responsive to receiving an acknowledgment that the second VM has been suspended, deallocating the one of the one or more hardware resources.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jan 5, 2022
From: TSIRKIN, MICHAEL; NOEL, KAREN LEE
To: RED HAT, INC.
Reel/Frame 058554/0220 →
Continuity (1)
Related Publication 20230214247A1 · Jul 6, 2023
References Cited (35)
US 8321617B1 · Haga · 2012 [cited by examiner]
US 8429675B1 · Radhakrishnan · 2013 [cited by examiner]
US 8589940B2 · Lim et al. · 2013 [cited by applicant]
US 8667496B2 · Levin · 2014 [cited by applicant]
US 8789069B2 · Green et al. · 2014 [cited by applicant]
US 8856788B2 · Tsirkin · 2014 [cited by examiner]
US 8910152B1 · Hyser · 2014 [cited by examiner]
US 9015709B2 · Voccio · 2015 [cited by examiner]
US 9396004B1 · Bester · 2016 [cited by examiner]
US 9817688B2 · Kaplan · 2017 [cited by examiner]
US 10394586B2 · Tsirkin · 2019 [cited by applicant]
US 10496424B2 · Shah · 2019 [cited by examiner]
US 10698784B2 · Tsirkin · 2020 [cited by examiner]
US 11093275B2 · Tsirkin · 2021 [cited by examiner]
US 11822948B2 · Tsirkin · 2023 [cited by examiner]
US 12056538B1 · Ozerkov · 2024 [cited by examiner]
US 20100211958A1 · Madison, Jr. et al. · 2010 [cited by applicant]
US 20110023028A1 · Nandagopal · 2011 [cited by examiner]
US 20110126198A1 · Vilke · 2011 [cited by examiner]
US 20120278818A1 · Green · 2012 [cited by examiner]
US 20130055254A1 · Avasthi · 2013 [cited by examiner]
US 20130326505A1 · Shah · 2013 [cited by examiner]
US 20140068606A1 · Tsirkin · 2014 [cited by examiner]
US 20140373010A1 · Folco et al. · 2014 [cited by applicant]
US 20150033227A1 · Lin · 2015 [cited by examiner]
US 20170046187A1 · Tsirkin · 2017 [cited by examiner]
US 20170187694A1 · Friedman · 2017 [cited by examiner]
US 20170293538A1 · Seenappa · 2017 [cited by examiner]
US 20180011728A1 · Nasu · 2018 [cited by examiner]
US 20190121745A1 · Hoppert · 2019 [cited by examiner]
US 20200341785A1 · Tsirkin · 2020 [cited by examiner]
US 20230067904A1 · Kumar · 2023 [cited by examiner]
Wang, et al., “Application-Aware Cross-layer Virtual Machine Resource Management” Proceedings of the 9th International Conference on Autonomic Computing, Sep. 18-20, 2012, pp. 13-22, Miami, FL, USA. [cited by applicant]
He et al., “Elastic Application Container: A Lightweight Approach for Cloud Resource Provisioning,” Proceedings of International Conference on Advanced Information Networking and Applications, Mar. 2012, pp. 15-22, Lond… [cited by applicant]
Andreolini et al., “Dynamic Load Management of Virtual Machines in Cloud Architectures,” Cloud Computing. CloudComp 2009. Lecture Notes of the Institute for Computer Sciences, Department of Information Engineering, Univ… [cited by applicant]