Date: Tue, 28 Sep 2021 09:15:51 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Alan Somers <asomers@freebsd.org> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Mark Johnston <markj@freebsd.org>, David Chisnall <theraven@freebsd.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: Building ZFS disk images Message-ID: <202109281615.18SGFpkl075922@gndrsh.dnsmgr.net> In-Reply-To: <CAOtMX2hRxM9s9YTZ=nXtO6KdTug7yqRG9L7iTQMFpVT9YEATZQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. > > > > > > > > > > > > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202109281615.18SGFpkl075922>