Abstract: A non-disruptive, non-migratory hypervisor reboot is performed by suspending execution of the guest operating system, rebooting the container, and then resuming execution of the guest operating system. Suspending execution of the guest operating system can include stopping guest OS access to processing resources. Reboot includes the container loading or reloading itself while preserving the contents of the volatile memory in place. It is also possible to relocate some or all of the contents of the volatile memory to different addresses by creating an abstraction layer.

Abstract: When a guest OS loads within the context of a container provided by the host OS, the guest OS uses PCI or other protocol to specify a virtual hardware device. The guest OS enumerates the virtual hardware device to establish the size for the BARs and establish its view of physical addresses for the memory locations. A server running in the context of the container receives read/write requests from the guest OS, maps the read/write requests to host OS physical address space, and posts responses to the virtual hardware device. Since the guest OS executes memory related operations using its own memory space, exits to the container code are not required to implement storage related actions by the Guest OS. This allows performance of an application executing in the context of the guest OS to approximate performance of an application executing in the context of the host OS.