Re: BHYVE SNAPSHOT image format proposal

> On 25 May 2023, at 04:30, Tomek CEDRO <tomek@cedro.info> wrote:
> 
> On Wed, May 24, 2023 at 5:11 PM Vitaliy Gusev wrote:
>> Protecting requires more efforts and it should be clearly defined: what is purpose. If
>> purpose is having checksum with 99.9% reliability, NVLIST HEADER can be widen
>> to have “checksum” key/value for a Section.
> 
> Well, this could be optional but useful to make sure snapshot did not
> break somehow for instance backup medium error or something like
> that.. even more maybe a way to fix it.. just a design stage idea :-

Yes, new format can have checksum of a Section data if implemented.

> 
> 
>> If purpose is having crypto verification - I believe sha256 program should be your choice.
> 
> My question was more specific to availability of that feature
> (integrity + repair) rather than specific format :-)
> 
> The use case here is having a virtual machine (it was VirtualBox) with
> a bare os installed, plus some common applications, that is snapshoted
> at some point in time, then experimented a lot, restored from
> snapshot, etc. I had a backup of such vm + snapshot backed up that got
> broken somehow. It would be nice to know that something is broken,
> what is broken, maybe a way to fix :-)


 “Integrity" is a very broad term. What checksum algorithm is fine enough?
 
For the instance,  ZFS has several options for checksum:

checksum=on|off|fletcher2|fletcher4|sha256|noparity|sha512|skein|edonr
       

Having checksum for a filesystem is strongly recommended. However, If consider image format,
it  doesn’t need to care about consistency in a file itself. As example (!)  - binary files in a system.
They don’t have checksum integrated, validation is done by another program  - pkg or another.


> 
> 
>> Why do you need modify snapshot image ? Could you describe more? Do you
>> modify current 3 snapshot files?
> 
> Analysis that require ram / nvram modification? Not sure if this is
> already possible, but may come handy for experimenting with uefi and
> maybe some OS (features) that will not run with unmodified nvram :-P


Sorry I don’t get, why do you need to modify snapshot image, but not directly vmem on the running
VM?

Another question, checksum and modifying image - two mutual exclusive things. 

> 
> 
>> If you are talking about compatibility of a Image format - it should be compatible in
>> both directions, at least for not so big format changes.
>> 
>> If consider overall snapshot/resume compatibility - I believe  forward compatibility
>> is not case and target. Indeed, why do you need  to resume an image created by
>> a higher version of a program?
> 
> This happens quite often. For instance there is a bug in application
> and I need to revert to (at least) one step older version. Then I am
> unable to work on a file that I just saved (or was autosaved for me).
> Firefox profile settings let be the first example. KiCAD file format
> is another example (sometimes I need to switch to a devel build to
> evade a nasty blocker bug then anyone else that uses a release is
> blocked for some months including me myself).

Any additional thing has a cost of development, testing and support. Current
Implementation doesn’t support compatibility at all. Having compatibility in both
directions can be hard.

For example, if some variable is removed in bhyve, backward compatibility is fine,
but forward compatibly is not possible unless that removed variable is being saved
into a snapshot image just for forward compatibility. And of course, it should be tested
and verified as worked.

Do you like that approach? I don’t think so. So I guess only backward compatibility
should be supported to make the snapshot code simple and robust.

Thanks,
Vitaliy Gusev