Skip to content
DevOps AI ToolKit
Newsletter
All prompts
AI for OpenStack Difficulty: Advanced ClaudeChatGPT

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.

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

Newsletter

Free: the DevOps AI Incident-Triage Cheat Sheet

Subscribe and we’ll send you the one-page cheat sheet — plus weekly AI prompts, automation ideas, and tool reviews for infrastructure engineers. One email a week. No spam, unsubscribe anytime.

  • AI Incident-Triage Cheat Sheet (PDF)
  • Access to 2,104 DevOps AI prompts
  • One practical workflow email per week