Hewlett Packard Enterprise Development LP

Vinnarasu Ganesan

Siva Subramaniam Manickam

Thavamaniraja Sakthivel

Balaji Ramamoorthi

Brahmanand Vuppuluri

Rajesh Teeparti

Siva Subramaniam M

Saravana Prabu

Thavamaniraja S

Sriram Padmachetty Harinath

SaiKrishna Reddy Vasipalli

Examples relate to preventing scheduling or executing a resource on an inconsistent host node in a networked system. Some examples track a taint status of the host node and identify whether the host node is inconsistent based on the taint status of the host node over a predefined period of time. Upon identifying that the host node is inconsistent, a master taint is applied on the inconsistent host node, which prevents scheduling or executing a resource on the identified inconsistent host node.

Preventing scheduling or executing a resource on an inconsistent host node

Examples described herein relate to a method and a system, for example, a workload controller, for accessing purged workloads. An alert indicative of an attempt to access a purged workload of workloads deployed in a workload environment may be received by the workload controller. The purged workload may include one or both of a deactivated workload or an archived workload. The workload controller may detect the attempt to access the purged workload based on port mirrored data traffic. Further, in some examples, the workload controller may activate the purged workload based on the alert.

Accessing purged workloads

In some examples, a system associates, with a plurality of virtual resources deployed in a cloud environment, properties representative of characteristics of the virtual resources, the properties comprising a performance level of a virtual resource. The system receives a request to create a virtual resource in the cloud environment, and, in response to determining that properties of the virtual resource to be created for the request satisfy a criterion with respect to properties of a given virtual resource of the plurality of virtual resources, selects the given virtual resource as a candidate virtual resource for the request.

Virtual resource selection for a virtual resource creation request

Examples described relate to determining a future operation failure in a cloud system. In an example, a historical utilization of resources for performing an operation in a cloud system may be determined. A current utilization of resources in the cloud system may be determined. Based on the historical utilization of resources for performing the operation in the cloud system and the current utilization of resources in the cloud system, a determination may be made whether a future performance of the operation in the cloud system is likely to be a failure. In response to a determination that the future performance of the operation in the cloud system is likely to be a failure, an alert may be generated.

Determining a future operation failure in a cloud system

Virtual machine images available across a plurality of cloud networks may be identified. A catalog of the virtual machine images may be generated. The catalog may comprise, for each virtual machine image, a mapping information, comprising: a name of a virtual machine image, a name of a virtual machine instance based on the virtual machine image, a name of a cloud network providing the virtual machine image, a cost of deploying the virtual machine instance on the cloud network, a tag identifying a feature of the virtual machine image, and an identification tag assigned to the virtual machine image. For a given virtual machine instance, the catalog of the virtual machine images may be analyzed to identify a least cost cloud network.

Identifying a least cost cloud network for deploying a virtual machine instance

Example implementations relate to testing a cloud service. An example implementation includes creating cloud service resources. The resources may include a system node and a cloud application programming interface (API) for accessing the system node. Workloads of different types may be generated on the deployed cloud service according to workload parameters. In an example, the different workload types may include data workloads on the system nodes to consume computational resources of a computational resource pool assignable by the cloud service. In an example, the different workload types may include application programming interface calls to interface with cloud APIs of the cloud service.

Generating different workload types for cloud service testing

In one example, mapping information corresponding to a container running on a private data center may be generated in a public cloud by a processor-based disaster recovery manager. Further, volume data associated with the container may be synchronized to the public cloud based on the mapping information by the disaster recovery manager. Furthermore, a failure of the container running on the private data center may be determined by the disaster recovery manager. In response to the failure of the container running on the private data center, the container may be deployed in the public cloud using the synchronized volume data and the mapping information by the disaster recovery manager.

Growing community of inventors

Bengaluru, India

Vinnarasu Ganesan