Re: Building ZFS disk images

From: Alan Somers <asomers_at_freebsd.org>
Date: Tue, 28 Sep 2021 16:23:28 UTC
On Tue, Sep 28, 2021 at 10:15 AM Rodney W. Grimes
<freebsd-rwg@gndrsh.dnsmgr.net> wrote:
>
> > On Tue, Sep 28, 2021 at 9:48 AM Rodney W. Grimes
> > <freebsd-rwg@gndrsh.dnsmgr.net> wrote:
> > >
> > > > On Mon, Sep 27, 2021 at 1:54 PM Mark Johnston <markj@freebsd.org> wrote:
> > > > >
> > > > > On Thu, Aug 05, 2021 at 10:54:19AM -0500, Alan Somers wrote:
> > > > > > There's this:
> > > > > > https://openzfs.github.io/openzfs-docs/man/8/zpool-reguid.8.html .  I
> > > > > > haven't used it myself.
> > > > >
> > > > > Would it be useful to have an rc.d script that can run this, probably
> > > > > just on the root pool?  It could be configured to run only upon the
> > > > > first boot, like growfs already does.
> > > >
> > > > Absolutely!
> > >
> > > Ewwwwwwwwww!  :-)
> > >
> > > > >
> > > > > > On Thu, Aug 5, 2021, 9:29 AM David Chisnall <theraven@freebsd.org> wrote:
> > > > > >
> > > > > > > On 05/08/2021 13:53, Alan Somers wrote:
> > > > > > > > I don't know of any way to do it using the official release scripts
> > > > > > > > either. One problem is that every ZFS pool and file system is supposed
> > > > > > > > to have a unique GUID.  So any kind of ZFS release builder would need to
> > >                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > > > > re-guid the pool on first boot.
> > >
> > > Isnt the proper place to solve this lack of Unique UUID creation
> > > in the tool(s) that are creating the zfs pool in the first place.
> > >
> > > Fixing it "post boot" seems to be a far to late hack and doesnt
> > > fix any of the situations where one might import these pools
> > > between creation and first boot.
> >
> > No, because you might create a VM image once, then instantiate it
> > dozens or thousands of times.  The firstboot solution is great because
> > it lets you reuse the same image file.
>
> I would continue to argue that the place to fix this is in the
> "instantiate tool".  ESXI vmfs deals with this all the time
> when you clone a disk.  And again the "fix at boot" does not
> deal with the problem in that if I "instatiate" 10 copies of
> a zpool for VM's and then try to mount 2 of them at once on
> the host this problem rares it head.   Fix the problem as close
> to point of creation as possible for minimal issues in all
> operations for everyone.

But that requires ESXI, or whatever VM system you're using, to know
about ZFS and GPT, and to know to look for a zpool on the 3rd
partition, right?  That seems like a lot to ask, especially since the
logic would have to be duplicated for ESXI, vm-bhyve, OpenNebula, etc
etc.

>
> >
> > >
> > > > > > >
> > > > > > > Is there a tool / command to do this?  I've hit this problem in the
> > > > > > > past: I have multiple FreeBSD VMs that are all created from the same
> > > > > > > template and if one dies I can't import its zpool into another because
> > > > > > > they have the same UUID.
> > > > > > >
> > > > > > > It doesn't matter for modern deployments where the VM is stateless and
> > > > > > > reimaged periodically but it's annoying for classic deployments where I
> > > > > > > have things I care about on the VM.
> > > > > > >
> > > > > > > David
> > > >
> > > >
> > >
> > > --
> > > Rod Grimes                                                 rgrimes@freebsd.org
> >
>
> --
> Rod Grimes                                                 rgrimes@freebsd.org