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