ZFS pool was previously in use from another system: MMP and multihost protection

You run zpool import tank and get:

cannot import 'tank': pool was previously in use from another system.
Last accessed by host2 (hostid=0x1a2b3c4d) at Wed Jul 22 03:12:44 2026
The pool can be imported, use 'zpool import -f' to import the pool.

Or, on a pool with multihost protection enabled, the harder version:

cannot import 'tank': pool is imported on host2 (hostid: 0x1a2b3c4d)

Both messages exist to stop one specific disaster: two hosts importing the same pool at the same time. ZFS has no distributed locking. If two systems write to the same vdevs concurrently, they allocate the same free blocks, overwrite each other’s metadata, and destroy the pool. Your job is to determine whether the fence is protecting you from a live peer, or blocking you on stale state.

The rule that outranks everything else on this page: do not run zpool import -f until you have positively confirmed the other host is not using the pool. A forced double-import is one of the few operator actions that can irreversibly destroy a healthy ZFS pool.

What this means

Every ZFS pool label records the hostid and timestamp of the last system that had the pool imported. On import, ZFS compares that recorded hostid against the local system’s hostid. If they differ, you get the “previously in use from another system” warning. This check is always on, regardless of pool properties.

The first message is advisory: “someone else had this pool last, and I cannot tell whether they finished with it.” It appears after an unclean shutdown (power loss, kernel panic, reset) because the pool was never exported, so the label still shows the old host as active. It also appears when you move disks between machines, or when the local hostid changed (OS reinstall, regenerated /etc/hostid, cloned VM image) even though it is the same physical machine.

The second message is stronger. When the pool property multihost=on is set, MMP (multi-mount protection) is active: the importing host writes a periodic heartbeat to every leaf vdev, and any other host attempting an import first performs an activity check, waiting to see whether those heartbeats are still landing. If MMP concludes the pool is active elsewhere, the import is refused even with -f. MMP exists for HA and shared-storage clusters where two nodes can physically see the same disks and a fencing mistake is a matter of when, not if.

Common causes

Quick checks

All read-only and safe.

# Show the full import refusal, including last host and timestamp
zpool import

# Show this machine's hostid (must be non-zero and unique per host)
cat /sys/module/spl/parameters/spl_hostid

# Show the hostid file contents if present
cat /etc/hostid | od -An -tx4

# Check whether multihost protection is enabled on the pool
# (run on the host where the pool is currently imported)
zpool get multihost tank

# Inspect MMP state on the host where the pool is imported
cat /proc/spl/kstat/zfs/tank/multihost

# Review administrative history on the owning host: imports, exports, property changes
zpool history tank | tail -20

# Check MMP-related module parameters
for p in zfs_multihost_interval zfs_multihost_fail_intervals \
         zfs_multihost_import_intervals zfs_multihost_history; do
  echo "$p: $(cat /sys/module/zfs/parameters/$p)"
done

What you are looking for:

• A spl_hostid of 0, or one that matches the hostid in the refusal message on the wrong machine, explains the whole incident. Cloned VM images and OS reinstalls without zgenhostid are the usual source.
• zfs_multihost_interval defaults to 1000 ms. zfs_multihost_import_intervals defaults to 20, so the MMP activity check during import waits at least 20 times the interval (about 20 seconds, plus random jitter) before concluding the pool is inactive. zfs_multihost_fail_intervals defaults to 10: if the owning host cannot land an MMP write for 10 intervals (about 10 seconds), it suspends the pool so the peer can take over safely.
• The /proc/spl/kstat/zfs/<pool>/multihost kstat only records history when zfs_multihost_history is set above 0 (default is 0). On the owning host it still shows current MMP state.

How to diagnose it

flowchart TD
  A[Import refused: previously in use] --> B{hostid in message = local hostid?}
  B -->|Yes| C[Stale label: unclean shutdown
or hostid changed]
  B -->|No| D{Is that host reachable?}
  D -->|Yes, alive| E{zpool list on that host:
pool imported?}
  D -->|No, dead or partitioned| F[Confirm it is really down:
console, BMC, storage fencing]
  E -->|Yes| G[Cleanly export on that host:
zpool export tank]
  E -->|No| H[Label is stale, safe to import]
  C --> H
  F -->|Confirmed down| H
  F -->|Cannot confirm| I[DO NOT force import
Fence the host first]
  G --> J[zpool import tank succeeds normally]
  H --> K[zpool import -f tank]

Work through it in order:

1. Read the full message. zpool import prints the hostname, hostid, and last-access timestamp recorded in the pool label. The timestamp tells you whether the pool was recently active (seconds ago: someone is using it now) or stale (before a known outage window).
2. Compare hostids. If the hostid in the message equals the local spl_hostid, the “other system” is you. The label is stale from an unclean shutdown, or your hostid changed. Check uptime, logs, and whether /etc/hostid was regenerated recently.
3. If it is a different host, contact it. SSH in and check zpool list and zpool status. If the pool is imported there and healthy, this host has no business importing it. Export cleanly from the owning side.
4. If the host is unreachable, prove it is down. A network partition is not a dead host. Check the BMC/IPMI, hypervisor console, or out-of-band management. If the host might still be alive and writing, fence it first: power it off via BMC or revoke its access at the SAN/fabric layer.
5. Only then import. Clean path: the label was stale and plain zpool import tank works. If the label still insists another host owns it, zpool import -f tank overrides the advisory check.

Metrics and signals to monitor

Fixes

Clean export on the owning host

The correct path whenever the original host is alive:

# On the host that currently owns the pool
zpool export tank

A clean export writes the label as “not in use”, and the next import on any host proceeds without warnings. If the export hangs, something on that host still holds the pool open: mounted datasets, an NFS or SMB share, a running VM or container using a zvol. Stop those first.

Forced import after verification

# DANGEROUS if the other host is still alive and has the pool imported.
# Only run after confirming the previous owner is down or fenced.
zpool import -f tank

-f overrides the advisory “previously in use” check. It does not override MMP: on a multihost=on pool, the import still runs the activity check and refuses if heartbeats are landing. Also note that zpool import -o multihost=off does not bypass MMP during the import itself; -o properties apply only after the import passes. If a forced import succeeds and the old host turns out to be alive with the pool open, both hosts write to the same vdevs. That is the pool-destroying scenario the fence exists to prevent.

Fixing a stale or duplicated hostid

If the root cause is a hostid problem:

# Generate and persist a unique hostid
zgenhostid

# Verify
cat /sys/module/spl/parameters/spl_hostid

Every host that might import a given pool must have a unique, non-zero hostid. Bake zgenhostid into image builds so cloned VMs do not share one. A cosmetic variant shows up as a “Mismatch between pool hostid and system hostid on imported pool” notice (ZFS-8000-EY) on pools already imported; it does not affect data integrity, but regenerating the hostid and toggling multihost off and on clears it.

Enabling MMP for shared-storage pools

If multiple hosts can physically see the disks (SAN LUNs, shared JBOD), enable multihost protection before an incident forces the lesson:

# Run on the host where the pool is imported
zpool set multihost=on tank

With multihost=on, the owning host heartbeats to each leaf vdev every zfs_multihost_interval ms. Two tradeoffs:

• Import takes longer. Every import waits at least zfs_multihost_import_intervals times the interval (default about 20 seconds) for the activity check. Plan failover RTO accordingly.
• Disk failures can suspend the pool. If MMP writes fail on all paths for zfs_multihost_fail_intervals intervals (default about 10 seconds), the owning host suspends the pool deliberately so the peer can take over. Setting zfs_multihost_fail_intervals=0 avoids the suspension but disables that safety guarantee.

The simultaneous-import race

MMP is not a perfect mutex. There is a documented race (OpenZFS issue #14886) where two nodes importing the same pool at the same instant can both pass the activity check, because MMP writes are not yet active during the import window. Cluster tooling should serialize imports: stagger standby imports with a node-dependent delay (for example, node ID times one second) rather than firing them simultaneously.

Stale cachefile on old versions

On OpenZFS 0.7.x, a stale pool cache file combined with -f could bypass MMP entirely and allow a double import (issue #6933, fixed in 0.8.0). If you still run 0.7.x on anything touching shared storage, upgrade.

Prevention

• Unique hostids everywhere. Run zgenhostid at provision time and verify /sys/module/spl/parameters/spl_hostid is non-zero on every host. Alert on hostid 0.
• Enable multihost=on on any pool visible to more than one host. The import delay is a small price for a fence that works even when the cluster manager is confused.
• Fence before failover. HA tooling should power off or storage-fence the old primary before importing on the standby, not merely stop responding to its heartbeats.
• Serialize cluster imports. Stagger import attempts across nodes to avoid the simultaneous-import race.
• Alert on pool import/export events in shared-storage environments. An import from an unexpected host is a fencing failure caught early.
• Handle SUSPENDED as a page. On a multihost pool, SUSPENDED usually means MMP writes are failing and the peer is about to (or already did) take over. Do not blindly resume on both sides.

How Netdata helps

• Pool state per pool, continuously. Netdata reads ZFS pool health from the same kstats behind /proc/spl/kstat/zfs/<pool>/state, so a SUSPENDED transition from an MMP failure shows up as an alert, not a surprise during the next failover.
• Event correlation. Correlating import/export events with reboots, cluster failover actions, and storage path errors on one timeline is what separates “stale label from a crash” from “live peer still owns the pool.”
• Post-import verification. After a forced import, watching pool latency and I/O confirms the pool came up clean rather than limping from an interrupted write stream.
• Both nodes side by side. In an HA pair, seeing both nodes’ storage, network, and reboot timelines together makes “is the other host actually down?” answerable in seconds instead of via guesswork over SSH.

Related guides

• ZFS ARC hit ratio low: cache misses, cold caches, and working sets that outgrew RAM
• ZFS zfs_arc_max: capping the ARC without starving read performance
• ZFS ARC and the OOM killer: applications killed while the cache will not shrink fast enough
• ZFS ARC shrinking below c_max: reading memory pressure before latency hits
• ZFS ARC using all memory: the Linux default that eats your RAM
• ZFS cannot destroy dataset is busy: clones, holds, and mounted filesystems
• ZFS capacity planning: runway estimation before the pool fills
• ZFS checksum errors (CKSUM): the definitive signal of silent corruption
• ZFS checksum errors on multiple devices: suspect RAM or the controller, not the disks
• ZFS deadman events: hung I/O and a stalled pool sync
• ZFS dedup memory exhaustion: when the DDT outgrows ARC and the pool crawls
• ZFS deleted files but no space freed: snapshots holding the blocks