Apparatus and method for emulating or para-virtualizing physical function of resource

Abstract

Apparatus and methods for emulating or para-virtualizing physical functions of a resource are described. An apparatus is provided that includes interface circuitry, machine-readable instructions, and processing circuitry for executing the machine-readable instructions. The machine-readable instructions include instructions to receive a request for a virtual machine to access a resource of a network node, determine whether a number of available virtual functions associated with the resource is below a predefined threshold, and if it is determined that the number of available virtual functions is below the predefined threshold, send the virtual machine to the network node. And if so, simulating and / or para-virtualizing the physical function associated with the resource. The machine-readable instructions also include instructions for providing access to the resource through a physical function for emulation and / or para-virtualization of the virtual machine.

Description

Background Art

[0001] The number of virtual functions for resources in a network node is usually limited. When all virtual functions are occupied, new requests to access resources will not be served and will be rejected. This is particularly important in environments that are sensitive to quality of service. Therefore, there is a need for improved resource control. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Some examples of apparatus and / or methods will be described below, by way of example only, and with reference to the accompanying drawings, in which:

[0003] Figure 1a and 1b An example of an apparatus for emulating and / or paravirtualizing the physical functionality of a resource is shown;

[0004] Figure 2 An example of a conventional IO (input / output) device is shown;

[0005] Figure 3 An example of improving IO devices is shown;

[0006] Figure 4 An example of an architecture of an apparatus for emulating and / or paravirtualizing physical functions of resources is shown;

[0007] Figure 5 An example of a method for emulating and / or paravirtualizing the physical functionality of a resource is shown;

[0008] Figure 6 Another example of a method for emulating and / or paravirtualizing physical functionality of a resource is shown;

[0009] Figure 7 An example of a configuration of a network node is shown; and

[0010] Figure 8 An example of negotiation between virtual machines is shown. DETAILED DESCRIPTION

[0011] Some examples are now described in more detail with reference to the accompanying drawings. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of features and equivalents and substitutes of features. In addition, the terms used herein to describe specific examples should not limit other possible examples.

[0012] Throughout the description of the drawings, the same or similar reference numerals refer to the same or similar elements and / or features, which may be implemented in the same or modified form while providing the same or similar functions. For clarification, the thickness of lines, layers and / or regions in the drawings may be exaggerated.

[0013] When two elements A and B are combined using "or", this should be understood to disclose all possible combinations, i.e. only A, only B and A and B, unless otherwise explicitly defined in individual cases. As an alternative wording for the same combination, "at least one of A and B" or "A and / or B" can be used. The same applies to combinations of more than two elements.

[0014] If singular forms such as "a / an" and "the" are used, and the use of only a single element is not explicitly or implicitly defined as mandatory, further examples may also use multiple elements to achieve the same function. If the function is described below as being achieved by using multiple elements, further examples may use a single element or a single processing entity to achieve the same function. It will be further understood that the terms "include", "in-cluding", "comprise" and / or "comprising" when used in this specification describe the presence of stated specified features, integers, steps, operations, processes, elements, components and / or groups thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or groups thereof.

[0015] In the following description, specific details are set forth, but examples of the technology described herein can be implemented without these specific details. Well-known circuits, structures, and techniques are not shown in detail to avoid obscuring the understanding of this description. "One example / example", "various examples / examples", "some examples / examples", etc. may include features, structures, or characteristics, but not every example must include a particular feature, structure, or characteristic.

[0016] Some examples may have some, all, or none of the features described in other examples. "First," "second," "third," etc. describe a common element and indicate different instances of similar elements being referenced. Such adjectives do not mean that the element items so described must be arranged in a given order, either temporally or spatially, or in any other manner. "Connected" may mean that elements are in direct physical or electrical contact with each other, while "coupled" may mean that elements cooperate or interact with each other, but they may or may not be in direct physical or electrical contact.

[0017] As used herein, the terms "operate," "execute," or "run" as they relate to software or firmware associated with a system, device, platform, or resource may be used interchangeably, and may refer to software or firmware stored in one or more computer-readable storage media accessible to a system, device, platform, or resource, even if the instructions contained in the software or firmware are not actively executed by the system, device, platform, or resource.

[0018] The description may use the phrases "in one example / example", "in an example / example", "in some examples / examples", and / or "in various examples / examples", each of which may refer to one or more of the same or different examples. In addition, the terms "comprising", "in-cluding", "having", etc. used with respect to examples of the present disclosure are synonymous.

[0019] Figure 1a A block diagram of an example of an apparatus 100 or device 100 communicatively coupled to a computer system 110 is shown. Figure 1b A block diagram of an example of a computer system 110 including an apparatus 100 or device 100 is shown.

[0020] The device 100 includes circuits configured to provide the functionality of the device 100. For example, Figure 1a and 1b The apparatus 100 includes an interface circuit 120, a processing circuit 130, and (optionally) a storage circuit 140. For example, the processing circuit 130 may be coupled to the interface circuit 120 and the storage circuit 140.

[0021] For example, processing circuitry 130 may be configured to provide the functionality of apparatus 100 in conjunction with interface circuitry 120 (for exchanging information, such as with other components within or outside computer system 110 ) and storage circuitry 140 (for storing information, such as machine-readable instructions).

[0022] Likewise, the apparatus 100 may include means configured to provide the functionality of the apparatus 100 .

[0023] The components of the device 100 are defined as component means, which may correspond to or be implemented by corresponding structural components of the device 100. For example, Figure 1a and 1b The device 100 comprises means 130 for processing, which may correspond to the processing circuit 130 or be implemented by the processing circuit 130; means 120 for communicating, which may correspond to the interface circuit 120 or be implemented by the interface circuit 120; and (optionally) means 140 for storing information, which may correspond to the storage circuit 140 or be implemented by the storage circuit 140. In the following, the functions of the device 100 are shown relative to the device 100. Therefore, the features described in conjunction with the device 100 can also be applied to the corresponding device 100.

[0024] In general, the functionality of the processing circuit 130 or the means for processing 130 may be implemented by the processing circuit 130 or the means for processing 130 executing machine-readable instructions. Thus, any features attributed to the processing circuit 130 or the means for processing 130 may be defined by one or more of the plurality of machine-readable instructions. The apparatus 100 or device 100 may include, for example, machine-readable instructions within the storage circuit 140 or the means for storing information 140.

[0025] For example, the storage circuit 140 or the device 140 for storing information may include at least one element from the group of computer-readable storage media, such as a magnetic or optical storage medium (e.g., a hard drive, a flash memory, a floppy disk), a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electronically erasable programmable read-only memory (EEPROM), or a network storage device.

[0026] The interface circuit 120 or the means for communicating 120 may correspond to one or more inputs and / or outputs for receiving and / or sending information within a module, between modules, or between modules of different entities, which information may be a digital (bit) value according to a specified code. For example, the interface circuit 120 or the means for communicating 120 may include a circuit configured to receive and / or send information.

[0027] For example, the processing circuit 130 or the means for processing 130 may be implemented using one or more processing units, one or more processing devices, any means for processing, such as a processor, a computer, or a programmable hardware component operable with corresponding adapted software. In other words, the functions of the processing circuit 130 or the means for processing 130 may also be implemented in software and then executed on one or more programmable hardware components. Such hardware components may include general purpose processors, digital signal processors (DSPs), microcontrollers, etc.

[0028] Interface circuit 120 is configured to receive a request from a virtual machine (VM) to access resources of network node 150, for example, on computing system 110. Interface circuit 120 may receive the request from computing system 110 itself or an external device (e.g., a user device) via any communication coupling (wired or wireless).

[0029] The network nodes 150 may be physical devices and / or software applications configured to send, receive, or forward data through a computer network coupled to the computing system 110. The network nodes 150 may include devices such as computers, routers, switches, hubs, servers, and other network components. The network nodes 150 may connect multiple components of the computing system 110 to each other, or connect the computing system 110 to an external computing system. The network nodes 150 may provide, for example, wired connections such as Ethernet cables or fiber optic links, and / or wireless connections such as Wi-Fi (Wireless Fidelity) or cellular networks. In some examples, the network nodes 150 include or are PCIe (Peripheral Component Interconnect Express: Peripheral Component Interconnect Express) buses.

[0030] The resources of the network node 150 can be devices or capabilities of the network node 150 that are accessible to other network nodes or users of the network node 150 (wherein the users are, for example, virtual machines or operating systems). A resource can have a unique identifier for locating and accessing the resource. A resource can also have additional attributes, such as access permissions, which determine how the resource can be used. In order to share resources with other network nodes or users, it can be made available on a computer network, for example, through resource sharing. This can involve configuring the network node 150 to allow other network nodes or users to access the resource, and optionally, setting access permissions and security measures to ensure that the resource is used in an expected manner. In some examples, the resource is the bandwidth of a PCIe bus.

[0031] A VM may be a software emulation of a computing system that can run applications and operating systems in an isolated environment. A VM may be a software abstraction of a physical computer created by a virtualization layer running on a host computer, which may be computing system 110 or an external computing system. For example, the host computer may have installed a virtualization layer, such as a hypervisor or a virtual machine monitor (VMM), in which virtual machines are created, operated, and managed. When running an application, a VM may interact with other VMs or with hardware components coupled to network node 150. Therefore, a VM may eventually need to access resources of network node 150.

[0032] The processing circuit 130 is configured to determine whether the number of available virtual functions associated with the resource is below a predefined threshold.

[0033] For example, network node 150 may use hardware-based virtualization technology to create a virtual function (VF) that allows resources to be presented as multiple resources to the operating system and VMs of computing system 110. Each VF may be assigned to a corresponding VM. Each VF may be presented to the VM as a separate physical resource, for example, with its own MAC (media access control) address, device driver, etc. Hardware-based virtualization technology may enable the VM to directly access the VF, i.e., without the need for emulation or translation by the hypervisor or network node 150.

[0034] An example of such hardware-based virtualization technology is SR-IOV (Single Root Input / Output Virtualization). SR-IOV may be based on self-virtualization of the network node 150, i.e., the virtualization logic is mainly provided by the network node 150 rather than the VMM. For example, the network node 150 may be able to perform filtering or Ethernet bridging to demultiplex incoming traffic to multiple queues or host endpoints. For example, the hypervisor may virtualize the configuration space of the network node 150 and give limited access to part of the IO address space. SR-IOV may provide an extension to the PCI configuration space of the network node 150, enabling enumeration of VFs. It may also be built on address translation services to translate DMA (Direct Memory Access) addresses into host addresses. The physical device of the network node 150 may have one or more physical functions (PFs), each of which may provide multiple VFs.

[0035] SR-IOV can provide several advantages over other virtualization technologies, including improved performance, reduced overhead, and increased flexibility. By allowing virtual machines to directly access physical NICs (network interface controllers), SR-IOV can reduce the overhead associated with network I / O virtualization and improve network throughput and latency. SR-IOV can also provide greater flexibility in network resource allocation, allowing virtual machines to be assigned dedicated VFs with guaranteed bandwidth and quality of service (QoS) levels. Therefore, SR-IOV may be beneficial for use in data center environments that require high-performance networks, such as cloud computing, virtual desktop infrastructure (VDI), and high-performance computing (HPC) applications.

[0036] Typically, the number of VFs is limited. For example, PCIe endpoint devices and SR-IOV virtual functions from a particular PCIe bus can be assigned to a maximum of 15 domains. PCIe resources (such as interrupt vectors for each PCIe bus) can be divided between root domains and I / O domains. As a result, the number of VMs (or devices) that can be assigned to a particular resource (e.g., in the form of an I / O domain) is also limited.

[0037] Server hardware and edge client devices such as data center servers, IOT edge computing platforms, PCs (personal computers) and laptop industries may have an increasing demand for hardware virtualization support for IO devices (such as PCI interfaces), which is contrary to the limitation of the maximum virtual PCI interface (virtual function) that can be supported by the hardware. SR-IOV can provide efficient local sharing of I / O devices with virtual machines to enhance I / O performance, but in this case, the sharing of I / O devices is also limited by the number of virtual functions exposed by the physical functions of the corresponding PCI hardware resources. As VMM overhead is reduced and power efficiency is improved through microarchitectures and multi-core processors, the number of VMs per server is also increasing. Therefore, there may be a need for scalable access to resources of network nodes.

[0038] Furthermore, conventional allocation of VMs to virtual functions may be too inflexible or provide too little manageability to cope with dynamic environments with a large number of VMs requesting access to resources and an ever-increasing number of changing VMs and corresponding requests and demands. This may result in a lack of RDT (Resource Director Technology) support (e.g., for negotiation and assurance of service level agreements (SLAs)), leading to SLA violations and thus greatly limiting the adoption of such technologies in public cloud infrastructures. As a result, in public cloud multi-tenant instance deployments, SR-IOV VFs may typically have no dynamic resource partitioning or management available.

[0039] In contrast, the apparatus 100 can overcome these obstacles in the following manner: The processing circuit 130 can check the availability of virtual functions of the resource. If it is determined that the number of available virtual functions is below the above-mentioned predefined threshold, the processing circuit 130 is further configured to emulate and / or paravirtualize the physical functions associated with the resource.

[0040] The physical function may be a hardware component of the network node 150 (e.g., a network adapter) that provides the primary interface between the hardware component and the operating system of the host computer. It may be a function of the network node that the operating system and applications of the host computer can directly access. It may be a logical entity that provides access to the hardware resources of the network node 150, such as input / output ports, memory buffers, and interrupt request lines. The physical function may have created multiple VFs including the above-mentioned VFs associated with the resources. The physical function may be responsible for managing the creation and allocation of VFs, and for implementing QoS policies and security controls. In some examples, the physical function may be the above-mentioned physical function provided by the SR-IOV device.

[0041] The predefined thresholds may be selected based on the target application, for example, so that a certain occupancy of virtual functions is tolerated without further action. For example, the predefined thresholds may be selected so that 10%, 30%, 50%, 80%, 100%, etc. of the maximum number of virtual functions may be used in a conventional manner. Alternatively, the predefined thresholds may be selected so that even if all virtual functions are available, the use of physical functions is triggered. The predefined thresholds may be selected so that: when the number of available VFs reaches or falls below the threshold, either to expand the number of VMs that can access the resource, to keep cleared VFs in the presence of high priority requests to access the resource, or to enable negotiation between VMs regarding the remaining VFs and emulated and / or paravirtualized physical functions, the resource is in demand and it is desirable to avoid additional access to the resource.

[0042] Emulation and / or paravirtualization may be software-based virtualization, as opposed to hardware-based virtualization provided by virtual functions. For example, emulation and / or paravirtualization may be virtualization performed by a hypervisor. Emulation may be a virtualization technique that enables a VM (called a guest) to run software designed to use resources through a physical function (called a host) by creating a software environment that emulates the hardware and software of the physical function. Paravirtualization may be a virtualization technique that enables multiple virtual machines to run on a single physical function by allowing them to share access to the physical function. This may be accomplished by modifying the guest operating system to be aware of the virtual environment and interact directly with the hardware resources of the host.

[0043] The processing circuit 130 is also configured to provide access to resources via emulated and / or paravirtualized physical functions for virtual machines. In this way, the device 100 can expand the number of possible accesses to resources by VMs, set aside virtual functions for high priority access, and / or achieve the above-mentioned negotiation. In addition, the device 100 can help comply with QoS policies, SLAs, etc. In conventional systems, VMs are given access to virtual functions on a first-come, first-served basis, and any VM that is found to be fully occupied by a virtual function is denied and not given any access to the resource. Unlike this conventional system, the device 100 can provide a basis for priority-based allocation of resource access and expansion of resource availability.

[0044] Figure 2 An example of the architecture of a conventional SR-IOV device 200 is shown. A conventional SR-10V device 200 includes an IO device 210, such as a NIC that manages a network node. At the first layer 220, the SR-IOV device 200 provides a PHY (physical layer) 221, a layer 2 classifier 222 that serves as an engine for forwarding Ethernet frames to their corresponding output ports, a physical function 223, and multiple virtual functions 224 derived from the physical function 223. At the virtualization layer 230, such as in a VMM or hypervisor environment, the SR-IOV device 200 provides a software switch 231 that gives a host or service virtual machine 240 access to the resources of a network node. In addition, there are multiple guest OSs or VMs 250. Some VMs 250 directly access resources through VFs 224. When all VFs 224 are occupied, other VMs 250 are rejected. Existing architectures of IO virtualization of the SR-IOV device 200 may result in limitations because the SR-IOV device 200 cannot negotiate / accommodate new tenants due to limited virtual functions. In contrast, the apparatus 100 may enable expansion of the maximum allowed access to resources.

[0045] Returning to FIG. 1 , in some examples, interface circuitry 120 may be configured to receive an SLA for a virtual machine. Interface circuitry 120 may receive the SLA, for example, from computing system 110, from a VM, or from an external device via any communication coupling. In other examples, processing circuitry 130 may determine the SLA based on the specification of the access request or through negotiation with the VM. The SLA may be any agreement between two or more parties, such as a service provider (providing services on computing system 110) and a user (VM) sending a request, regarding a service provided by computing system 110 (e.g., providing access).

[0046] The SLA may be, for example, a customer-based, service-based, or multi-level-based SLA. In some examples, the apparatus 100 may further demonstrate (e.g., based on the needs of the (cloud) service provider) the ability to expose a specific application SLO (service-level objective) to, for example, a user to negotiate an SLA.

[0047] The processing circuit 130 may also be configured to determine at least one of resource tolerance and priority of the virtual machine based on the SLA. For example, the processing circuit 130 may be configured to determine resource tolerance by determining at least one of rate control, grouping priority, bonding options, fault tolerance, and migration tolerance of the virtual machine.

[0048] For example, a resource tolerance (application tolerance) may be specified by a VM. It may be, for example, a factor ranging from 0 to 1. It may represent tolerance for potential changes in the SLA regarding access to resources of the network node 150. Factor = 0 may indicate that the VM cannot tolerate any changes in resources, while factor = 1 may indicate that the VM is flexible to any changes in other resources. An example implementation of resource tolerance may be a function App_Tolerance_QoS = FUNC_MAPPER (rate_control, packet_prioritization, fault_tolerance, bonding, scheduling, migration_tolerance, reserved) where migration_tolerance may indicate tolerance for migration to a different network node under resource constraints. This includes stopping processes in the App / VM (typically in milliseconds) until negotiation with a different network node is successful.

[0049] The processing circuit 130 may also be configured to determine whether a virtual function or a physical function associated with a resource is to be provided to a virtual machine based on at least one of a resource tolerance and a priority, and if it is determined that a physical function is to be provided to a virtual machine, the physical function is simulated and / or paravirtualized. This may allow the processing circuit 130 to have increased controllability over the use of resources. For example, a VM with a higher priority may be preferred when providing a virtual function, while a VM with a lower priority may be assigned an emulated / paravirtualized physical function. In this way, when requesting resources, especially when the requested VM has a high priority, the device 100 can avoid service being denied. However, access services may be provided to low-priority VMs through emulated / paravirtualized physical functions.

[0050] In the case of receiving the SLA, in some examples, the processing circuit 130 can be configured to schedule the use of resources by the virtual machine based on at least one of the resource tolerance and the priority, and provide the virtual machine with access to the resource based on the use of the scheduled resources. Therefore, the priority and / or resource tolerance of the requesting VM can be reflected by the scheduling. For example, whenever a resource constraint is encountered, a high resource tolerance can obtain scheduling flexibility. A high priority may also obtain a privileged position in resource scheduling. For example, the processing circuit 130 may include a scheduler that allocates and configures resources. For example, the scheduler may generate and dynamically adjust the scheduling (e.g., the timeline of access, use, and release of resources) and / or the configuration of resources considering the priority and resource tolerance to achieve the best QoS. The scheduling can then be implemented by the resource control of the computing system 110. In order to schedule access to resources, the processing circuit 130 may perform any scheduling technique, such as priority, multi-level, polling, preemptive and / or collaborative scheduling.

[0051] For scheduling resource usage, other or further factors may be considered. For example, the processing circuit 130 may be configured to determine at least one of the number of emulations and / or paravirtualizations of physical functions, the corresponding capabilities of the emulations and / or paravirtualizations, the expected QoS of resource usage, and the risk of resource usage.

[0052] The device 100 can provide a resource allocation technology (Resource Director Technology) for SR-10V virtual functions of software-configurable VFs in PCI devices. The device 100 can extend the number limit of virtual functions supported by the physical functions of the SR-IOV device by implementing paravirtualization or software emulation of the physical functions exposed by the SR-IOV device, thereby providing hybrid software emulation. Once the paravirtualization or software emulation for the physical function is completed by the hypervisor or service OS, the SR-IOV device can be shared between other guest virtual machines that cannot access the virtual function due to the unavailability of the virtual function. For example, according to the specifications supported by SR-IOV, an example of an SR-IOV device can support up to eight virtual functions. The hypervisor (VMM) can maintain a resource table of virtual functions, and implement state machine control logic and corresponding priorities assigned to guest virtual machines, for example, according to life cycle and time-critical workloads.

[0053] For security reasons, the processing circuit 130 can be configured to access a list of trusted virtual machines stored in the zone processing block chain, determine whether the virtual machine is in the list, and deny access to the resource if it is determined that the virtual machine is not in the list. Using a zone processing block chain-based system to check the trustworthiness of guest virtual machines can provide several advantages including decentralized trust, i.e., the verification of the VM will rely on a decentralized network of nodes to reach a consensus on the validity of the guest VM's credentials, which means that no single entity can fully control the verification process, making it less susceptible to tampering or manipulation. Other advantages can be immutable record keeping, efficient verification, and reduced risk of running untrusted or malicious guest VMs.

[0054] In a multi-tenant environment, there may be multiple VMs. The interface circuit 120 may then receive multiple requests from multiple virtual machines to access resources. In some examples, the processing circuit 120 may be configured to negotiate corresponding SLAs with multiple virtual machines to access resources, and provide access to resources via emulated and / or paravirtualized physical functions for multiple virtual machines based on the negotiated SLAs. Negotiability may be achieved by providing an interface to multiple VMs for negotiating the use of resources, for example, by bidding and tendering via smart contracts.

[0055] In order to achieve highly dynamic manageability of resource access, the device 100 can further detect hot plugging or hot unplugging. Hot plugging can be a hardware feature that enables new hardware components to be added to the computing system 110 while it is running, without the need to shut down or restart. Hot plug devices can be designed to be physically inserted or removed from their connectors when the system is powered on, and the system automatically detects and configures the new hardware components. Hardware components can provide new resources or form new network nodes in the computing system 110. Hot unplugging can be the process of removing hardware components from the system while the system is running, without the need to shut down or restart the system. Hot plug devices can be designed to be physically removed from their connectors when the computing system 110 is powered on, and the computing system 110 automatically detects and removes hardware components from its configuration.

[0056] In these cases, the processing circuit 120 may be configured to determine such hot-plugging or hot-unplugging of a resource or another resource. This may change the number of available access channels: hot-plugging may increase the number of available resources, while hot-unplugging may reduce the number of available resources. Therefore, the processing circuit 120 may re-evaluate access to the resource and, for example, adjust access requirements or scheduling. Therefore, the processing circuit 120 may be configured to determine the number of available virtual functions based on the determined hot-plugging or hot-unplugging. The processing circuit 120 may also be configured to negotiate an SLA based on the determined number of available virtual functions.

[0057] To improve scheduling, for example, in terms of QoS, the apparatus 100 may track resource usage, store the tracked data, and use it, for example, for machine learning feedback. In some examples, the processing circuit 120 may be configured to monitor metrics of the simulated and / or paravirtualized physical functions and store the monitored metrics. For example, the processing circuit 120 may be configured to determine QoS of resource usage via the simulated and / or paravirtualized physical functions and store the determined quality of service.

[0058] In addition, a dedicated driver can be provided for access to physical functions through simulation and / or paravirtualization. For example, processing circuit 120 can be configured to send a driver for using simulation and / or paravirtualization functions to the virtual machine in response to receiving a request from the virtual machine. In the case of paravirtualization, the guest operating system of the VM can be modified by the driver to understand the virtual environment and directly interact with the hardware resources of the host without simulating them. In order to achieve this communication between the guest operating system and the host hardware resources, special software components may be required, such as paravirtualization drivers. Paravirtualization drivers can provide an interface between the guest operating system and the hypervisor. In the case of simulation, the guest operating system can interact with the simulated physical function by installing special software components, such as simulated device drivers. The simulated device driver can provide an interface between the guest operating system and the simulated hardware device of the virtual machine, which is used to translate the hardware access request of the guest operating system into the appropriate format for the simulated hardware device of the virtual machine.

[0059] In summary, the proposed apparatus 100 may involve an extension of the number limit of virtual functions, such as virtual functions supported by physical functions of SR-IOV devices, through paravirtualization or software emulation of physical functions. The SR-IOV devices may then be shared among other guest virtual machines that are not assigned virtual functions due to unavailability. The extended virtual functions may be exposed to an RDT manager having a bidirectional interface for negotiation that the tenant / guest operating system may use to negotiate SLAs. With the help of negotiated SLAs, an orchestrator may improve the efficiency of node / fleet management, and reward-based systems for tenants / apps that receive small payments in SLA negotiations, for example.

[0060] For example, the device 100 can improve the scalability of the data center without compromising on the SLA. It can dynamically negotiate resource allocations based on, for example, tolerance factors specified by the requesting VM or its application. This may help achieve efficient colocation and improved fleet-level utilization at the cluster level and provide better and guaranteed performance for all tenants, resulting in reduced total cost of ownership at the data center level. In addition, the RDT can effectively handle tenants that require spare resource requirements at runtime (which is common in public cloud environments), thereby achieving higher fleet-level utilization. In addition, the device 100 can have the ability to oversubscribe virtual function support on SR-IOV devices (e.g., XPUs, processing units of any architecture) without service denial and with appropriate QoS to manage the SLA commitment via extension.

[0061] The device 100 can provide hybrid IO virtualization for scalable architecture implementations such as SR-IOV devices (e.g., Ethernet, graphics processing units in data center servers, IoT edge computing, and client device environments). The device 100 can enhance SR-IOV device virtualization capabilities to accommodate more guest VMs with a smaller number of IO devices. Environments that support a large number of cores can greatly benefit from the device 100 because the software extensions described herein can be combined with hardware acceleration (virtual functions). The device 100 can be beneficial for server and client workloads that do not have hard latency requirements, such as TSN (Time Stamp Network) Ethernet cards.

[0062] Figure 3 An example of the apparatus 100 implemented in an SR-IOV environment is shown. Figure 3An example of the architecture of the SR-IOV device 300 is shown. The SR-IOV device 300 includes an IO device 310 that provides an interface to a network node. In the first layer 320, the SR-IOV device 300 provides a PHY 321, a layer 2 classifier 322, a physical function 323, and multiple virtual functions 324 derived from the physical function 323. In the virtualization layer 330, for example, in a host operating system or a hypervisor environment, the SR-IOV device 300 provides a physical driver 331 and a software switch 332 coupled to the physical function 323. The software switch 332 provides virtual function extension mapping, RDT virtual function extension, hybrid IO configuration entity, hybrid IO runtime entity, and virtualized IO back-end driver. Through the virtual function IO333, the virtual function 324 can still be used directly by the VM350, but under the control of the virtual machine manager. When the number of occupied virtual functions exceeds the threshold, the SR-IOV device 300 simulates / paravirtualizes the physical function 323 through the software switch 332. VM 350 may, for example, install a virtualized IO front-end driver that helps VM 350 achieve compatibility with back-end drivers provided by the hypervisor.

[0063] The SR-IOV device 300 can provide resource allocation technology for SRIOV virtual functions by extending the limit on the number of virtual functions 324 supported by the physical function 323. This is accomplished by paravirtualization or software emulation of the physical function 323 exposed by the SR-IOV device 300. The virtual function extension mapper can be defined by a scheduling function F, such that VF_EXTENSION_MAPPER=F((R, W), Tx, a, QoS, M)(VF_Extension_Mapper=F((R, W), Tx, a, QoS, M)), where VF_EXTENSION_MAPPER()(VF_Extension_Mapper()) is a function that determines the number and capabilities of simulated and / or paravirtualized access to resources of a network node based on limited available physical functions, QoS represents the expected quality of service (e.g., QoS can have parameterized costs, such as attributes such as performance, transaction settlement costs, etc.), M represents machine learning feedback to be incorporated for the next iteration of scheduling calculations, and W represents a set of applications A that conform to a known trusted list of allowed configurations. For example, the allow list can be published on the public zone processing box chain, where the security operation can be a confirmation check, anti-virus scan, firewall scan, etc., and R represents the risk at risk, such as the value or opportunity cost generated by executing the transaction Tx.

[0064] The hypervisor or VMM or coordinator can determine the SLA priority to be honored for the VM 350 (user or system application) requesting access to resources, and input the priority to the VF factory method. Based on the SLA priority and application tolerance feedback, the SR-IOV device 300 can decide to whom to assign the VF 324 or PF 323, and the SLA interface can be bidirectional for the operating system, VMM and VM 350 (guest), so that SLA and resource access can be negotiated at runtime.

[0065] Emulated or paravirtualized physical functions (extended virtual functions) can be exposed to the RDT manager with a bidirectional interface that tenant / guest OS can use to dynamically negotiate SLAs for efficient node and fleet management. Background applications or non-time-critical applications or workloads running on host or guest VMs can be direct beneficiaries of this VF function extension approach. For example, the RDT manager can use RDT VF extensions, such as function RDT_VF_Ext=func_factory(PF, VF_EXTENSION_MAPPER(R, W, Tx, A, QoS))(RDT_VF_Ext=function_factory(PF, VF_extension_mapper(R, W, Tx, A, QoS))). This function implementation can use an emulation approach through a shared PF interface (called VF extension). It can share the PF interface between VM 350 or applications based on their SLA priorities and requirements using a state machine implementation. Due to the factory method implementation, VF-like interfaces can be created and assigned to applications and VM 350 at runtime.

[0066] The SR-IOV device 300 may provide a software switch 332 including a hybrid (hybridge) IO configuration to set software emulation control using an interface driver of a guest VM 350 and a host operating system. The driver may provide an interface for submitting the workload of the guest VM 350 to the host VM. The software switch 332 may include a hybrid IO runtime entity that is responsible for scheduling the guest VM workload on the host OS or virtual machine manager on a time-sharing basis. Guest virtual machines 350 with medium or low priority may be assigned software emulation 10 interfaces or handles provided by the service OS to execute their workloads. The hybrid software emulation implementation using the SR-IOV device 300 may obtain extensions to other virtual machines beyond the limits of the available virtual functions of the SR-IOV device 300.

[0067] Figure 4An example of an architecture 400 for RDT is shown. The architecture 400 implements a hardware domain 410 underlying a software domain 420. The hardware domain is configured with resource monitoring 411 and resource enforcement 412 of resources of a network node. The resource enforcement 412 is based on QoS considerations and hardware policies.

[0068] The software domain 420 includes an RDT component 421 and a hybrid 10 configuration entry 422. The RDT component 421 exposes resources to applications at the application level 430. The RDT component 421 receives information about resources from the resource monitoring 411 and sends QoS hints to the resource enforcement 412. The orchestrator 440 negotiates resources for an efficient placement strategy with the new VM 450 using the exposed SLA.

[0069] Figure 5 A flow chart of an example of a method 500 is shown. The method 500 includes receiving 510 a request for a virtual machine to access a resource of a network node, determining 520 whether a number of available virtual functions associated with the resource is below a predefined threshold, and if it is determined that the number of available virtual functions is below the predefined threshold, emulating 530 and / or paravirtualizing 530 a physical function associated with the resource. The method 500 also includes providing 540 access to the resource via the emulated and / or paravirtualized physical function for the virtual machine.

[0070] The method 500 may further include: receiving an SLA for the virtual machine, determining at least one of a resource tolerance and a priority of the virtual machine based on the SLA, and

[0071] Based on at least one of resource tolerance and priority, determining whether a virtual function or a physical function associated with the resource is to be provided to the virtual machine. Method 500 may also include emulating and / or paravirtualizing the physical function if it is determined that the physical function is to be provided to the virtual machine.

[0072] In some examples, method 500 may include: receiving an SLA for a virtual machine, determining at least one of a resource tolerance and a priority of the virtual machine based on the SLA, and scheduling the virtual machine's use of a resource based on at least one of the resource tolerance and the priority. Method 500 may also include: providing the virtual machine with access to the resource based on the scheduled use of the resource.

[0073] In other examples, method 500 may include scheduling resource usage by determining at least one of the amount of emulation and / or paravirtualization of physical functions, the corresponding capabilities of the emulation and / or paravirtualization, the expected quality of service of resource usage, and the risk of resource usage, and providing access to the resource to the virtual machine based on the scheduled resource usage.

[0074] In some further examples, method 500 may include receiving multiple requests from multiple virtual machines to access resources, negotiating corresponding SLAs with the multiple virtual machines regarding access to resources, and providing access to resources via simulated and / or para-virtualized physical functions for the multiple virtual machines based on the negotiated SLAs.

[0075] In combination with the proposed technology or one or more of the above examples (e.g., Figure 1a and 1b ) describes more details and aspects of the method 500. The method 500 may include one or more additional optional features corresponding to one or more aspects of the proposed technology or one or more examples described above.

[0076] Figure 6 A flow chart of an example of a method 600 for providing access to resources of an IO device is shown. The method 600 includes requesting 610 by a VM to share an IO device with a VM, i.e., requesting access to a resource. The method 600 includes determining 620 the availability of a virtual function through a hypervisor, for example, determining whether the number of available virtual functions associated with a resource exceeds a predefined threshold. The method 600 also includes receiving 630 a table of physical and virtual functions of the IO device at the hypervisor. The hypervisor, VMM, or host operating system may maintain the resource table. If it is determined that availability is given, the method 600 includes allocating 640 the virtual function to the VM and terminating the process. If there are not enough virtual functions available, the method 600 includes configuring 650 IO sharing, for example, according to the method 700 described below.

[0077] The host OS or hypervisor can obtain input from the hybrid IO configuration component and the RDT manager to configure IO sharing using the back-end driver of the service VM and the front-end driver of the guest VM. Therefore, the method 600 continues to create 660 IO sharing by emulating and / or paravirtualizing the physical functions associated with the resources. In the case of failure to create IO sharing, the method 600 includes canceling 670 the process. In the case of successful creation of IO sharing, the method 600 includes providing 680 access to IO devices, for example, according to the method 800 described below. For example, the hybrid IO runtime can facilitate the scheduling of VM access by the host OS or VMM.

[0078] Figure 7A flow chart of an example of a method 700 for configuration of a network node is shown. The method 700 includes determining 71 whether ORDT support is provided by the network node. If so, then in processing box 720, the new higher priority VM (application or guest) is considered to be scheduled by the coordinator. Verification is performed using a trusted VM list. If the verification is successful, then in processing box 730, the current service class, resource management identifier, and configuration of the network node (SR-IOV device) are exposed to the verified application and guest VM. Based on the guest, application, coordinator guidelines, and available hardware, the RDT profile is negotiated with the VM, for example by calling the RDT_VF_Ext function, as described above. In processing box 740, the newly negotiated configuration is implemented.

[0079] Figure 8 A flow chart of an example of a method 800 for negotiation between VMs requesting access to resources is shown. In processing box 810, a user or guest OS instance or application triggers negotiation by, for example, providing QoS information based on the above-mentioned QoS function. In processing box 820, the user's request is verified, or the user is prompted to provide a valid negotiation request. In processing box 830, the availability of other VMs willing to negotiate is confirmed. If there is no available VM, then in processing box 840, a policy-based action is taken. If there is an available VM, then in processing box 850, the RDT manager provides an interface for negotiation between the requesting VM and another VM. In processing box 860, negotiation is performed based on an extended virtual function (a simulated and / or paravirtualized physical function of a resource). The RDT manager can use RDT_VF_Ext and VF_EXTENSION_MAPPER to implement negotiation on VF availability and resource allocation. In processing box 870, the RDT manager checks whether an existing instance or application can be migrated based on the migration tolerance defined by the instance or application. If so, method 800 continues to processing box 830. If not, then at process block 880, the use of resources is rescheduled by updating the service class of the instance or application. At process block 890, the requested instance is launched (implemented) using the negotiated RDT.

[0080] The methods and apparatus described herein can extend the limit on the number of virtual functions by paravirtualization or software emulation of physical functions, which are supported, for example, by physical functions of SR-IOV devices. The SR-IOV devices can then be shared between virtual machines that are not assigned virtual functions because they are unavailable. The extended virtual functions can be exposed to the RDT manager, which has a bidirectional interface for negotiation that the tenant / guest OS can use to negotiate SLAs. With the help of negotiated SLAs, the coordinator can improve the efficiency of node / fleet management, and reward-based systems for tenants / apps that receive small payments in SLA negotiations, for example.

[0081] In the following, some examples of the proposed technique are presented:

[0082] One example (e.g., Example 1) involves an apparatus comprising an interface circuit, machine-readable instructions, and a processing circuit for executing the machine-readable instructions to: receive a request from a virtual machine to access resources of a network node, determine whether the number of available virtual functions associated with the resources is below a predefined threshold, simulate and / or paravirtualize physical functions associated with the resources if it is determined that the number of available virtual functions is below the predefined threshold, and provide access to the resources via the simulated and / or paravirtualized physical functions for the virtual machine.

[0083] Another example (e.g., Example 2) relates to the previous example (e.g., Example 1) or any other example, and also includes: the machine-readable instructions include instructions for the following operations, namely: receiving a service level agreement SLA for a virtual machine, determining at least one of a resource tolerance and a priority of the virtual machine based on the SLA, determining whether a virtual function or a physical function associated with a resource is provided to the virtual machine based on at least one of the resource tolerance and the priority, and if it is determined that a physical function is provided to the virtual machine, simulating and / or paravirtualizing the physical function.

[0084] Another example (e.g., Example 3) relates to a previous example (e.g., one of Examples 1 or 2) or any other example, and further includes: the machine-readable instructions include instructions for the following operations: receiving a service level agreement SLA for a virtual machine, determining at least one of a resource tolerance and a priority of the virtual machine based on the SLA, scheduling the virtual machine's use of resources based on at least one of the resource tolerance and the priority, and providing the virtual machine with access to resources based on the scheduled use of the resources.

[0085] Another example (e.g., Example 4) relates to a previous example (e.g., one of Examples 2 or 3) or any other example, and further includes: the machine-readable instructions include instructions for the following operations: determining resource tolerance by determining at least one of rate control, grouping priority, bonding options, fault tolerance, and migration tolerance of the virtual machine.

[0086] Another example (e.g., Example 5) relates to a previous example (e.g., one of Examples 1 to 4) or any other example, and further includes: the machine-readable instructions include instructions for the following operations: scheduling the use of resources by determining at least one of the amount of emulation and / or paravirtualization of physical functions, the corresponding capabilities of the emulation and / or paravirtualization, the expected quality of service of the use of the resources, and the risk of the use of the resources, and providing access to the resources to the virtual machine based on the scheduled use of the resources.

[0087] Another example (e.g., Example 6) relates to the previous example (e.g., one of Examples 1 to 5) or any other example, and also includes: the machine-readable instructions include instructions for the following operations: accessing a list of trusted virtual machines stored in the blockchain, determining whether the virtual machine is in the list, and if it is determined that the virtual machine is not in the list, denying its access to the resource.

[0088] Another example (e.g., Example 7) relates to a previous example (e.g., one of Examples 1 to 6) or any other example, and also includes: machine-readable instructions include instructions for the following operations: receiving multiple requests for access to resources from multiple virtual machines, negotiating corresponding service level agreements (SLAs) with the multiple virtual machines regarding access to resources, and providing access to resources via simulated and / or para-virtualized physical functions for the multiple virtual machines based on the negotiated SLAs.

[0089] Another example (e.g., Example 8) relates to a previous example (e.g., one of Examples 1 to 7) or any other example, and also includes: the machine-readable instructions include instructions for the following operations: determining hot plugging or hot unplugging of a resource or another resource, and determining the number of available virtual functions based on the determined hot plugging or hot unplugging.

[0090] Another example (eg, Example 8) relates to the previous example (eg, to a combination of Examples 7 and 8) or any other example, wherein the machine-readable instructions include instructions for negotiating an SLA based on the determined number of available virtual functions.

[0091] Another example (e.g., Example 10) relates to a previous example (e.g., one of Examples 1 to 9) or any other example, and further includes: the machine-readable instructions include instructions for monitoring metrics of simulated and / or paravirtualized physical functions and storing the monitored metrics.

[0092] Another example (e.g., Example 11) relates to a previous example (e.g., one of Examples 1 to 10) or any other example, further including: machine-readable instructions including instructions for determining quality of service of resource usage via simulated and / or para-virtualized physical functions and storing the determined quality of service.

[0093] Another example (e.g., Example 12) relates to the previous example (e.g., one of Examples 1 to 11) or any other example, and also includes: the physical function associated with the resource is a physical function provided by a single root input / output virtualization device.

[0094] Another example (eg, Example 13) relates to the previous example (eg, one of Examples 1 to 12) or any other example, further including: the resource is a bandwidth of a PCIe bus.

[0095] Another example (e.g., Example 14) relates to a previous example (e.g., one of Examples 1 to 13) or any other example, and further includes: the machine-readable instructions include instructions for sending a driver to the virtual machine for using emulated and / or paravirtualized physical functions in response to receiving a request from the virtual machine.

[0096] One example (e.g., Example 15) relates to a method comprising: receiving a request from a virtual machine to access resources of a network node, determining whether the number of available virtual functions associated with the resource is below a predefined threshold, simulating and / or paravirtualizing physical functions associated with the resource if it is determined that the number of available virtual functions is below the predefined threshold, and providing access to the resource via the emulated and / or paravirtualized physical functions for the virtual machine.

[0097] Another example (e.g., Example 16) relates to the previous example (e.g., Example 15) or any other example, and also includes: receiving a service level agreement (SLA) for a virtual machine, determining at least one of a resource tolerance and a priority of the virtual machine based on the SLA, determining whether a virtual function or a physical function associated with the resource is provided to the virtual machine based on at least one of the resource tolerance and the priority, and if it is determined that the physical function is provided to the virtual machine, simulating and / or virtualizing the physical function.

[0098] Another example (e.g., Example 17) relates to a previous example (e.g., one of Examples 15 or 16) or any other example, and also includes: receiving a service level agreement (SLA) for a virtual machine, determining at least one of a resource tolerance and a priority of the virtual machine based on the SLA, scheduling the virtual machine's use of resources based on at least one of the resource tolerance and the priority, and providing the virtual machine with access to resources based on the scheduled use of the resources.

[0099] Another example (e.g., Example 18) relates to a previous example (e.g., one of Examples 15 to 17) or any other example, and also includes: scheduling the use of resources by determining at least one of the amount of emulation and / or paravirtualization of physical functions, the corresponding capabilities of the emulation and / or paravirtualization, the expected quality of service of the use of resources, and the risk of the use of resources, and providing access to resources to the virtual machine based on the scheduled use of the resources.

[0100] Another example (e.g., Example 19) relates to a previous example (e.g., one of Examples 15 to 18) or any other example, and also includes: receiving multiple requests from multiple virtual machines to access resources, negotiating corresponding service level agreements (SLAs) with the multiple virtual machines regarding access to resources, and providing access to resources via simulated and / or para-virtualized physical functions of the multiple virtual machines based on the negotiated SLAs.

[0101] Another example (e.g., Example 20) involves a non-transitory machine-readable storage medium that includes program code that, when executed, causes a machine to perform the method of any one of the foregoing examples (e.g., Examples 15 to 19) or any other example.

[0102] The aspects and features described in relation to a particular example among the foregoing examples may be combined with one or more of the other examples to replace the same or similar features of the other examples or to additionally introduce these features into the other examples.

[0103] Examples may further be or relate to (computer) programs, including program codes for executing one or more of the above methods when the program is executed on a computer, a processor, or other programmable hardware component. Thus, the steps, operations, or processes of the different methods in the methods described above may also be performed by a programmed computer, a processor, or other programmable hardware component. Examples may also encompass program storage devices, such as digital data storage media, which are machine-readable, processor-readable, or computer-readable and encode and / or contain machine-executable, processor-executable, or computer-executable programs and instructions. For example, a program storage device may include or may be a digital storage device, a magnetic storage medium (such as a disk and a tape), a hard drive, or an optically readable digital data storage medium. Other examples may also include a computer, a processor, a control unit, a (field) programmable logic array ((field) programmable logic array, (F) PLA), a (field) programmable gate array ((field) programmable gate array, (F) PGA), a graphics processor unit (GPU), an application-specific integrated circuit (ASIC), an integrated circuit (IC), or a system-on-a-chip (SoC) system programmed to perform the steps of the method described above.

[0104] It will also be understood that the disclosure of several steps, processes, operations or functions disclosed in the specification or claims should not be interpreted as implying that these operations must be performed in the described order, unless explicitly stated in a separate use case or necessary for technical reasons. Therefore, the previous description does not limit the performance of several steps or functions to a certain order. In addition, in other examples, a single step, function, process or operation may include and / or be decomposed into sub-steps, sub-functions, sub-processes or sub-operations.

[0105] If some aspects have been described in conjunction with a device or system, these aspects should also be understood as descriptions of corresponding methods. For example, a block, a device, or a functional aspect of a device or system may correspond to a feature (such as a method step) of a corresponding method. Accordingly, aspects described in conjunction with a method should also be understood as descriptions of properties or functional features of the corresponding block, corresponding element, corresponding device, or corresponding system.

[0106] As used herein, the term "module" refers to a logic for performing one or more operations in accordance with the present disclosure that can be implemented using hardware components or devices, software or firmware running on a processing unit, or a combination thereof. Software and firmware can be embodied as instructions and / or data stored on a non-transient computer-readable storage medium. As used herein, the term "circuitry" can include, individually or in any combination, non-programmable (hard-wired) circuitry, programmable circuitry (such as a processing unit), state machine circuitry, and / or firmware that stores instructions that can be executed by a programmable circuitry. The modules described herein can be embodied collectively or individually as circuits that form part of a computing system. Thus, any one of the modules can be implemented as a circuit system. A computing system that is referred to as being programmed to perform a method can be programmed to perform the method via software, hardware, firmware, or a combination thereof.

[0107] Any disclosed method (or part thereof) can be implemented as computer-executable instructions or computer program products. Such instructions can enable a computing system or one or more processing units capable of executing computer-executable instructions to perform any of the disclosed methods. As used herein, the term "computer" refers to any computing system or device described or mentioned herein. Thus, the term "computer-executable instructions" refers to instructions that can be executed by any computing system or device described or mentioned herein.

[0108] Computer executable instructions may be, for example, part of an operating system of a computing system, an application stored locally on the computing system, or a remote application accessible to the computing system (e.g., via a web browser). Any of the methods described herein may be performed by computer executable instructions, which are executed by a single computing system or by one or more networked computing systems operating in a network environment. Computer executable instructions and updates to computer executable instructions may be downloaded from a remote server to a computing system.

[0109] In addition, it should be understood that implementation of the disclosed techniques is not limited to any particular computer language or program. For example, the disclosed techniques can be implemented by software written in C++, C#, Java, Perl, Python, JavaScript, Adobe Flash, C#, assembly language, or any other programming language. Likewise, the disclosed techniques are not limited to any particular computer system or any particular type of hardware.

[0110] In addition, any software-based examples (including, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed via suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, cables (including fiber optic cables), magnetic communications, electromagnetic communications (including RF, microwave, ultrasonic, and infrared communications), electronic communications, or other such communication means.

[0111] The disclosed methods, devices, and systems should not be interpreted as limiting in any way. Instead, the present disclosure is directed to all novel and non-obvious features and aspects of each disclosed example, individually and in various combinations and sub-combinations with each other. The disclosed methods, devices, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed examples require the existence of any one or more specific advantages or the resolution of any one or more specific problems.

[0112] The theories of operation, scientific principles, or other theoretical descriptions presented herein with reference to the devices or methods of the present disclosure are provided for the purpose of better understanding and are not intended to limit the scope. The devices and methods in the appended claims are not limited to those devices and methods that function in the manner described by such theories of operation.

[0113] The attached claims are hereby included in the detailed description, wherein each claim itself can serve as a separate example. It should be noted that although a dependent claim refers to a specific combination with one or more other claims in the claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are expressly proposed here, unless it is stated in individual cases that a specific combination is not intended. In addition, even if a claim is not directly limited to refer to any other independent claim, the features of the claim should also be included for any other independent claim.

Claims

1. An apparatus comprising an interface circuit, a machine-readable instruction, and a processing circuit, wherein the processing circuit is configured to execute the machine-readable instruction to: receiving a request from a virtual machine to access resources of a network node; determining whether a number of available virtual functions associated with the resource is below a predefined threshold; If it is determined that the number of available virtual functions is below the predefined threshold, emulating and / or paravirtualizing physical functions associated with the resource; and Access to the resources is provided via the emulated and / or para-virtualized physical functions for the virtual machine.

2. The device according to claim 1, wherein: The machine-readable instructions include instructions for: Receiving a service level agreement SLA for the virtual machine; determining at least one of a resource tolerance and a priority of the virtual machine based on the SLA; determining whether a virtual function or the physical function associated with the resource is provided to the virtual machine based on at least one of the resource tolerance and the priority; as well as If it is determined to provide the physical function to the virtual machine, the physical function is simulated and / or paravirtualized.

3. The device according to claim 1 or 2, wherein: The machine-readable instructions include instructions for: Receiving a service level agreement SLA for the virtual machine; determining at least one of a resource tolerance and a priority of the virtual machine based on the SLA; scheduling use of the resource by the virtual machine based on at least one of the resource tolerance and the priority; as well as The virtual machine is provided access to the resource based on the scheduled usage of the resource.

4. The device as claimed in claim 3, wherein: The machine-readable instructions include instructions for determining the resource tolerance by determining at least one of rate control, packet priority, bonding options, fault tolerance, and migration tolerance for the virtual machine.

5. The device according to claim 1, wherein: The machine-readable instructions include instructions for: scheduling the use of the resource by determining at least one of an amount of emulation and / or paravirtualization of the physical function, a corresponding capacity of the emulation and / or paravirtualization, an expected quality of service of the use of the resource, and a risk of the use of the resource; as well as The virtual machine is provided access to the resource based on the scheduled usage of the resource.

6. The device according to claim 1, wherein: The machine-readable instructions include instructions for: Access the list of trusted virtual machines stored in the blockchain; Determine whether the virtual machine is in the list; as well as If it is determined that the virtual machine is not in the list, then the virtual machine is denied access to the resource.

7. The device of claim 1, wherein: The machine-readable instructions include instructions for: receiving multiple requests from multiple virtual machines to access resources; Negotiating a corresponding service level agreement (SLA) with the plurality of virtual machines regarding access to the resource; and Access to the resources is provided via the emulated and / or para-virtualized physical functions for the plurality of virtual machines based on a negotiated SLA.

8. The device of claim 1, wherein: The machine-readable instructions include instructions for: Determining hot plugging or hot unplugging of the resource or another resource; and A number of available virtual functions is determined based on the determined hot plug or hot unplug.

9. The device of claim 8, wherein: The machine-readable instructions include instructions for negotiating an SLA based on the determined number of available virtual functions.

10. The device of claim 1, wherein: The machine-readable instructions include instructions for monitoring metrics of the emulated and / or para-virtualized physical functions and storing the monitored metrics.

11. The device of claim 1, wherein: The machine-readable instructions include instructions for determining a quality of service for usage of the resource via the emulated and / or para-virtualized physical functions and for storing the determined quality of service.

12. The device of claim 1, wherein: The physical function associated with the resource is a physical function provided by a single root input / output virtualization device.

13. The device of claim 1, wherein: The resource is the bandwidth of the PCIe bus.

14. The device of claim 1, wherein: The machine-readable instructions include instructions for, in response to receiving a request from the virtual machine, sending to the virtual machine a driver for use of the emulated and / or para-virtualized physical functions.

15. A method comprising: receiving a request from a virtual machine to access resources of a network node; determining whether a number of available virtual functions associated with the resource is below a predefined threshold; If it is determined that the number of available virtual functions is below the predefined threshold, emulating and / or paravirtualizing physical functions associated with the resource; and Access to the resources is provided via emulated and / or para-virtualized physical functions for the virtual machine.

16. The method of claim 15, further comprising: Receiving a service level agreement SLA for the virtual machine; determining at least one of a resource tolerance and a priority of the virtual machine based on the SLA; determining whether a virtual function or the physical function associated with the resource is provided to the virtual machine based on at least one of the resource tolerance and the priority; as well as If it is determined to provide the physical function to the virtual machine, the physical function is simulated and / or paravirtualized.

17. The method of any one of claims 15 or 16, further comprising: Receiving a service level agreement SLA for the virtual machine; determining at least one of a resource tolerance and a priority of the virtual machine based on the SLA; scheduling use of the resource by the virtual machine based on at least one of the resource tolerance and the priority; as well as The virtual machine is provided access to the resource based on the scheduled usage of the resource.

18. The method of claim 15, further comprising: scheduling the use of the resource by determining at least one of an amount of emulation and / or paravirtualization of the physical function, a corresponding capacity of the emulation and / or paravirtualization, an expected quality of service of the use of the resource, and a risk of the use of the resource; as well as The virtual machine is provided access to the resource based on the scheduled usage of the resource.

19. The method of claim 15, further comprising: receiving a plurality of requests from a plurality of virtual machines to access the resource; Negotiate a corresponding service level agreement (SLA) with the plurality of virtual machines regarding access to the resources; as well as Access to the resources is provided via the emulated and / or para-virtualized physical functions for the plurality of virtual machines based on a negotiated SLA.

20. The method of claim 15, further comprising: Determining hot plugging or hot unplugging of the resource or another resource; as well as A number of available virtual functions is determined based on the determined hot plug or hot unplug.

21. The method of claim 20, further comprising: An SLA is negotiated based on the determined number of available virtual functions.

22. The method of claim 15, further comprising: Metrics of the emulated and / or para-virtualized physical functions are monitored and the monitored metrics are stored.

23. The method of claim 15, further comprising: A quality of service for usage of the resource is determined via the emulated and / or para-virtualized physical functions and the determined quality of service is stored.

24. A non-transitory machine-readable storage medium comprising a program code, which, when executed, causes a machine to perform the method of claim 15.

25. A computer system comprising a processor, a memory coupled to the processor for storing instructions, the instructions, when executed by the processor, for performing the method of claim 15.

Images