Is there a way to temporarily disable a storage device?

Is there a way to disable a storagedevice (backed by a ZFS dataset) on a LXD server? I need to take down a zfs pool for an extended period of time. And I get constantly error messages like ‘Failed mounting storage pool’.

It might be that i need to be take the containers in the pool online fast if need arises (suddenly). So I need to ensure taking the containers online is simple and fast.

Currently I simply ignore the error messages. Another option seems to be to remove and recreate the storage and recover the containers. Another way would be probably to configure the storage to a fake backend(?).

If there is currently no way to disable/enable storages, how to proceed implementing that feature?

There is currently no support for disabling a storage pool.

Whilst an unmountable storage pool does not prevent LXD start up normally, it will potentially prevent start up in the future if there is a storage patch that needs to be applied, as LXD will not start up fully until the patch has been applied.

You could consider removing the storage pool from the database using the lxd sql global 'delete from storage_pools where name = "<pool name>"' command and then using lxd recover to restore it later when needed.

But this would not be using LXD in the expected way.

2 Likes

Thanks a lot for this.

Would disabling a storage pool be a feature that would possibly be merged if we provide an implementation/PR? I am sure this won’t be a one-off for us.

I imagine, that storage pool patching would have to happen when re-enabling the pool. And that the storage would not be online in case that would fail for some reason (so the pool would stay disabled). Would you imagine more complexity than this?

My feature/bug request is pretty similar to what you require.

The ability to remove a storage pool without having LXD purge it.

1 Like

That would also be good. Its insofar different as one should be able to disable storage if no containers are currently running on it, but the container configuration should be left untouched. So when the storage gets enabled again, one can start the containers.

For deleting storage, the containers would be probably removed (beforehand?)

The ability to delete the storage connection in LXD (Without (!!) purging your underlying storage pool like ZFS or Ceph) would solve both of our problems I think.

Your instances/profiles could still have them configured, they would simply error when attempting to start them.

It’s basically the sql oneliner that @tomponline posted.