Date: Tue, 23 May 2023 20:26:27 +0300 From: Vitaliy Gusev <gusev.vitaliy@gmail.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: virtualization@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: BHYVE SNAPSHOT image format proposal Message-ID: <5544A8DA-4E91-4384-B72D-8C91B32B6D69@gmail.com> In-Reply-To: <202305231645.34NGj2Bq081239@critter.freebsd.dk> References: <67FDC8A8-86A6-4AE4-85F0-FF7BEF9F2F06@gmail.com> <202305231645.34NGj2Bq081239@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > On 23 May 2023, at 19:45, Poul-Henning Kamp <phk@phk.freebsd.dk> = wrote: >=20 >=20 >> 1. BHYVE SNAPSHOT image format: >=20 > Please do not invent Yet Another Format, please ? >=20 > Why not make it a tar(5) file ? >=20 Tar cannot solve issues mentioned in =E2=80=9Cdisadvantages=E2=80=9D. = Tar doesn=E2=80=99t have versions, it is just container for files that would introduce another level of indirection. Snapshot/resume = doesn=E2=80=99t need just container. It needs information what is saved and in what format. For example, virtual = memory can be saved in different ways: binary, diff pages, etc. Virtual memory of VM should be saved faster without additional cost. The = same for restore stage. Do you like an idea to have tar file with size 8 GB ? And how it can be saved = efficiently without double copying of data? Yes, tar is powerful and convenient for many purposes, but it is not so = suitable to suspend/resume process and would introduce just another level of complexity. =E2=80=94=E2=80=94 Vitaliy Gusev=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5544A8DA-4E91-4384-B72D-8C91B32B6D69>