NVIDIA ovstorage#
The storage library publishes packages. No resolver wheels are published for this release; build the resolver for the supported host SDK as described in getting started.
ovstorage gives an application one API for reading and writing content across local, HTTP, cloud, and service-backed storage, without binding its code to a single storage SDK. This repository also includes the source of ovstorage-usd-resolver, an OpenUSD ArResolver plugin built on that library, so a host can open and save remote USD stages through ordinary OpenUSD calls.
In this documentation you will find getting started guides, the storage library and plugin guides, and the USD resolver reference.
Getting started — install the storage package and build the resolver against a compatible OpenUSD SDK.
ovstorage documentation — library bindings, configuration, storage plugins, and operations.
USD resolver documentation — architecture, configuration, CLI, and compatibility commitments.
How USD content flows — how a USD request is resolved, materialized, and saved through the stack, with sequence diagrams.
Note
ovstorage is currently preview software. VERSION.md records the component versions and the storage requirement for this snapshot. Public C++ headers may change before 1.0.
Features#
One object API across backends —
stat,read_bytes,read_stream,materialize,write,delete,list,copy, andrename, where the selected backend supports them.Configuration-based routing — callers pass an object address and the library routes each operation to the configured backend provider, so switching backends does not require recompiling against a different storage SDK.
Remote USD stages — resolve, compose, and save USD over provider-backed URI schemes, while local paths continue through OpenUSD’s default filesystem resolver.
Host surfaces — the Rust library, a stable C ABI, a header-only C++ wrapper, the Python wheel, a CLI, and MCP.
Standalone — runs outside Omniverse Kit.
License#
See the repository LICENSE and NOTICE. Each component also carries its own license and notice files, and third-party components remain under their own licenses.
Getting Started
Storage Library
- Overview
- Configuration
- Using ovstorage from Rust
- Using ovstorage from Python
- Installation
- What you import
- Compose a Stack
- Declare Python Layers
- The async surface
- Cancellation
- Documented Limits
- Etag-bound writes
- Connection accessors
- Credential callbacks
- What’s not supported
- Process-global auth substrate
- Address helpers
- Interactive authentication
- Type marshaling
- Threat model
- Conformance posture
- See also
- Using ovstorage from C++
- Using the REST Gateway
- Agent Consumer Reference
- Agent Result Envelope
- MCP Tools
Storage Plugins
- Storage Plugin Guide
- Plugin Development
- Foreign interface — the C ABI
- Layer shape — vtables, manifest, init
- Surface boundary — host APIs vs plugin Layer
- Type vocabulary
- Error model
- Connection lifecycle errors
- Addressing a connection: finding the layer that owns it
- URL canonicalization
ReadResult: the read shapes- Plugin Layer contract
- C-ABI surface
- Ownership and lifetime invariants
- Capability vocabulary
- Object information from the backend
- Conformance harness
- Streaming seams
- Build and load
- Plugin macros
- ABI roadmap
- ABI-stability rules
- What’s not supported
- Azure plugin (
azure) - Broker storage plugin (kind
broker) - Local filesystem backend (
file) - GCS plugin (
gcs) - HTTP plugin (
http) - Hugging Face Hub plugin (
huggingface) - Nucleus plugin (
nucleus) - OpenDAL plugin (
opendal) - S3 plugin (
s3) - Omniverse Storage Service plugin (kind
omniverse-storage-service) - Test plugin (
ovstorage-plugin-test) - Credential Providers
- Plugin Conformance
- Layer Ownership Registry
The broker and authorization guides under Operations apply to existing deployments only; normal library and resolver use embeds storage in-process.
Operations