Re: BHYVE SNAPSHOT image format proposal

> On 25 May 2023, at 19:22, Mario Marietto <marietto2008@gmail.com> wrote:
> 
> 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. 


You should build kernel and tools, install it. Then you can run bhyve, bhyvectl to deal with suspend/resume.

Please follow 

 9.5. Building and Installing a Custom Kernel

https://docs.freebsd.org/en/books/handbook/book/#kernelconfig-building


Make sure that BHYVE_SNAPSHOT is enabled.

Also look at build(7):

https://man.freebsd.org/cgi/man.cgi?build(7)


> 
> On Thu, May 25, 2023 at 3:40 PM Vitaliy Gusev <gusev.vitaliy@gmail.com <mailto:gusev.vitaliy@gmail.com>> wrote:
>> 
>> 
>>> On 25 May 2023, at 04:30, Tomek CEDRO <tomek@cedro.info <mailto: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.