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...

[Cy Schubert]

In message <202005050002.04502576094544 at 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 at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy at nwtime.org>    Web:  https://nwtime.org

	The need of the many outweighs the greed of the few.