Abstract: A system and method for imaging a self-bootstrapping computing node includes booting, from a boot device, the computing node into a bootstrapping environment using a bootstrap operating system, where the bootstrap operating system is configured with an address of an imaging location, accessing the imaging location and receiving a software image for the computing node, and, imaging the computing node using the software image including installing another operating system on the computing node to boot from the boot device. Monitoring a status of the computing node's imaging operations using an application programming interface (API), monitoring a health status of the computing node, and enabling restart of the boot process upon failure (e.g., self-healing, self-recovery, etc.), is also described.

Abstract: Methods, systems and computer program products for lockless acquisition of memory for RDMA operations. A contiguous physical memory region is allocated. The contiguous physical memory region is divided into a plurality of preregistered chunks that are assigned to one or more process threads that are associated with an RDMA NIC. When responding to a request from a particular one of the one or more process threads, a buffer carved from the preregistered chunk of the contiguous physical memory region is assigned to the requesting process thread. Since the memory is pre-registered, and since the associations are made at the thread level, there is no need for locks when acquiring a buffer. Furthermore, since the memory is pre-registered, the threads do not incur registration latency. The contiguous physical memory region can be a contiguous HugePage contiguous region from which a plurality of individually allocatable buffers can be assigned to different threads.

Abstract: A platform-as-a-service (PaaS) manager abstracts deployment of PaaS software stacks to different computing platforms such that the PaaS software stacks provide a common platform to host an application despite differences in the underlying architectures of the computing platforms. Each PaaS software stack is hosted on a service domain installed on a respective one of the computing platforms, and includes an operating system and provides access to a set of services for execution of applications. The some examples, the different computing platforms include multiple different cloud architectures.

Abstract: A computing system is provided that enables efficient layer-2 traffic forwarding. During operation, the computing system can determine that a packet is from a first virtual machine (VM) running on the computing system and destined to a second VM running on a second computing system. The computing system can determine a first transit Internet Protocol (IP) address of a first VM and a second transit IP address of the second VM. The computing system can then modify the packet to replace existing media access control (MAC) addresses in the layer-2 header with MAC addresses of the computing system and the second computing system. The computing system can also modify the packet to replace the source and destination IP addresses in the layer-3 header with the first and second transit IP addresses, respectively. Subsequently, the computing system can determine an egress port based on the modified layer-2 header.

Abstract: Methods, systems, and computer program products for multi-cloud shared data management. A first storage facility on a first cloud is established and a second storage facility on a second cloud established. The first cloud and the second cloud comprise at least respective first deduplication metadata and second deduplication metadata. In response to receipt of a request to store a content object comprising at least one candidate deduplication chunk, an inter-cloud deduplication protocol is initiated. The inter-cloud deduplication protocol determines whether or not a candidate deduplication chunk of a data item is already stored at either the first cloud or the second cloud. In the event that the candidate deduplication chunk of the data item deemed to have been already stored then, rather than storing a further copy of the bit sequence corresponding to the candidate deduplication chunk, instead, merely referring to the location of the already stored candidate deduplication chunk.

Abstract: An aspect of the present disclosure facilitates performance of node management actions in a computing infrastructure having diverse node interfaces. In one embodiment, a configuration data is maintained, the configuration data specifying plugins designed to communicate with different node interfaces installed on the nodes of a computing infrastructure. The plugins are corresponding implementations of a common client interface. Upon receiving from the client application, via the common client interface, a management action to be performed on a desired node, the configuration data is inspected to identify a specific plugin corresponding to the node interface installed on the desired node. The node management action is then performed on the desired node using the identified specific plugin. Accordingly, the client application can be implemented agnostic to the specific node interfaces installed on a node.

Abstract: Upon receiving a request to hibernate a hypervisor of a virtualization system running on a first computer, acts are carried out to capture a state of the hypervisor, where the state of the hypervisor comprises hypervisor logical resource parameters and an execution state of the hypervisor. After hibernating the hypervisor by quiescing the hypervisor and storing the state of the hypervisor into a data structure, the data structure is moved to a different location. At a later moment in time, the data structure is loaded onto a second computing machine and restored. The restore operation restores the hypervisor and all of its state, including all of the virtual machines of the hypervisor as well as all of the virtual disks and other virtual devices of the virtual machines. Differences between the first computing machine and the second computing machine are reconciled before execution of the hypervisor on the second machine.

Abstract: Disclosed is an improved approach to implement I/O and storage device management in a virtualization environment. According to some approaches, a Service VM is employed to control and manage any type of storage device, including directly attached storage in addition to networked and cloud storage. The Service VM implements the Storage Controller logic in the user space, and can be migrated as needed from one node to another. IP-based requests are used to send I/O request to the Service VMs. The Service VM can directly implement storage and I/O optimizations within the direct data access path, without the need for add-on products.

Abstract: Methods, systems and computer program products for deploying a virtualization system onto cloud computing infrastructure. Virtual machines of a virtualization system are deployed onto computing nodes that are interconnected via a cloud provider's networking infrastructure. When migrating a virtual machine from a source computing node to a target computing node that is also interconnected to the cloud provider's networking infrastructure, the addressing of the to-be-migrated virtual machine changes. Dynamically-updated media access control translation tables are maintained at the computing nodes. The media access control translation tables are populated with cloud provider media access control addresses received from the cloud provider. A virtual switch at each computing node modifies incoming and outgoing packets of a to-be-migrated virtual machine based on contents of that node's media access control translation table.

Abstract: An illustrative embodiment disclosed herein is an apparatus including a processor and a memory. In some embodiments, the memory includes programmed instructions that, when executed by the processor, cause the apparatus to apply a category to a first virtual machine (VM) and a second VM, schedule the first VM and the second VM to be placed on a host at least based on the first VM and the second VM including the category, and apply a security policy to the first VM and the second VM at least based on the first VM and the second VM including the category.

Abstract: A high frequency snapshot technique improves data replication in a disaster recovery (DR) environment. A base snapshot is generated from failover data at a primary site and replicated to a placeholder file at a secondary site. Upon commencement of the base snapshot generation and replication, incremental light weight snapshots (LWSs) of the failover data are captured and replicated to the secondary site. A staging file at the secondary site accumulates the replicated LWSs (“high-frequency snapshots”). The staging file is populated with the LWSs in parallel with the replication of the base snapshot at the placeholder file. At a subsequent predetermined time interval, the accumulated LWSs are synthesized to capture a “checkpoint” snapshot by applying and pruning the accumulated LWSs at the staging file. Once the base snapshot is fully replicated, the pruned LWSs are merged to the base snapshot to synchronize the replicated failover data.

Abstract: In some aspects, an apparatus includes a processor and a memory. In some embodiments, the memory includes programmed instructions that, when executed by the processor, cause the apparatus to intercept an I/O transaction between a virtual machine and an I/O device, determine whether data in the I/O transaction indicates a security misconfiguration, and perform a remedial action in response to identifying the security misconfiguration.

Abstract: A technique enables coordination of unrelated software components to facilitate extensive recovery point management on a snapshot or recovery point through the use of a flexible tag structure. The tag is organized and arranged as a {key=value,[value] . . . } structure wherein the key denotes an operation that requires coordination between the unrelated software components and the value(s) denote multi-cardinality that provide parameters for coordination of the operation. The multi-cardinality aspect of the flexible tag structure provides a set of values associated with the key of the tag that enables a software component and/or protocol to insert its value(s) into the tag structure for its interpretation. The technique thus provides an extensible model where multiple components/protocols use the tag to coordinate operations on the RP by conveying certain meaning/interpretations of the tag and its values.

Abstract: Methods, systems, and computer program products for high-availability computing systems. A computer processor executes a sequence of instructions to execute, on a first node of a computing platform, a first instance of a computing process that is configured to use a first graphics processing unit (GPU) in a first GPU configuration. Responsive to detection of a loss of functionality that affects the first node, a second instance of the computing process is configured to be executed on the second node. The determination of aspects of the second node is made by (1) consulting a machine learned model to retrieve recommended known configuration states, then (2) mapping the recommended known configuration states onto one or more alternate second GPU configurations, and (3) configuring the second instance of the computing process to use the second GPU in one of the recommended known configuration states.

Abstract: Methods, systems, and computer program products for high availability computing systems. A computer processor executes a sequence of instructions to execute, on a first node of a computing platform, a first instance of a computing process that is configured to use a first graphics processing unit (GPU) in a first GPU configuration. Responsive to detection of a loss of functionality that affects the first node, an agent automatically determines that a second instance of the computing process can execute on a second node. The determination is made by (1) determining that the second instance of the computing process can execute using a second GPU in a second GPU configuration on the second node, (2) mapping the first GPU configuration into one or more alternate second GPU configurations, and (3) configuring the second instance of the computing process to use the second GPU in one of the alternate second GPU configurations.

Abstract: A recovery orchestration pipeline has stages configured to control efficient failover and recovery of applications in a multi-site disaster recovery (DR) environment. The applications run on user virtual machines (UVMs) at a primary site of the DR environment and connect to block storage devices (BSDs) that export virtual disks over a storage protocol to consume data including a recovery plan for disaster recovery. The recovery plan includes a recovery configuration whose generation is triggered by a user via a graphical user interface (GUI) and specifies resource requirements needed to recover the applications at a secondary site in the event of a disaster. The orchestration pipeline is initiated via single click of the GUI and completion of the stages of the pipeline is displayed as progress via the GUI to allow recovery of the applications without user intervention.

Abstract: Methods, systems, and computer program products for computer networking. Legacy policy-based routing is advanced by adding fallback-aware policy actions that are enabled within a policy-based routing regime. Upon determining that a destination specified in a subject policy is compromised, or down, or unreachable then, a fallback-aware policy action is invoked. Destinations specified in policies may refer to inserted services, wherein an inserted service can be any one of, a service process, a service virtual machine, a hardware network component, or a virtual network interface. Such inserted services might implement a logging service, or a firewall service, or other services that can process a network packet. Fallback-aware policy actions include, a PASSTHROUGH fallback action, an ALLOW fallback action, a FORWARD fallback action, and a DROP fallback action. Various techniques serve to determine whether or not a particular destination of a subject policy is deemed to be compromised, or down or unreachable.

Abstract: Methods, systems and computer program products for configuring microservices platforms in one or more computing clusters. In one of the computing clusters, a request to instantiate a microservice platform is received, wherein the request is received in a computing cluster having a first node and a second node, and wherein the first node and second node comprise a first virtualized storage controller and a second virtualized storage controller, respectively. The storage controllers each manage their respective storage pools comprising local storage devices. A first microservice manager is deployed on the first node and a second microservice manager is deployed on the second node.

Abstract: Examples described herein are generally directed towards file server access controls, and more specifically towards a mechanism to create consistent access control lists for local users across different file servers in a distributed file server environment. In operation, a local user system SID (e.g., external SID) may be generated for a first user of a first file server. A global ID based on attributes associated with the user of the first file server may also be generated. The global ID for the user may be stored in metadata associated with an access control list (ACL) for a file accessible through the first file server. Data, including the file may be migrated to a second file server. Based on receiving an access request at the second file server associated with the user based on the external ID, the external ID for the user may be translated into the global ID, and used to determine access to the file.

Abstract: Bootstrapping a microservices container registry. A computing system node receives an installation package. The receiving computing system node bootstraps an initial invocation of the microservice by first installing a local container registry from the installation package and then by installing the microservice from the installation package. The installation package contains additional components that can be extracted, installed and invoked by executing the microservice at the computing system node after extracting from the local container registry. The installation package is generated by any node of the computing system and contains code corresponding to infrastructure microservices that are installed before invoking microservices that depend on the infrastructure. Temporary domain name services are installed from the installation package at a node-local IP address. The temporary domain name services are switched over to a different domain name service at a different IP address.