Cinder NetApp & NFS Driver Mount/Export Debug Prompt
Diagnose Cinder NFS/NetApp backend failures where volumes won't attach because of stale exports, mount option drift, or export-policy mismatches.
- Target user
- Advanced Cinder operators running NFS or NetApp ONTAP backends
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior Cinder storage operator who runs NFS and NetApp ONTAP (NFS/iSCSI) backends. I will provide: - OpenStack release, Cinder driver in use (`NetAppCmodeNfsDriver`, generic `NfsDriver`, etc.) and the relevant cinder.conf backend stanza - `nfs_shares_config` / export list, `nfs_mount_options`, and ONTAP export-policy/rule details if NetApp - The symptom: attach times out, volume `error`, stale file handle, permission denied, or wrong-size volume - cinder-volume and nova-compute logs around the attach, plus `mount`/`showmount -e` output from the compute host - Whether NFS v3 or v4.1, and whether multipath/pNFS is involved Your job: 1. **Export reachability** — confirm the compute host can actually mount the share (export policy, network path, NFS version negotiation). 2. **Mount-option drift** — compare configured `nfs_mount_options` vs what is actually mounted; flag mismatches (e.g., missing `nolock`, `vers`, `hard/soft`). 3. **Stale handle / qtree** — for NetApp, check qtree/export-policy rules and whether a failover or LIF migration left stale handles. 4. **Capacity vs reservation** — verify thin-provision/dedup settings aren't reporting capacity Cinder then can't honor. 5. **Root cause** — name the single most likely cause with the log/command evidence that proves it. 6. **Fix + verify** — the export/policy/mount fix plus a clean attach test on one compute before fleet rollout. Output as: (a) an export-to-compute reachability matrix, (b) a mount-option diff table, (c) a fix runbook with single-host attach validation. Never force-unmount or change an export policy that backs running volumes without draining attachments first; validate one host before changing the backend.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
NFS and NetApp backend failures in Cinder are deceptive because the error surfaces in Nova (“attach timed out”) while the root cause lives in the storage export layer — an export-policy rule that doesn’t include the compute’s IP, a LIF migration that left stale handles, or a mount-option drift that only bites under network jitter. This prompt makes the model start from export reachability and work toward the symptom, which is the opposite of how a stuck operator usually debugs (they stare at the Nova error and miss that the host can’t even mount the share).
The mount-option diff is the highest-value step. Operators set nfs_mount_options in cinder.conf and assume reality matches, but a fallback or an older volume can be mounted with different options, and a soft vs hard or wrong vers mismatch quietly risks data under network blips. Forcing a literal diff between configured and actual mount options catches the kind of drift that no one notices until a partition event.
The drain-before-changing-exports guardrail is critical here because a NetApp export policy or LIF backs many volumes at once. An AI that proposes “just update the export policy” without that constraint can detach every running volume on a share. Keeping the change scoped to a single-host validation, with the human draining attachments first, is what makes this safe to run against a backend serving production workloads.
Related prompts
-
Cinder Multi-Backend & Volume-Type Design Prompt
Design Cinder multi-backend storage with sane volume types, extra-specs, QoS, and scheduler hints — so volumes land on the right backend (Ceph, LVM, NetApp) and the cinder-scheduler stops sending them to the wrong place.
-
Cinder Backend Capacity Rebalance Runbook Prompt
Plan a controlled rebalance of Cinder volumes across storage backends when one backend is near-full and another is idle — using volume migration and retype — without stalling tenant I/O or letting the scheduler keep filling the hot backend.
-
Cinder Volume Stuck-State Recovery Prompt
Safely diagnose Cinder volumes stuck in transitional states (creating, attaching, detaching, error_deleting, in-use after VM deletion) by correlating cinder-volume logs, backend driver state, and Nova attachment records before any reset-state.
-
Cinder Volume Migration & Retype Runbook Prompt
Plan safe Cinder volume migrations and retypes — moving volumes between backends or volume types with the right migration policy and minimal attached-instance disruption.
More OpenStack prompts & error guides
Browse every OpenStack prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.