Fixed Jail ID for ZFS -> need proper mgmt?

[Jamie Gritton]

On 09/04/12 02:55, Bjoern A. Zeeb wrote:
> Hi,
>
> I had been talking to someone about jail management and it turns out
> people are using jail jid=42 to always have a fixed jail ID. The
> reason as I understood is that ZFS datasets are associated by jail id
> for delegation? [I admit having no clue about the ZFS side]
>
> If this is true I feel it's a very bad idea as it makes restarting
> jails a lot harder in case they remain DYING for say a not fully
> closed TCP session.
>
> My memories are: jid are still unique and cannot be re-used, even if
> in DYING, names can be re-used and thus are not neccessarily unique.
> Jamie, can you confirm this?
>
> Seems we need to sort out one to two problems:
>
> 1) can we make sure that the jail management framework can address a
> ZFS dataset for delegation somehow and automatically do that as
> part of the startup?
>
> 2) in the case of (1) it should be possible to address jails by name
> as ZFS would be handled automatically and we would not need another
> unique identifier I guess?
> Otherwise I'd prefer for people to be able to delegate ZFS datasets
> to jail names (as well), as long as they are uniquely identifyable
> (i.e. there are no 17 jails running with a name of "filesever").
>
> Do we have documentation for the ZFS features in the man pages or
> elsewhere btw? If not we should add it.
>
> Does this make sense?
>
> /bz

It's true that a jail left in the DYING state can't be re-created
normally. But it can with the "-d" flag or the "allow.dying" parameter.
In that case, an existing but dying jail will be re-attached to and this
resurrected. So it can be gotten around, and would be a matter of
education. Or perhaps we could change the default behavior to silently
all re-creation of dying jails. Is there any harm in this? I.e. would
there be any difference noticeable to the user if a jail was created
with some old TCP connections attached to it?

- Jamie