Date: Tue, 05 May 2020 08:44:30 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: John Baldwin <jhb@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r360648 - in head: lib/libvmmapi share/man/man5 share/mk sys/amd64/include sys/amd64/vmm sys/amd64/vmm/amd sys/amd64/vmm/intel sys/amd64/vmm/io sys/conf sys/modules/vmm tools/build/opti... Message-ID: <202005051544.045FiUHA049666@slippy.cwsent.com> In-Reply-To: <202005050002.04502576094544@repo.freebsd.org> References: <202005050002.04502576094544@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <202005050002.04502576094544@repo.freebsd.org>, John Baldwin writes: > Author: jhb > Date: Tue May 5 00:02:04 2020 > New Revision: 360648 > URL: https://svnweb.freebsd.org/changeset/base/360648 > > Log: > Initial support for bhyve save and restore. > > Save and restore (also known as suspend and resume) permits a snapshot > to be taken of a guest's state that can later be resumed. In the > current implementation, bhyve(8) creates a UNIX domain socket that is > used by bhyvectl(8) to send a request to save a snapshot (and > optionally exit after the snapshot has been taken). A snapshot > currently consists of two files: the first holds a copy of guest RAM, > and the second file holds other guest state such as vCPU register > values and device model state. > > To resume a guest, bhyve(8) must be started with a matching pair of > command line arguments to instantiate the same set of device models as > well as a pointer to the saved snapshot. > > While the current implementation is useful for several uses cases, it > has a few limitations. The file format for saving the guest state is > tied to the ABI of internal bhyve structures and is not > self-describing (in that it does not communicate the set of device > models present in the system). In addition, the state saved for some > device models closely matches the internal data structures which might > prove a challenge for compatibility of snapshot files across a range > of bhyve versions. The file format also does not currently support > versioning of individual chunks of state. As a result, the current > file format is not a fixed binary format and future revisions to save > and restore will break binary compatiblity of snapshot files. The > goal is to move to a more flexible format that adds versioning, > etc. and at that point to commit to providing a reasonable level of > compatibility. As a result, the current implementation is not enabled > by default. It can be enabled via the WITH_BHYVE_SNAPSHOT=yes option > for userland builds, and the kernel option BHYVE_SHAPSHOT. > > Submitted by: Mihai Tiganus, Flavius Anton, Darius Mihai > Submitted by: Elena Mihailescu, Mihai Carabas, Sergiu Weisz > Relnotes: yes > Sponsored by: University Politehnica of Bucharest > Sponsored by: Matthew Grooms (student scholarships) > Sponsored by: iXsystems > Differential Revision: https://reviews.freebsd.org/D19495 Could also be the basis of a vmotion-like function. And possibly a hot-failover facility like VMware has. Vmotion and hot-failover require shared disk but we could use ZFS snapshots instead. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202005051544.045FiUHA049666>