Cansu

If you go the out-of-tree route, install it through the framework that rebuilds modules automatically on kernel updates rather than compiling it by hand.

A hand-built module works until the next kernel update, at which point the machine boots with no network and no obvious reason. That failure lands weeks later, when nobody connects it to the driver they installed, and it is a genuinely unpleasant hour.

What changes is the layer you are managing, and it is worth being clear about because the two tools are not the same kind of thing.

The community tool wrapped the init system's own lightweight container mechanism — a thin layer over something already on the box, which is why it was easy to add and easy to abandon.

The replacement is a full system container and virtual machine manager. It manages images, storage pools, networking, snapshots, profiles and limits, with its own command set and its own idea of where things live. That is more capability and a genuinely different tool, not a renamed one.

The practical consequence for migration: there is no in-place conversion. The container's contents move; the container itself does not. What you are moving is the filesystem and the configuration knowledge, and you are recreating the container around it.

The path that works, in order:

1. Write down what each environment actually is before touching anything: which packages, which services, which mounts from the host, which ports, which user and group ids. This is the part people skip and then rebuild by trial and error.
2. Copy the data out to a location outside the container — a dataset on the pool. Do this while the old system still runs.
3. Create the new container on the replacement manager from a clean image of the same distribution.
4. Reattach the data as a mount, rather than copying it inside. Keeping data outside the container is what makes the next migration a configuration exercise instead of this one again.
5. Reinstall the services and point them at the mounted data.

The user and group id mapping is the step that bites. A system container may map ids differently from the old tool, so files owned correctly before are owned by nobody afterwards. Check that first, on one small environment, before moving anything you care about.

There is a second thing that catches people with applications that keep a database: the database may store absolute paths.

If it does, moving the files and repointing the setting is not enough — every record still refers to the old path. Some applications handle this, some have a maintenance command to repair paths, and some require the storage location to be a stable mount point precisely so this never arises.

Which is the actual lesson for next time: give the application a mount point that will not change, and move the storage underneath it rather than changing the path the application sees. Then relocating the data is a host-level operation the application never notices.

That is why the deprecation exists in the first place — the old default was almost certainly a location the platform itself controls, and the new arrangement is asking you to own the path.

Four things have to be true, and they fail in this order:

1. The host has a working driver. The card being visible in a device list is not the same as a driver being loaded. Check that the kernel module is in use, and on platforms where the vendor driver is an optional install, that it is installed.

2. The device nodes are passed into the container. A container sees no hardware unless the runtime is told to give it some. This is a checkbox or a resource setting on most platforms, and on plain container runtimes it is an explicit device mapping.

3. The container has the userspace libraries. The kernel driver on the host is not enough — the application inside needs the matching userspace pieces, and their version has to be compatible with the host driver. This is the mismatch that produces "no device available" while everything looks correctly wired.

4. The application is configured to use it, and built with support for it. Many images have separate variants for hardware acceleration.

Most failures are step 3, and they present exactly like step 2.

One broader point for anybody assembling storage from what is to hand: this error is doing you a favour by appearing now.

The alternative version of this story is a pool that builds fine, runs for a year, and then behaves unpredictably during a disk replacement because the system cannot reliably tell two members apart. That failure happens at the worst possible moment and is much harder to reason about.

A storage system that refuses to start on ambiguous hardware is one that will also refuse to guess later.