From nobody Thu May 25 01:30:18 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRVqZ3QBxz4CRRv for ; Thu, 25 May 2023 01:30:34 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRVqX4b6Lz3srC for ; Thu, 25 May 2023 01:30:32 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=K34LfFlX; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::112b) smtp.mailfrom=tomek@cedro.info; dmarc=none Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-55db055b412so7220247b3.0 for ; Wed, 24 May 2023 18:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1684978231; x=1687570231; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=RUGK9CXZZGThSQNZt+5FalMrWwsvK+w2j4g94Ic1xao=; b=K34LfFlX9OrVdNkeY7CTCkX3afIIRd2RXPmiSXCyQkkIkVOdQpJRDpcSq7xqfWBL49 i7d4Gox9k0qsvEEw2t4IomU6DpqDRcQjH9N+7TSYcYhNHJxWwyGKKPM2tALoXUch+9YV wICw5/3tbf7d7vCtEgR+dngtAZ8TIuV9CLuw4FlzTHrIFdHHUJJQKNGXQdBSmFhR/o8e PH7xV1BIuN009ChXym54U0j8CtusATbSml32ttEfPYRr9YAfAa0PyEs4/97KDalanlO6 lfsvoZgFgCqOdH0Y4V6lSJJiXWc2w+4qrtcrOoWptYy33nCi0uzMw+WkNZntSgD5+M5e 1kEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684978231; x=1687570231; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RUGK9CXZZGThSQNZt+5FalMrWwsvK+w2j4g94Ic1xao=; b=DriMSCS7yBxGhJMrPDfx2whT/mLOyF6NAUFADZ4uIuE2SYAqp914PdBRIujTAaGu5U Rb2vAEP/Dmvx6+4qc5mz834qLp3Kve6KQOagSLFOTL96YVYM7UaADijK8A3cATm9iBsJ cN66k6XboPmSjqTTABnm5xRjby8jcAQ35Dn7B808I+S4DICYcR0tNv2n4R4/jqxvkHBq 9EjeAT4+HoNYnmfjMqmVpB8NyF7FUynbI1ua8+YGmzGBSH8Nogs4xIHCDovCdmRmaBP8 YTZ4JsAXcOmWM1qprEAKtlmHzjjEfZCh9/Rk/T9si1pDSM7rRZ6HYfW+uCIxyOVc4RPf lbXA== X-Gm-Message-State: AC+VfDwC/imq19SKxT6NooYYDNT4HDBDFKfS0PjUhKfNx52qGAOUv1Nv uvPeKx9UaCdhMdoN2WIqpjWoZw== X-Google-Smtp-Source: ACHHUZ7mT4Xm+4nD8ZWFyjfYPxJGyB7k9r4WaqOh1QJbQ88NJLa4oQGqSMyeZdYktXeJeJxzYvm2QA== X-Received: by 2002:a81:9b56:0:b0:55a:776e:95f3 with SMTP id s83-20020a819b56000000b0055a776e95f3mr997101ywg.25.1684978231218; Wed, 24 May 2023 18:30:31 -0700 (PDT) Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com. [209.85.128.178]) by smtp.gmail.com with ESMTPSA id g4-20020a0ddd04000000b00545a08184b1sm4124776ywe.65.2023.05.24.18.30.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 May 2023 18:30:30 -0700 (PDT) Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-55db055b412so7220137b3.0; Wed, 24 May 2023 18:30:30 -0700 (PDT) X-Received: by 2002:a0d:ea05:0:b0:561:9bcc:6c81 with SMTP id t5-20020a0dea05000000b005619bcc6c81mr1402634ywe.24.1684978230412; Wed, 24 May 2023 18:30:30 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> In-Reply-To: From: Tomek CEDRO Date: Thu, 25 May 2023 03:30:18 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: BHYVE SNAPSHOT image format proposal To: Vitaliy Gusev Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112b:from,209.85.128.178:received]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; DKIM_TRACE(0.00)[cedro.info:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[cedro.info]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4QRVqX4b6Lz3srC X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Wed, May 24, 2023 at 5:11=E2=80=AFPM Vitaliy Gusev wrote: > Protecting requires more efforts and it should be clearly defined: what i= s purpose. If > purpose is having checksum with 99.9% reliability, NVLIST HEADER can be w= iden > to have =E2=80=9Cchecksum=E2=80=9D 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 :-) > If purpose is having crypto verification - I believe sha256 program shoul= d 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 :-) > Small is not so perfect. As the first attempt snapshot code is good. But = if you want to get > values related to some specific device, for example, for NIC or HPET, you= cannot get it easily. Please > try :) > > Stream doesn=E2=80=99t have flexibility. It is good for well specified a= nd long long time discussed protocols > like XDR (NFS), when it has RFC and each position in the stream is descri= bed. Example: RFC1813. > > New format with NVLIST has flexibility and is fast enough. Note, ZFS uses= nvlist for keeping attributes > and more another things. Sorry, I was not really aware of that format!! This looks really solid :-) https://github.com/fudosecurity/nvlist https://man.freebsd.org/cgi/man.cgi?query=3Dnvlist > 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 > If you are talking about compatibility of a Image format - it should be c= ompatible in > both directions, at least for not so big format changes. > > If consider overall snapshot/resume compatibility - I believe forward co= mpatibility > is not case and target. Indeed, why do you need to resume an image creat= ed 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). > The most important thing - backward compatibility, i.e. when an image is = created > by an older version of a program, but should be resumed on a new one. > > This is target and and intention of this improvement. Thank you, this looks promising :-) Just another design stage idea to keep the formats forward and backward compatible at least for some time and/or have an option to skip unknown feature :-) > Yes, I know about another formats, like JSON or others. NVLIST is the mos= t > effective and suitable for the current purposes. Thank you I know that now :-) I have switched to bhyve recently and for my use I prefer it now over virtualbox :-) Thanks again Vitaliy and good luck with the updates :-) --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info