Re: BHYVE SNAPSHOT image format proposal

The review you referenced requires multiple files for a snapshot, which I
think is a non-starter.

I was trying to ensure that the limitations described in the original
snapshot commit message are addressed appropriately - but maybe I've
mis-interpreted the message or that I don't fully understand the problem.

I don't want give unhelpful or contradictory suggestions to what you've
received in the past.

The best I can do at this point is defer to those who you have made these
agreements with.

On Friday, July 14, 2023, Matthew Grooms <mgrooms@shrew.net> wrote:

> On 7/14/23 13:08, Rob Wing wrote:
>
>>
>>
>> On Fri, Jul 14, 2023 at 9:40 AM Matthew Grooms <mgrooms@shrew.net
>> <mailto:mgrooms@shrew.net>> 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
>