• Stars
    star
    158
  • Rank 237,131 (Top 5 %)
  • Language
    C
  • License
    Other
  • Created over 8 years ago
  • Updated over 5 years ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Quartz: A DRAM-based performance emulator for NVM

Quartz: A DRAM-based performance emulator for NVM

Quartz leverages features available in commodity hardware to emulate different latency and bandwidth characteristics of future byte-addressable NVM technologies.

Quartz's design, implementation details, evaluation, and overhead can be found in the following research paper:

  • H. Volos, G. Magalhaes, L. Cherkasova, J. Li: Quartz: A Lightweight Performance Emulator for Persistent Memory Software. In Proc. of the 16th ACM/IFIP/USENIX International Middleware Conference, (Middleware'2015), Vancouver, Canada, December 8-11, 2015. and can be downloaded from: http://www.jahrhundert.net/papers/middleware2015.pdf

While the emulator is designed to cover three processor families: Sandy Bridge, Ivy Bridge, and Haswell -- we have had the best results on the Ivy Bridge platform. Haswell processor has a TurboBoost feature that cause higher variance and deviations when emulating higher range latencies (above 600 ns).

Contributors

For a list of contributors see AUTHORS.

Extended documentation

Extended documentation available in Doxygen form. To build and view:

doxygen
xdg-open doc/html/index.html

Dependencies

This is the list of libraries and tools used by Quartz:

On RPM based distributions:

  • cmake 2.8
  • libconfig and libconfig-devel
  • numactl-devel
  • uthash-devel
  • kernel-devel

On Debian based distributions:

  • cmake 2.8
  • libconfig-dev
  • libnuma-dev
  • uthash-dev
  • linux-headers

You can run 'sudo scripts/install.sh' in order to automatically install these dependencies.

Supported environment

Currently the latency emulator can be used on Linux with Sandy Bridge, Ivy Bridge, and Haswell Intel processors. For bandwidth emulation support, Intel Thermal Memory Controller device is required. No specific Linux distribution or kernel version is required.

Source code tree overview

bench             Benchmarks
doc               Documentation, including Doxygen generated documentation (doc/html)
src/lib           Emulator main library code
src/dev           Kernel-module for accessing performance counters and 
                  memory-controller PCI registers
scripts           Helper scripts to run a program using the emulator and install 
                  dependencies
test              Several tests and application code examples
benchmark-tests   Several automated tests with benchmark runs and output analysis 
                  for testing the correctness of configured emulation environment and 
                  the accuracy of expected results

For more details, please see the extended documentation generated using Doxygen.

Building

After installing the dependencies, go to the emulator's source code root folder and execute the following steps:

mkdir build
cd build
cmake ..
make clean all

In order to disable statistics support, replace the third step above with:

cmake .. -DSTATISTICS=OFF

See more details about statistics on the respective section below. The emulator library, benchmark and test binaries resulted from the build process will be available in the respective subfolder inside the 'build' folder.

Usage

First, load the emulator's kernel module. From the emulator's source code root folder, execute:

sudo scripts/setupdev.sh load

Set your processor to run at maximum frequency to ensure fixed cycle rate (as the cycle counter is used to project delay time). You can use the scaling governor:

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Set the LD_PRELOAD and NVMEMUL_INI environment variables to point respectively to the emulators library and the configuration file to be used. The LD_PRELOAD is used for automatically loading the emulator's library when the user application is executed. Thus, there is no need to statically link the library to the user application. See below details about the configuration file in the respective section.

Rather than configuring the scaling governor and the environment variables manually as indicated above, you can use the scripts/runenv.sh script. See below.

An additional configuration step may be required depending on the Linux Kernel version. This emulator makes use of rdpmc x86 instruction to read CPU counters. Before kernel 4.0, when rdpmc support was enabled, any process (not just ones with an active perf event) could use the rdpmc instruction to access the counters. Starting with Linux 4.0 rdpmc support is only allowed if an event is currently enabled in a process's context. To restore the old behavior, write the value 2 to /sys/devices/cpu/rdpmc if kernel version is 4.0 or greater:

echo 2 | sudo tee /sys/devices/cpu/rdpmc

Run your application:

scripts/runenv.sh <your_app>

The runenv.sh script runs an application in a new shell environment that properly sets LD_PRELOAD to the library available in the build folder. We do not modify the current shell environment to avoid getting other applications interposed by the emulator unexpectedly.

Alternatively, you may directly link the library to your application but the nvmemul library must come first in the linking order to ensure we properly interpose on necessary functions. Additionally, this script sets the NVMEMUL_INI environment variable to point to the nvmemul.ini configuration file available in the emulator's source code root folder.

Configuration file

Emulator runtime parameters can be defined in a configuration file.

The default path is ./nvmemul.ini but you may change the path through the environment variable $NVMEMUL_INI (see scripts/runenv.sh).

The main available parameters are:

- Latency:
  enable                  True means the latency emulation is on, false,
                          the latency emulation is disabled.
  inject_delay            True means the delay injection is on, false,
                          the emulator will skip the delay injection
  read                    The target read latency in nano seconds. It must 
                          be greater than the hardware latency. This value
                          is automatically consisted by the emulator.
  write                   The target write latency in nano seconds. It must 
                          be greater than the hardware latency. This value
                          is automatically consisted by the emulator.
  max_epoch_duration_us   This is the epoch duration in micro seconds. 
                          Eventually an epoch may be greater than this value
                          depending on signal delivery managed by Kernel.
  min_epoch_duration_us   The minimum epoch duration. 
- Bandwidth:
  enable                  True means the bandwidth emulation is on, false, 
                          it is disabled.
  model                   File path used by the emulator to cache the 
                          detected hardware bandwidth characteristics.
  read                    Target read bandwidth in MB/s.
  write                   Target write bandwidth in MB/s;
- Topology:
  mc_pci                  File path used by the emulator to cache the PCI 
                          bus topology. It is not required if bandwidth 
                          emulation is disabled.
  physical_nodes          List all CPU sockets ids to be added to the known
                          topology. An odd number of CPU sockets means it
                          will not be possible to configure all CPUs in
                          pairs and then a single CPU will be used as NVM
                          only. See Emulation modes section below.
- Statistics:
  enable                  True means the statistics collection and report is
                          enable, false, it is disable. See the Statistics
                          section below.
  file                    File path used by the emulator to write the 
                          statistics report. If not provided, emulator will 
                          use stdout.
- Debug:
  level                   Shows debugging message with level up to this 
                          value, the greater this value is, the more verbose 
                          the debug log will be.
                          0: off; 1: critical; 2: error; 3: warning; 4: info;
                          5: debugging.
  verbose                 If greater than zero shows source code information
                          along with the debugging message.

Latency emulation modes

The emulator may run application threads on a NVM only mode or DRAM+NVM mode. It depends if the system has more than one CPU socket and if the topology configuration enables multiple CPU socket.

For NVM only mode, the emulator will use a CPU socket with no sibling node and make use of the DRAM available in that socket to emulate NVM. Any DRAM memory access on this socket will produce delays injection to emulate the target latency.

For DRAM+NVM mode, the emulator will differentiate DRAM from virtual NVM latencies. It is supported only on IvyBridge, Haswell (and higher) Intel processor systems with 2 CPU sockets or more. A proper configuration as mentioned above and explicit calls to NVM memory allocation in the application’s source code is required.

  • The emulator will bind application threads to node 0 CPU and DRAM. The other CPU socket will not be used for application threads and the DRAM from this second socket will be used as virtual NVM;
  • The application must explicitly allocate virtual NVRAM memory using pmalloc(size) and pfree(pointer, size) API provided by the emulator.

See the NVM programming section below.

NVM programming

The emulator provides an API for allocating and deallocating memory from NVM space. It is possible to use this API on both NVM only and DRAM+NVM modes. However, it is really required to use this API in the DRAM+NVM mode so the emulator can clearly differentiate DRAM from NVM memory access latencies. This is the API available for user applications:

void *pmalloc(size_t size);
void pfree(void *start, size_t size);

The application can include the NVM_EMUL/src/lib/pmalloc.h header file to properly define these headers. See test/test_nvm.c and test/test_nvm_remote_dram.c for an example on how to allocate memory on respectively local DRAM or virtual NVM on a DRAM+NVM emulation mode.

Statistics

The emulator collects statistical data to help on emulation accuracy validation. If enabled, by default the emulator will show the statistics report when the user application terminates to the standard output. Some applications suppress output to stdout, you can still see the reports by defining a target file for the report in the configuration file. When using a file as output, the emulator appends the result to the file and then previous reports are not overwritten. The statistics source code can also be statically removed at compile time. See Building section.

These are the reported statistics:

- initialization duration   Time in micro seconds took by the emulator to 
                            initialize.
- running threads           The number of threads still running. If the report
                            was called automatically by the emulator, all user 
                            threads are already terminated.
- terminated threads        Number of terminated threads, including the main
                            thread.
For each application thread:
- thread id                 Thread id.
- cpu id                    CPU id where the user thread was bind to.
- spawn timestamp           Thread spawn timestamp as reported by the
                            monotonic time.
- termination timestamp     Thread termination timestamp as reported by the
                            monotonic time.
- execution time
- stall cycles              Total number of CPU stalls caused by memory 
                            accesses made by this thread.
- NVM accesses              Number of effective NVM accesses performed by
                            the application.
- latency calculation overhead cycles     Overhead cycles caused by the 
                                          emulator and that could not be
                                          amortized. Zero is expected.
                                          Otherwise, consider increasing
                                          the epoch duration.
- injected delay cycles     Total number of cycles injected by the emulator
                            to emulate the target latency.
- injected delay in usec    Same value as above, but shown in micro seconds.
- longest epoch duration    The effective longest epoch duration ever 
                            performed for this thread.
- shortest epoch duration   The effective shortest epoch duration ever 
                            performed for this thread.
- average epoch duration    The average epoch duration for this thread.
- number of epochs          Total number of epochs performed for this 
                            thread.
- epochs which didn't reach min duration   Number of epochs requested by 
                                           either Thread Monitor or thread 
                                           synchronizations, but were not 
                                           open since the epoch durations
                                           didn't reach the minimum epoch
                                           duration.
- static epochs requested   Number of epochs requested by the Thread Monitor.

Support to PAPI

Performance API (PAPI) library may be used with the emulator and there are some hooks to switch the current CPU counters reading method to PAPI. Up to the time of this writing, there was no way to make PAPI CPU counter reading to perform at the performance level required by the emulation. In the future, if it is desired to switch to PAPI, follow these steps:

  • Device pmc_ioctl_setcounter() and emulator lib set_counter() in dev/pmc.c calls can be deleted.
  • Define PAPI_SUPPORT for src/lib/* source code.
  • Compile with lib/cpu/pmc-papi.c rather than lib/cpu/pmc.c.
  • Link code with PAPI and add PAPI include directory.
  • Some extra tweaks may be required, check TODOs in the code.

Multiple emulated processes and MPI programs

The emulator needs to bind user threads to specific CPU cores in order to optimize emulation results. It is required to export the EMUL_LOCAL_PROCESSES environment variable with the number or emulated processes on the host. The emulator will manage each emulated processes to partition the available CPUs in a coordinated way. It is recommended to set EMUL_LOCAL_PROCESSES with up to half number of available CPU cores (note DRAM+NVM mode already reserves half of available CPU cores).

If EMUL_LOCAL_PROCESSES is not set or set with a value lower than 2, the emulator will not partition CPU cores per process.

If some process crashes the emulator might not have cleaned up the environment and the process rank ids will not be correctly managed. On this case, close all emulated processes and delete files /tmp/emul_lock_file and /tmp/emul_process_local_rank if they exist.

Bandwidth emulation

Quartz supports an emulation mode with "throttled" memory bandwidth.

The memory bandwidth emulation makes use of the copy kernel from the Stream benchmark, openMP version. When the bandwidth emulation is enabled for a first time, Quartz creates a memory bandwidth model by utilizing the available Thermal Registers in the Memory Controller and measuring the corresponding memory bandwidth. This initial step of building a model might take several minutes (~10min).

For the memory bandwitdh emulation, turn off the latency modeling in the configuration file and select all available NUMA nodes in the configuration file in order to prepare the model for any combination of NUMA nodes selection.

Modeling data will be cached to these files:

/tmp/bandwidth_model
/tmp/mc_pci_bus

As first step, the emulator will detect the Memory Controller Thermal Registers Control PCI addresses and cache it to /tmp/mc/pci_bus. After this step, the emulator will close the current execution to safely clear NUMA bindings. Rerun the process to resume the work.

Quartz will create the file: /tmp/bandwidth_model.

It reflects the relationship between Thermal Registers and achievable memory bandwidth (in a single socket). The line format in this file is:

read <thermal register value> <memory bandwidth MB/s>

This file should present ascending values of memory bandwidth ranging from hundreds of MiB/s to tens of GiB/S. These values (or their approximations) can be used for the experiments with memory bandwidth throttling. Note, that the model is built once: it is cached and then used for all later experiments. (You can also run a specially prepared automated script bandwidth-model-building.sh in directory benchmark-tests. For details see [README-BENCHMARKS-TESTING.md] (https://github.hpe.com/labs/quartz/blob/master/README-BENCHMARKS-TESTING.md).

For example, to enable memory bandwidth throttling at 2 GB/s, you should change the emulator configuration file "nvmemul.ini" using the following settings:

bandwidth:
{
enable = true;
model = "/tmp/bandwidth_model";
read = 2000;
write = 2000;
};

Both read and write bandwidth values must be set to the same value since the emulator does not model read/write independently in the current version. See Limitations session.

The pmalloc() family is not intended to be used with the bandwidth modeling. Use numactl for instance to bind CPU and memory of the used application to the intended NUMA node depending. The bandwidth emulator considers the virtual NVRAM node only (in the configuration with two sockets). So it is required the application to keep processes/threads and data on the same NUMA node for bandwidth experiments.

Automated Benchmark Runs

We have created several automated tests with benchmark runs and output analysis for testing the correctness of configured emulation environment and the accuracy of expected results. For details see [README-BENCHMARKS-TESTING.md] (https://github.hpe.com/labs/quartz/blob/master/README-BENCHMARKS-TESTING.md).

Limitations

The emulator functionality may be affected by certain conditions in user applications:

  • application sets threads CPU and memory affinity.
  • application opens much more concurrent threads than available cores per socket. Note that on DRAM+NVM emulation mode, half of the available CPU cores is not used for user threads.
  • application sets handler for SIGUSR1. Other:
  • Write memory latency is not yet implemented.
  • Write/Read memory bandwidth emulation cannot be set independently.
  • The signal handler may cause syscalls in the application to fail. It is recommended to implement retries at the application level as a good practice for syscalls.
  • Child process from fork() calls are not tracked by the emulator. As a workaround, the emulator could make the library initialization function available in the external API. Applications then should call this function in the beginning of the child process.
  • OpenMP applications may use synchronization primitives not based on pthreads which are currently not supported.
  • See Todo session for details.

Todo list

Please see accompanied TODO.dox or extended documentation for an extensive list.

#License

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or (at
your option) any later version. This program is distributed in the
hope that it will be useful, but WITHOUT ANY WARRANTY; without even
the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License for more details. You
should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation,
Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

#Copyright

    (c) Copyright 2016 Hewlett Packard Enterprise Development LP

NOTE: This software depends on other packages that may be licensed under different open source licenses.

More Repositories

1

netperf

Netperf is a benchmark that can be used to measure the performance of many different types of networking. It provides tests for both unidirectional throughput, and end-to-end latency.
C
725
star
2

swarm-learning

A simplified library for decentralized, privacy preserving machine learning
Python
331
star
3

cacti

An integrated cache and memory access time, cycle time, area, leakage, and dynamic power model
C++
301
star
4

squest

Service request portal on top of Ansible Tower/AWX
Python
294
star
5

LinuxKI

LinuxKI Toolset (Trace-based performance analysis tool)
C
224
star
6

dlcookbook-dlbs

Deep Learning Benchmarking Suite
Python
130
star
7

POSH-HPEOneView

PowerShell language bindings library for HPE OneView.
PowerShell
125
star
8

mcpat

An integrated power, area, and timing modeling framework for multicore and manycore architectures
C++
122
star
9

PacketRusher

High performance 5G UE/gNB Simulator and CP/UP load tester.
Go
109
star
10

oneview-ansible

This project is no longer being developed and has limited support. Please use the newer Ansible Collection project: https://github.com/HewlettPackard/oneview-ansible-collection
Python
104
star
11

yoda

GitHub extension for agile project management using the issues subsystem.
JavaScript
90
star
12

python-hpOneView

DEPRECATED - no longer actively maintained. New repository: https://github.com/HewlettPackard/oneview-python
Python
87
star
13

python-ilorest-library-old

Python library for iLO RESTful API
Python
85
star
14

wireless-tools

Wireless Tools for Linux
C
85
star
15

PowerShell-ProLiant-SDK

PowerShell sample scripts for managing HPE servers
PowerShell
85
star
16

kraal

Enables the use of Kotlin coroutines and GraalVM native-image together
Kotlin
84
star
17

monkeyble

End-to-end testing framework for Ansible
Python
78
star
18

Atlas

Atlas: Programming for Persistent Memory
C++
74
star
19

foedus

FOEDUS: Fast Optimistic Engine for Data Unification Services
65
star
20

foedus_code

FOEDUS main source code repository
C++
64
star
21

structex

Go structure annotations that supports encoding and decoding; similar to C-style bitfields. Supports bitfield packing, self-describing layout parameters, and alignment.
Go
58
star
22

ansible-ilorest-role

Ansible role for installing the Python iLOrest library and showcasing a few examples.
Python
52
star
23

terraform-provider-oneview

Automates the provisioning of physical infrastructure from a private cloud using templates from HPE OneView with Terraform
Go
49
star
24

reconbf

Recon system hardening scanner
Python
47
star
25

sandpiper

Implementation of the Loopy Belief Propagation algorithm for Apache Spark
Scala
42
star
26

sparkle

C++
38
star
27

ilo-ansible-collection

Ansible Collection and Sample Playbooks for HPE iLO
Python
38
star
28

dockerfile-parser-rs

a Rust library for parsing, validating, and modifying Dockerfiles
Rust
37
star
29

jupyterhub-samlauthenticator

jupyterhub-samlauthenticator
Python
34
star
30

cloudformation-plus

A tool that adds features to AWS CloudFormation that reduce the amount of code you must write to deploy non-trivial applications.
Python
31
star
31

cmf

CMF library helps to collect and store information associated with ML pipelines. It tracks the lineages for artifacts and executions of distributed AI pipelines. It provides API's to record and query the metadata associated with ML pipelines. The framework adopts a data first approach and all artifacts recorded in the framework are versioned and identified by the content hash.
Python
30
star
32

lustre_exporter

Prometheus exporter for use with the Lustre parallel filesystem
Go
29
star
33

oneview-python

Python library for HPE OneView
Python
28
star
34

nvthreads

C
27
star
35

oneview-golang

Golang bindings for OneView api's
Go
27
star
36

nagios-plugins-hpilo

Nagios plug-in for iLO Agentless Management
Shell
26
star
37

mds

Managed Data Structures
Java
26
star
38

dpp

Device Provisioning Protocol is a Wi-Fi Alliance program to securely provision devices to obtain network access.
C
25
star
39

mdc-toolkit

24
star
40

Docker-SimpliVity

Ansible deployment playbooks with detailed deployment guides to rapidly provision a Docker dev and Docker ops environment in less than 30 minutes
Shell
24
star
41

woodchipper

An interactive command-line log processor
Rust
23
star
42

oneview-ansible-collection

Ansible Collection and Sample Playbooks for HPE OneView
Python
22
star
43

hpe-solutions-openshift

This GitHub site contains deployment guides and resources for deploying Red Hat OpenShift on HPE platforms.
Python
22
star
44

chef-provisioning-oneview

Chef Provisioning Driver for HPE OneView
Ruby
21
star
45

lustre-csi-driver

A Lustre container storage interface that allows Kubernetes to mount/unmount provisioned Lustre filesystems into containers.
Go
20
star
46

supersim

A flexible event-driven cycle-accurate network simulator
C++
19
star
47

hpe3par_ansible_module

HPE Alletra 9000 and HPE Primera and HPE 3PAR ansible module to configure, provision and manage storage systems and resources
Python
18
star
48

galadriel

SPIFFE Federation the easy way
Go
18
star
49

csa-ce

This repo contains scripts which start HPE Cloud Service Automation Community Edition 4.7 (HPE CSA CE) in Docker.
Shell
17
star
50

ezdemo

HPE Ezmeral Deployment tool for demos
Shell
17
star
51

ilo-chef

iLO Resource Provider for Chef
Ruby
17
star
52

oneview-chef

This project is no longer being developed and has limited support. In the near future this repository will be fully deprecated. Please consider using other OneView projects, such as Terraform and Ansible Collection
Ruby
17
star
53

oneview-osdeployment

Sample HPE OneView OS deployment integration
Python
16
star
54

oneview-sdk-java

Java SDK for HPE OneView
Java
16
star
55

ilo-sdk-ruby

iLO Software Development Kit for Ruby Programmers.
Ruby
15
star
56

criu-pmem

C
15
star
57

oneview-redfish-toolkit

HPE OneView Redfish Toolkit provides a REST service to answer DMTF's Redfish compliant requests by querying HPE OneView
Python
15
star
58

javascript-ilorest-library

JavaScript
15
star
59

mpgc

Multi-Process Garbage Collector
C++
15
star
60

logger

A log parsing engine written in Java for high performance. Additionally, logger is also highly configurable.
Java
14
star
61

pcp_exporter

Exporter for Performance CoPilot Metrics
Go
14
star
62

Aruba-FlaskwithNetworking

Python
14
star
63

zabbix-plugins-hpeilo

Shell
13
star
64

hpe-oneview-hubot

HPE OneView Chatbot Integration
JavaScript
13
star
65

osfci

Go
13
star
66

prometheus-parser-rs

a Rust library for parsing and validating Prometheus query expressions
Rust
12
star
67

nagios-hpeilo-restful-extension

Nagios Plug-in for iLO RESTful Extension
Shell
12
star
68

c-spiffe

C
12
star
69

LSGI

Large-Scale Graph Inference
HTML
12
star
70

oneview-powershell-samples

HPE OneView PowerShell sample scripts
PowerShell
12
star
71

oneview-sdk-ruby

This project is no longer being developed and has limited support. In the near future this repository will be fully deprecated. Please consider using other OneView projects, such as Golang and Python.
Ruby
12
star
72

zing-stats

Tool for generating summary stat reports and graphs from Gerrit (https://www.gerritcodereview.com/) and GitHub Enterprise review and pull requests data using https://plot.ly/.
Python
12
star
73

py-spiffe

Python library for SPIFFE support
Python
11
star
74

Jenkins-stats

Tool for gathering job data from the Jenkins CI system (https://jenkins-ci.org/) and generating summary stat reports and graphs. These reports cover metrics such as success/failure rates and job duration.
Python
11
star
75

image-streamer-tools

PowerShell
10
star
76

OpenShift-on-SimpliVity

10
star
77

lsrrb

Linux Software Raid Redundant Boot
Python
10
star
78

Docker-Synergy

Shell
10
star
79

shoveller

Rust
10
star
80

hpecli

Command-line interface for HPE products and services
Go
10
star
81

hpe3par_pstoolkit

The HPE Alletra 9000 and Primera and 3PAR PowerShell Toolkit supports cmdlets, which are wrappers around the native HPE Alletra 9000 or HPE Primera or HPE 3PAR storage CLI commands and Web Services API (WSAPI).
PowerShell
10
star
82

image-streamer-esxi

9
star
83

chef-ilorest-cookbook

Chef cookbook for installing the Python iLOrest library and showcasing a few examples.
Python
9
star
84

GlobalDashboardPS

A Powershell module for working with HPE OneView Global Dashboard
PowerShell
9
star
85

hpe-notebooks

Jupyter Notebook
9
star
86

hpe3par_python_sdk

HPE Alletra 9000 and HPE Primera and HPE 3PAR Software Development Kit for Python
Python
9
star
87

RiscVEdk2

C
9
star
88

HPEDSCC-PowerShell-Toolkit

A PowerShell Toolkit that enables management of a HPE GreenLake DSCC (Data Storage Cloud Console) environment via easy to use PowerShell commands which interface with the publically available RestAPI.
PowerShell
9
star
89

gull

a multi-node fabric-attached memory manager that provides simple abstractions for accessing and allocating NVM from fabric-attached memory
C++
9
star
90

iLOAmpPack-Redfish-API-Docs

iLO Amplifier Pack Redfish API Documentation
JavaScript
8
star
91

python-opsramp

Python binding for the OpsRamp API
Python
8
star
92

ironic-driver-oneview

HPE OneView driver for OpenStack Ironic bare-metal machine provisioning
8
star
93

simplivity-ansible

Ansible Modules for HPE SimpliVity
Python
8
star
94

hpe-nvm

Documentation and utilities for NVDIMM-N device management and support
8
star
95

oneview-puppet

This project is no longer being developed and has limited support. In the near future this repository will be fully deprecated. Please consider using other OneView projects, such as Terraform and Ansible Collection
Ruby
8
star
96

SHARP

Python
7
star
97

devid-provisioning-tool

Go
7
star
98

oneview-ansible-samples

A collection of sample code for oneview-ansible
7
star
99

dc-rl

HTML
7
star
100

simplivity-python

This library provides a Python interface to the HPE SimpliVity REST APIs
Python
7
star