From nobody Fri Jul 14 22:37:46 2023 X-Original-To: virtualization@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 4R2mZp4qbqz4nT5W for ; Fri, 14 Jul 2023 22:37:54 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4R2mZn4b2bz3xf6 for ; Fri, 14 Jul 2023 22:37:53 +0000 (UTC) (envelope-from mgrooms@shrew.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.131 as permitted sender) smtp.mailfrom=mgrooms@shrew.net; dmarc=none Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.15.2/8.15.2) with ESMTP id 36EMbqkG087396; Fri, 14 Jul 2023 17:37:52 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.32] (unknown [136.49.230.220]) by mail.shrew.net (Postfix) with ESMTPSA id 2BAF5194F0D; Fri, 14 Jul 2023 17:37:47 -0500 (CDT) Message-ID: <3973013d-c183-360f-d7ca-ca822859c23d@shrew.net> Date: Fri, 14 Jul 2023 17:37:46 -0500 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: BHYVE SNAPSHOT image format proposal Content-Language: en-US To: Rob Wing Cc: virtualization@freebsd.org References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <6b98da58a5bd8e83bc466efa20b5a900298210aa.camel@FreeBSD.org> <8387AC83-6667-48E5-A3FA-11475EA96A5F@gmail.com> <986A83D8-E0E0-4030-9369-A5B3500E27C6@gmail.com> <79fabe94-b800-c713-48ea-518da1f74e4d@shrew.net> From: Matthew Grooms In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.shrew.net [10.24.10.10]); Fri, 14 Jul 2023 17:37:52 -0500 (CDT) X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_LONG(-0.99)[-0.993]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[virtualization@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[shrew.net]; TAGGED_RCPT(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4R2mZn4b2bz3xf6 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 7/14/23 13:08, Rob Wing wrote: > > > On Fri, Jul 14, 2023 at 9:40 AM Matthew Grooms > wrote: > > > I see a need to define a format for bhyve so it's possible to mix > different sections and encodings inside a unified stream. But all the > data in your nvlist example above can be easily be represented as text. > We already have JSON, YAML, XML, etc ... By adopting an preexisting > format, we could retain the snapshot structure instead of lifting it up > into the stream format. Even if we decide to break the structure up > into > different nvlist stream sections, using a common format would allow > other tools to more easily parse and validate the structure inside > these > sections. Isn't that a good thing? Is there a reason we're trying to > reinvent the wheel here? > > > Does JSON support storing binary data? I'm under the impression that it > does not. Hi Rob, When we spoke to John Baldwin and others in the community about being able to remove the #ifdef's from the snapshot code, we were told that copying binary data structures to a state file was the wrong approach and that a better method needed to be provided. We agreed. That's why the following work was undertaken to provide a rich file format that describes the component values of device's state instead of codifying the c structure in the file format ... https://reviews.freebsd.org/D29262 When Vitaliy added comments to that review WRT an nvlist based approach, I assumed that meant preserving the decomposition of device information that the UPB team spent so much effort trying to extract. I should have read the original file format proposal email before I replied as I tried too hard to interpret it info through that lens. My mistake. If Vitaliy, and apparently you, favor the continued practice of copying data from c structure pointers directly into files to save device state, I have no more comments on that approach. Maybe John or UPB will chime in here with feedback that's more helpful. -Matthew