To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

An automotive gateway includes one or more interfaces and one or more processors. The one or more interfaces are configured to communicate with electronic subsystems of a vehicle. The one or more processors and configured to host one or more guest applications and to control communication traffic between the one or more guest applications and the electronic subsystems of the vehicle in accordance with a security policy.

A method and system for automating application of software patches to a server system having a virtualization layer. A plurality of software patches are downloaded to a computer system having a first operating system. The software patches to apply to a server console operating system are then determined. The software patches are automatically copied to the server system by executing a first script file. The copied software patches are automatically decompressed by executing a second script file. The decompressed software patches are installed in a specified order by executing the second script file. The console operating system is rebooted only after all software patches are installed.

Systems and methods providing robust resource removal for virtual machines. In one implementation, a hypervisor may receive configuration data associated with a virtual machine (VM). The hypervisor may determine, based on the configuration data, a type of support by the VM of recovery from unexpected hardware resource removal. The hypervisor may identify, based on the type of support of recovery form unexpected hardware resource removal, a type of access of the VM to one or more hardware resources. The hypervisor may launch the VM according to the type of access to the one or more hardware resources.

Techniques are described for filtering and normalizing training data used to build a predictive auto scaling model used by a service provider network to proactively scale users' computing resources. Further described are techniques for identifying collections of computing resources that exhibit suitably predictable usage patterns such that a predictive auto scaling model can be used to forecast future usage patterns with reasonable accuracy and to scale the resources based on such generated forecasts. The filtering of training data and the identification of suitably predictable collections of computing resources are based in part on autocorrelation analyses, and in particular on “delayed” autocorrelation analyses, of time series data, among other techniques described herein.

Provided are techniques for encrypting a virtual disk of a virtual computing instance (VCI) while the VCI is online and still running using a mirror driver. In certain aspects a mirror driver is a filter running in an I/O stack used for accessing a virtual disk, such that the mirror driver receives I/Os destined to the virtual disk and mirrors those I/Os to the virtual disk and one or more additional virtual disks. The mirror driver begins copying data from an unencrypted source virtual disk to a destination virtual disk, and the data is encrypted as it is stored in the destination virtual disk, while the VCI is still online. During the copying, as new writes are issued to the unencrypted source virtual disk from the VCI, the mirror driver mirrors the writes to both the unencrypted source virtual disk and the destination virtual disk.

Example implementations relate to virtual persistent volumes. In an example, a manifest of a containerized application to which a virtual persistent volume is allocated is read from a container orchestrator. An application data store profile that matches information of the manifest is identified from among a plurality of application data store profiles that each include storage parameters preconfigured for a respective application type. The virtual persistent volume is modified according to the identified application data store profile.

Calls run through a virtual desktop infrastructure server are enhanced by opening a media channel between a personal computing device and a media server for a call initiated using a virtual desktop infrastructure server. A first stream of media data for the call is merged with a second stream of media data for the call in a single virtual channel of the protocol using a first packet queue to store packets of the first stream and a second packet queue to store packets of the second stream as the packets await transmission. A first packet of media data of the first stream is pushed into the first packet queue. A fill level of the first packet queue is compared to a first congest threshold associated with the first packet queue. Responsive to the fill level exceeding the first congest threshold, a congestion mitigation measure is invoked.

This disclosure is directed to embodiments of systems and methods for containerizing files and managing policy data applied to the resulting containers. In some of the disclosed embodiments, a computing system determines that a file stored in storage medium is to be included in a container to be sent to at least one computing component associated with a device including a user interface. The computing system determines that the file is of a particular type and also determines code that can be used to access files of the particular type. The computing system combines the file and the code into the container such that container is configured to be executed by the at least one computing component so as to cause content of the file to be presented by the user interface. The computing system then sends the container to the at least one computing component. In some implementations, the container may further include policy information defining at least one of whether, how, where, when, or by whom the file can be accessed using the code. A communication link may be established between the computing system and the container at the at least one computing component and an instruction may be sent via the communication link that causes a change to the policy information.

A system comprising a hosting service configured to perform: providing, to a trusted entity on a central processing unit, a command for a launch of a virtual machine (VM); assigning, to the VM, at least a portion of memory for the guest operating system; submitting, to the trusted entity, a request to measure an address space of the VM to provide a measurement digest of the address space of the guest operating system; including, in a configuration object, a policy provided by the user for the service logic, wherein the policy defines one or more rules for the service logic, wherein the one or more rules include at least one rule for which containers may run in the guest operating system; hashing the policy to provide a hash digest of the policy; submitting, to the trusted entity, the hash digest of the policy; and completing the launch of the VM.