Re: BHYVE SNAPSHOT image format proposal

Vitaliy,

what happens if I clone your repo as source code on my FreeBSD system. Can
I test your code directly or not ? Anyway,I think that,before doing this,I
need to follow some kind of tutorial,to understand how the workflow is.
Otherwise I will be not able to test and stress it.

On Thu, May 25, 2023 at 3:40 PM Vitaliy Gusev <gusev.vitaliy@gmail.com>
wrote:

>
>
> 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
>
>
>

-- 
Mario.