13/05/2026
"We snapped the volume. Now Solaris won't import the zpool. Fix it."
If you work with ZFS on SAN storage, this one will sound familiar.
Our customers love storage-level snapshots - and for good reason. They're instantaneous, space-efficient, and incredibly useful. Need a test environment that mirrors production? Snap. Need a quick backup before a risky upgrade? Snap. Need to hand a developer a full copy of the dataset without touching the source? Snap.
The speed and simplicity are addictive. Once teams discover they can create a point-in-time copy of a multi-terabyte volume in seconds, they start building workflows around it. CI/CD pipelines, disaster recovery drills, reporting clones - snapshots become infrastructure.
And then, inevitably, someone tries this:
1. Take a storage-array snapshot of a volume hosting a ZFS zpool
2. Map the snapshot to a host as a new LUN
3. Run `zpool import`
4. Get rejected
Why? Because ZFS identifies pools by GUID. The snapshot is a block-level copy of the original volume - which means the zpool inside it carries the exact same GUID as the one that's already imported and active on the production host.
Solaris sees two pools with identical GUIDs and says: no.
It's the right behavior from ZFS's perspective. Allowing two pools with the same identity to coexist would be dangerous - imagine the metadata collisions, the potential for silent corruption. ZFS is protecting you.
But the customer doesn't want a lecture on GUID uniqueness. They want their snapshot-based workflow to work.
— — —
This is a pattern we see constantly in storage interoperability: the storage array does exactly what it's supposed to do (create a perfect copy), the OS does exactly what it's supposed to do (reject a duplicate identity), and the customer is caught in the middle saying "I don't care whose fault it is, make it work."
The answer exists. There are flags, there are procedures, there are trade-offs to consider depending on whether the original pool is still active, whether you're importing on the same host or a different one, and whether you need read-write or read-only access.
But the real story isn't the solution - it's the question itself. It's a perfect example of what happens when storage-layer capabilities outpace the assumptions baked into operating system design. Our snapshots are so fast and easy that customers naturally try to use them in ways that ZFS was never designed to expect.
And that's exactly where our Interoperability team lives - in the gap between what the storage can do and what the OS will allow.
More on the actual solution in the next post. Stay tuned.
By Leon Kull, Infinidat, a Lenovo Company
Have you encountered a similar challenge? Let’s discuss
