From nobody Tue Sep 28 16:15:51 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3B4A917E1368 for ; Tue, 28 Sep 2021 16:15:54 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HJl3s5dKGz3qFG; Tue, 28 Sep 2021 16:15:53 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 18SGFpjN075923; Tue, 28 Sep 2021 09:15:51 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 18SGFpkl075922; Tue, 28 Sep 2021 09:15:51 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202109281615.18SGFpkl075922@gndrsh.dnsmgr.net> Subject: Re: Building ZFS disk images In-Reply-To: To: Alan Somers Date: Tue, 28 Sep 2021 09:15:51 -0700 (PDT) CC: "Rodney W. Grimes" , Mark Johnston , David Chisnall , freebsd-current X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4HJl3s5dKGz3qFG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On Tue, Sep 28, 2021 at 9:48 AM Rodney W. Grimes > wrote: > > > > > On Mon, Sep 27, 2021 at 1:54 PM Mark Johnston 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 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