Abstract: One or more aspects of the present disclosure relate to allocating virtual memory to one or more virtual machines (VMs). The one or more VMs can be established by a hypervisor of a storage device. The virtual memory can be allocated to the established one or more VMs. The virtual memory can correspond to non-volatile (NV) memory of a global memory of the storage device.

Abstract: One or more aspects of the present disclosure relate to allocating virtual memory to one or more virtual machines (VMs). The one or more VMs can be established by a hypervisor of a storage device. The virtual memory can be allocated to the established one or more VMs. The virtual memory can correspond to non-volatile (NV) memory of a global memory of the storage device.

Abstract: Software emulations of physical devices allow protocol neutral communications between heterogeneous operating systems. Within a computing node of a storage cluster, a logical communications cut-through device connects a guest operating system to a front end adapter and enables the guest operating system to perform operations on an allocated portion of computing node memory without hypervisor intervention. The cut-through device may implement an industry standard memory-mapped interface, thereby enabling a guest operating system to discover the cut-through device and obtain access to memory that is shared with the hypervisor and/or another guest OS. Moreover, if guest OSs and/or the hypervisor share any communications protocol then the channel may be utilized at memory speeds. This may be advantageous in symmetric multiprocessing environments in which multiple guest OSs can have core affinities.

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.