Re: BHYVE SNAPSHOT image format proposal
- Reply: Vitaliy Gusev : "Re: BHYVE SNAPSHOT image format proposal"
- In reply to: Vitaliy Gusev : "Re: BHYVE SNAPSHOT image format proposal"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 25 May 2023 16:22:10 UTC
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.