Pure Fusion File Presets & Workloads on FB 4.6.7 and FA 6.10.4: Less Click‑Ops, More Policy

If you’ve ever built the “standard” NFS/SMB layout for an app for the fifth time in a week and thought “this should be a function, not a job”, this release is for you.

With FlashBlade version 4.6.7 and FlashArray version 6.10.4, Pure Fusion finally gives file the same treatment block has had for a while: presets and workloads for file services across FlashBlade and FlashArray, a much sharper Presets & Workloads UI, plus smarter placement and resource naming controls tuned for real environments—not demos.

This post is written for people who already know what NFS export policies and snapshot rules are and are mostly annoyed they still have to configure them by hand.

Problem Statement: Your “Standard” File Config is a Lie

Current pattern in most environments:

• Every app team needs “just a few file shares”.
• You (or your scripts) manually:
• Pick an array, hope it’s the right one.
• Create file systems and exports.
• Glue on snapshot/replication policies.
• Try to respect naming conventions and tagging.
• Six months later:
• Same logical workload looks different on every array.
• Audit and compliance people open tickets.
• Nobody remembers what “fs01-old2-bak” was supposed to be.

Fusion File Presets & Workloads exist to eradicate that pattern:

• Presets = declarative templates describing how to provision a workload (block or file).
• Workloads = concrete instances of those presets deployed somewhere in a Fusion fleet (FA, FB, or both).

In nerd-speak, think: Helm chart for storage (preset) vs Helm release (workload).

Quick Mental Model: What Presets & Workloads Actually Are

A File Preset can include, for example:

• Number of file systems (FlashBlade or FlashArray File).
• Directory layout and export policies (for NFS/SMB).
• Snapshot policies and async replication (through protection groups or pgroups).
• Per‑workload tags (helps in finding a needle in a haystack & more)
• Quota and Snapshot parameters

A Workload is:

• A Fusion object that:
• References the preset in it’s entirety.
• Tracks where the underlying Purity objects live.
• Surfaces health, capacity, and placement at the fleet level.

In code‑brain terms:

preset: app-file-gold

parameters:

  env: prod

  fs_count: 4

  fs_size: 10TB

  qos_iops_max: 50000

placement:

  strategy: recommended   # Pure1 or dark‑site heuristic depending on connectivity

  constraints:

    platform: flashblade

Fusion resolves that into resources and objects on one or more arrays: purefs objects, exports, pgroups, QoS, tags, and consistently named resources.

So, what’s new you ask?

What’s New on FlashBlade in Purity//FB 4.6.7

1. Fusion File Presets & Workloads for FlashBlade

Purity//FB 4.6.7 is the release where FlashBlade joins the Fusion presets/workloads party for file.

Key points:

• You can now define Fusion file presets that describe:
• Number/size of file systems.
• Export policies (NFS/SMB).
• Snapshot/replication policies.
• Tags and other metadata.
• You then create Fusion file workloads from those presets:
• Deployed onto any compatible FlashBlade or FlashArray in the fleet, depending on your constraints and placement recommendations.

That means you stop hand‑crafting per‑array configs and start stamping out idempotent policies.

2. New Presets & Workloads GUI on FlashBlade

Putrity//FB version 4.6.7 brings proper Fusion GUI surfaces to FB:

• Storage → Presets
• Create/edit/delete Fusion presets (block + file).
• Upload/download preset JSON directly from the GUI.
• Storage → Workloads
• Instantiate workloads from presets.
• See placement, status, and underlying resources across the fleet.

Why this is a real improvement, not just new tabs:

• Single mental model across FA and FB:
• Same abstractions: preset → workload → Purity objects.
• Same UX for block and file.
• Guard‑railed customization:
• GUI only exposes parameters marked as configurable in the preset (with limits), so you can safely delegate provisioning to less storage‑obsessed humans without getting random snapshot policies.

3. JSON Preset Upload/Download (CLI + GUI)

This new release also adds full round‑trip JSON support for presets, including in the GUI:

On the CLI side:

# Export an existing preset definition as JSON

purepreset workload download app-file-gold > app-file-gold.json

 

# Edit JSON, save to file share, version control, commit to git, run through CI, etc…

 

# Import the preset into another fleet or array

purepreset workload upload --context fleet-prod app-file-gold < app-file-gold.json

Effects:

• Presets become versionable artifacts (Git, code review, promotion).
• You can maintain a central preset catalog and promote from dev → QA → prod like any other infra‑as‑code.
• Sharing configs stops being “here’s a screenshot of my settings.”,

4. Fusion Dark Site File Workload Placement + Get Recommendations

Many folks run fleets without outbound connectivity, for various reasons. Until now, that meant “no fancy AI placement recommendations” for those sites.

Fusion Dark Site File Workload Placement changes that:

• When Pure1 isn’t reachable, Fusion can still compute placement recommendations for file workloads across the fleet using local telemetry:
• Capacity utilization.
• Performance headroom.
• QoS ceilings/commitments (where applicable).
• In the GUI, when you’re provisioning a file workload from a preset, you can hit “Get Recommendations”:
• Fusion evaluates candidate arrays within the fleet.
• Returns a ranked list of suitable targets, even in an air‑gapped environment.

So, in dark sites you still get:

• Data‑driven “put it here, not there” hints.
• Consistency with what you’re used to on the block side when Pure1 is available, but without the cloud dependency.

What’s New on FlashArray in Purity//FA 6.10.4

1. Fusion File Presets & Workloads for FlashArray File

Version 6.10.4 extends Fusion presets and workloads to FlashArray File Services:

You can now:

• Define file presets on FA that capture:
• File system count/size.
• NFS/SMB export behavior.
• QoS caps at workload/volume group level.
• Snapshot/async replication policies via pgroups.
• Tags and metadata.
• Provision file workloads on FlashArray using those presets:
• From any Fusion‑enabled FA in the fleet.
• With the same UX and API that you use for block workloads.

This effectively normalizes block and file in Fusion:

• Fleet‑level view.
• Same provisioning primitives (preset→workload).
• Same policy and naming controls.

2. Fusion Pure1‑WLP Replication Placement (Block Workloads)

Also  introduced is Fusion Pure1 Workload Replication Placement for Block Workloads:

When you define replication in a block preset:

• Fusion can ask Pure1 Workload Planner for a placement plan:
• Primary/replica arrays are chosen using capacity + performance projections.
• It avoids packing everything onto that one “lucky” array.
• Workload provisioning then uses this plan automatically:
• You can override, but the default is data‑backed rather than “whatever’s top of the list.”

It’s the same idea as dark‑site file placement, just with more telemetry and projection thanks to Pure1.

Resource Naming Controls: Have it your way

If you care about naming standards, compliance, and audit (or just hate chaos and stress), this one matters.

Fusion Presets Resource Naming Controls let you define deterministic naming patterns for all the objects a preset creates:

Examples:

• Allowed variables might include:
• workload_name
• tenant / app / env
• platform (flasharray-x, flashblade-s, etc.)
• datacenter site code
• Sequenced IDs
• You can also define patterns like:

fs_name_pattern: "{tenant}-{env}-{workload_name}-fs{seq}"

export_name_pattern: "{tenant}_{env}_{app}_exp{seq}"

pgroup_name_pattern: "pg-{app}-{env}-{region}"

Result:

• Every file system, export, pgroup, and volume created by that preset:
• Follows the pattern.
• Satisfies internal CS/IT naming policies for compliance and audits.
• You can still parameterize inputs (e.g., tenant=finops, env=prod), but the structure is enforced.

No more hunting down “test2-final-old” in front of auditors and pretending that was intentional. Not speaking from experience though :-) 

The Updated Presets & Workloads GUI: Simple is better

Across Purity//FB v4.6.7 and Purity//FA v6.10.4, Fusion’s UI for presets and workloads is now a graphical wizard-type interface that is easier to follow, with more help along the way..

Single Pane, Shared Semantics

• Storage → Presets
• Block + file presets (FA + FB) in one place.
• JSON import/export.
• Storage → Workloads
• All workloads, all arrays.
• Filter by type, platform, tag, or preset.

Benefits for technical users:

• Quick answer to:
• “What’s our standard for <workload X>?”
• “Where did we deploy it, and how many variants exist?”
• Easy diff between:
• “What the preset says” vs “what’s actually deployed.”

Guard‑Rails Through Parameterization

Preset authors (yes, we’re looking at you) decide:

• Which fields are fixed (prescriptive) vs configurable.
• The bounds on configurable fields (e.g., fs_size between 1–50 TB).

In the GUI, that becomes:

• A minimal set of fields for provisioners to fill in.
• Validation baked into the wizard.
• Workloads that align with standards without needing a 10‑page runbook.

Integrated Placement and Naming

When you create a workload via the new GUI, you get:

• “Get Recommendations” for placement:
• Pure1‑backed in connected sites (block).
• Dark‑site logic for file workloads on FB when offline.
• Naming patterns from the resource naming controls baked in, not bolted on afterward.

So you’re not manually choosing:

• Which array is “least bad” today.
• How to hack the name so it still passes your log‑parsing scripts.

CLI / API: What This Looks Like in Practice

If you prefer the CLI over the GUI, Fusion doesn’t punish you.

Example: Defining and Using a File Preset

1. Author a preset JSON (simplified example):

{

  "name": "app-file-gold",

  "type": "file",

  "parameters": {

    "fs_count": { "min": 1, "max": 16, "default": 4 },

    "fs_size_tib": { "min": 1, "max": 50, "default": 10 },

    "tenant": { "required": true },

    "env": { "allowed": ["dev","test","prod"], "default": "dev" }

  },

  "naming": {

    "filesystem_pattern": "{tenant}-{env}-{workload_name}-fs{seq}"

  },

  "protection": {

    "snapshot_policy": "hourly-24h-daily-30d",

    "replication_targets": ["dr-fb-01"]

  }

}

1. Upload preset into a fleet:

purepreset workload upload --context fleet-core app-file-gold < app-file-gold.json

1. Create a workload and let Fusion pick the array:

pureworkload create \

  --context fleet-core \

  --preset app-file-gold \

  --name payments-file-prod \

  --parameter tenant=payments \

  --parameter env=prod \

  --parameter fs_count=8 \

  --parameter fs_size_tib=20

1. Inspect placement and underlying resources:

pureworkload list --context fleet-core --name payments-file-prod --verbose

Behind the scenes:

• Fusion picks suitable arrays using Pure1 Workload Placement (for connected sites) or dark‑site logic
• purefs/exports/pgroups are created with names derived from the preset’s naming rules.

Example: Binding Existing Commands to Workloads

The new version also extends several CLI commands with workload awareness:

• purefs list --workload payments-file-prod
• purefs setattr --workload payments-file-prod ...
• purefs create --workload payments-file-prod --workload-configuration app-file-gold

This is handy when you need to:

• Troubleshoot or resize all file systems in a given workload.
• Script around logical workloads instead of individual file systems.

Why This Matters for You (Not Just for Slides)

Net impact of FB 4.6.7 + FA 6.10.4 from an Admin’s perspective:

1. File is now truly first‑class in Fusion, across both FlashArray and FlashBlade.
2. You can encode “how we do storage here” as code:
• Presets (JSON + GUI).
• Parameterization and naming rules.
• Placement and protection choices.
3. Dark sites get sane placement via “Get Recommendations” for file workloads, instead of best‑guess manual picks.
4. Resource naming is finally policy‑driven, not left to whoever is provisioning at 2 AM.
5. GUI, CLI, and API are aligned around the same abstractions, so you can:
• Prototype in the UI.
• Commit JSON to Git.
• Automate via CLI/API without re‑learning concepts.

Next Steps

If you want to kick the tires:

• Upgrade:
• FlashBlade to Purity//FB 4.6.7
• FlashArray to Purity//FA 6.10.4 
• Pick one or two high‑value patterns (e.g., “DB file services”, “analytics scratch”, “home directories”).
• Implement them as Fusion presets with:
• Parameters.
• Placement hints.
• Naming rules.
• Wire into your existing tooling:
• Use the GUI for ad‑hoc.
• Wrap purepreset / pureworkload in your pipelines for everything else.

You already know how to design good storage. These releases just make it a lot harder for your environment to drift away from that design the moment humans touch it.