Robust resource removal for virtual machines
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.
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.