Date: Thu, 21 Oct 2021 23:22:32 -0700 From: Julian Elischer <julian@freebsd.org> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Alan Somers <asomers@freebsd.org> 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: <f218e84b-c485-7430-9ecf-257a45d0d014@freebsd.org> In-Reply-To: <202109281615.18SGFpkl075922@gndrsh.dnsmgr.net> References: <202109281615.18SGFpkl075922@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/28/21 9:15 AM, Rodney W. Grimes wrote: >> On Tue, Sep 28, 2021 at 9:48 AM Rodney W. Grimes >> <freebsd-rwg@gndrsh.dnsmgr.net> wrote: >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>> 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. Define a special magic "change to something else" ID that will always do the right thing exactly once.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f218e84b-c485-7430-9ecf-257a45d0d014>