Multi-hypervisor virtual machines

• US 9,798,567 B2
• Filed: 11/20/2015
• Issued: 10/24/2017
• Est. Priority Date: 11/25/2014
• Status: Active Grant

• Current Assignee: The Research Foundation for The State University of New York (State University of New York)
• Original Assignee: The Research Foundation for The State University of New York (State University of New York)
• Inventors: Hu, Yaohui, Gopalan, Kartik
• Primary Examiner(s): Sun, Charlie
• Application Number:
  US14/947,595
• Publication Number:
  US 20160147556A1
• Time in Patent Office: 704 Days
• CPC Class Codes: G06F 2009/4557 Distribution of virtual machine instances; Migration and load balancing
• CPC Class Codes: G06F 2009/45579 I/O management, e.g. providing access to device drivers or storage
• CPC Class Codes: G06F 9/45558 Hypervisor-specific management and integration aspects

Abstract

Standard nested virtualization allows a hypervisor to run other hypervisors as guests, i.e. a level-0 (L0) hypervisor can run multiple level-1 (L1) hypervisors, each of which can run multiple level-2 (L2) virtual machines (VMs), with each L2 VM is restricted to run on only one L1 hypervisor. Span provides a Multi-hypervisor VM in which a single VM can simultaneously run on multiple hypervisors, which permits a VM to benefit from different services provided by multiple hypervisors that co-exist on a single physical machine. Span allows (a) the memory footprint of the VM to be shared across two hypervisors, and (b) the responsibility for CPU and I/O scheduling to be distributed among the two hypervisors. Span VMs can achieve performance comparable to traditional (single-hypervisor) nested VMs for common benchmarks.

Claims

1. A multi-hypervisor virtual machine system, comprising:

a unitary host machine including one or more processors;

at least one unitary virtual machine from a plurality of unitary virtual machines which concurrently relies on each of at least two concurrently available hypervisors to interface with the unitary host machine; and

the at least two concurrently available hypervisors,

the at least one unitary virtual machine being configured to concurrently communicate with the at least two concurrently available hypervisors to execute on the unitary host machine,

wherein a first concurrently available hypervisor from the at least two concurrently available hypervisors controls a first virtual central processing unit of the at least one unitary virtual machine, and a second concurrently available hypervisor from the at least two concurrently available hypervisors controls a second virtual central processing unit of the at least one unitary virtual machine, and

wherein the first concurrently available hypervisor is selected for relaying input/output requests generated from the at least one unitary virtual machine running on the second virtual central processing unit to the first virtual central processing unit, such that when outgoing packets from the at least one unitary virtual machine switch back and forth between the first concurrently available hypervisor and the second concurrently available hypervisor, the outgoing packets from the at least one unitary virtual machine are restricted to exit via only the first concurrently available hypervisor.

2. The multi-hypervisor virtual machine system according to claim 1, wherein one concurrently available hypervisor from the at least two concurrently available hypervisors is hierarchically inferior to another concurrently available hypervisor from the at least two concurrently available hypervisors.

3. The multi-hypervisor virtual machine system according to claim 1, wherein the at least two concurrently available hypervisors have respectively different sets of execution privileges.

4. The multi-hypervisor virtual machine system according to claim 1, wherein the existence of the at least two concurrently available hypervisors is transparent to a guest operating system which executes on the at least one unitary virtual machine.

5. The multi-hypervisor virtual machine system according to claim 1, wherein an operating system and applications of the at least one unitary virtual machine execute substantially without explicit control by the operating system and the applications over a selection of respective actions of the at least two concurrently available hypervisors.

6. The multi-hypervisor virtual machine system according to claim 1, wherein at least one portion of a memory map associated with the at least one unitary virtual machine is associated exclusively with a single concurrently available hypervisor from the at least two concurrently available hypervisors.

7. The multi-hypervisor virtual machine system according to claim 1, wherein a plurality of concurrently available hypervisors from the at least two concurrently available hypervisors partition responsibility for scheduling at least one respective virtual central processing unit of the unitary host machine.

8. The multi-hypervisor virtual machine system according to claim 1, wherein the at least two concurrently available hypervisors offer different services to the at least one unitary virtual machine.

9. The multi-hypervisor virtual machine system according to claim 1, wherein the plurality of unitary virtual machines are provided, and at least two of the plurality of unitary virtual machines rely on the at least two concurrently available hypervisors to interface with the unitary host machine.

10. The multi-hypervisor virtual machine system according to claim 1, wherein responsibility for servicing the input/output requests of the at least one unitary virtual machine is partitioned at a device-level granularity among a plurality of the concurrently available hypervisors from the at least two concurrently available hypervisors.

11. The multi-hypervisor virtual machine system according to claim 1, wherein the at least one unitary virtual machine is configured to execute a guest operating system which supports a polling mode driver for receiving communications via the first concurrently available hypervisor, substantially without interrupts.

12. The multi-hypervisor virtual machine system according to claim 1, wherein the first concurrently available hypervisor which controls the first virtual central processing unit of the at least one unitary virtual machine is selected for relaying the input/output requests generated from the at least one unitary virtual machine on the second virtual central processing unit controlled by the second concurrently available hypervisor.

13. The multi-hypervisor virtual machine system according to claim 1, wherein the first concurrently available hypervisor is selected for relaying device interrupts to the second concurrently available hypervisor for delivery to the second virtual central processing unit of the at least one unitary virtual machine controlled by the second concurrently available hypervisor.

14. The multi-hypervisor virtual machine system according to claim 13, wherein the device interrupts are generated by at least one hardware device, and delivered to the first virtual central processing unit of the at least one unitary virtual machine per an interrupt affinity specified by a guest operating system executing in the at least one unitary virtual machine.

15. The multi-hypervisor virtual machine system according to claim 1, wherein responsibility for servicing the input/output requests of the at least one unitary virtual machine is partitioned at a device-level granularity among a plurality of concurrently available hypervisors from the at least two concurrently available hypervisors.

16. A method for providing multiple hypervisors for a virtual machine system, comprising:

providing a unitary host machine including one or more processors;

providing at least two hypervisors which are concurrently available and independently execute on the unitary host machine; and

executing a unitary virtual machine which concurrently relies on the at least two concurrently available hypervisors to interface with the unitary host machine, the unitary virtual machine having a memory map which has portions accessible by each of the at least two concurrently available hypervisors,

wherein a first hypervisor of the at least two hypervisors is selected for relaying input/output requests generated from each of the at least two hypervisors on the unitary virtual machine, such that when outgoing packets from the unitary virtual machine switch back and forth between the at least two hypervisors, the outgoing packets from the unitary virtual machine are restricted to exit via only the first hypervisor.

17. The method according to claim 16, wherein one of the at least two concurrently available hypervisors is hierarchically inferior to another of the at least two concurrently available hypervisors.

18. The method according to claim 16, wherein:

the at least two hypervisors have respectively different sets of execution privileges and offer different services to the unitary virtual machine, and

responsibility for servicing the input/output requests of the unitary virtual machine is partitioned at a device-level granularity among a plurality of hypervisors from the at least two hypervisors to select the first hypervisor from the at least two hypervisors.

19. A method for providing multiple hypervisors for a virtual machine system, comprising:

providing a single virtual machine supporting execution of a guest operating system and having a memory map, the guest operating system supporting execution of applications, on hardware resources of a unitary host machine including one or more processors;

providing at least two concurrently available and independently executing hypervisors which each concurrently interface the single virtual machine to the unitary host machine, the at least two concurrently available and independently executing hypervisors each having access to at least a respective portion of the memory map;

performing a first action by the single virtual machine which employs resources provided by a first hypervisor of the at least two concurrently available and independently executing hypervisors, and controls at least one virtual central processing unit of the single virtual machine;

performing a second action by the single virtual machine which employs resources provided by a second hypervisor of the at least two concurrently available and independently executing hypervisors;

servicing input/output requests of the single virtual machine by the first hypervisor, on behalf of both the first hypervisor and the second hypervisor, such that when outgoing packets from the single virtual machine switch back and forth between the first hypervisor and the second hypervisor, the outgoing packets from the at least one unitary virtual machine are restricted to exit via only the first hypervisor; and

relaying device interrupts from the first hypervisor to the second hypervisor,

wherein the first and second hypervisors have respectively different sets of execution privileges and offer different services to the single virtual machine.

20. The method according to claim 19, wherein the at least two concurrently available and independently executing hypervisors each have respectively different sets of execution privileges.