From nobody Fri Oct 22 06:22:32 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 C448817F2F53
	for <freebsd-current@mlmmj.nyi.freebsd.org>; Fri, 22 Oct 2021 06:22:39 +0000 (UTC)
	(envelope-from julian@freebsd.org)
Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4HbDmH4Mmkz4nh9;
	Fri, 22 Oct 2021 06:22:39 +0000 (UTC)
	(envelope-from julian@freebsd.org)
Received: from [192.168.0.12] (c-73-92-38-73.hsd1.ca.comcast.net [73.92.38.73])
	(authenticated bits=0)
	by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id 19M6MbsX061867
	(version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
	Thu, 21 Oct 2021 23:22:38 -0700 (PDT)
	(envelope-from julian@freebsd.org)
Message-ID: <f218e84b-c485-7430-9ecf-257a45d0d014@freebsd.org>
Date: Thu, 21 Oct 2021 23:22:32 -0700
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.2.0
Subject: Re: Building ZFS disk images
Content-Language: en-US
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>
References: <202109281615.18SGFpkl075922@gndrsh.dnsmgr.net>
From: Julian Elischer <julian@freebsd.org>
In-Reply-To: <202109281615.18SGFpkl075922@gndrsh.dnsmgr.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4HbDmH4Mmkz4nh9
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Spamd-Result: default: False [0.00 / 15.00];
	 ASN(0.00)[asn:36236, ipnet:204.109.60.0/22, country:US];
	 local_wl_from(0.00)[freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

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.