* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Mon, Feb 11, 2019 at 11:22:27PM +0100, Samuel Thibault wrote: > > Marc-André Lureau, le lun. 11 févr. 2019 12:34:47 +0100, a ecrit: > > > On Mon, Feb 11, 2019 at 12:09 PM Daniel P. Berrangé <berra...@redhat.com> > > > wrote: > > > > > > > > On Fri, Feb 08, 2019 at 07:12:26PM +0100, Marc-André Lureau wrote: > > > > > Once libslirp has received its first release, we can link with the > > > > > external libslirp library. > > > > > > > > > > The migration data should be compatible with current and older qemu > > > > > versions (same compatibility as today). See "slirp: add state > > > > > saving/loading" patch. However, the content should be treated as a > > > > > blob, as the format may change eventually in the future. > > > > > > > > How are we going to manage live migration compat if libslirp changes > > > > the blob content ? > > > > > > > > Bear in mind that we need to support all existing QEMU releases live > > > > migrating to effectively all future QEMU releases, with all future > > > > libslirp releases, in *both* directions. ie arbitrarily newer > > > > libslirp needs to be able to emit a blob format that can be read > > > > by arbitrarily older slirp inside QEMU. > > > > > > Right, this is all supported currently with the proposed patch set, > > > since it is effectively the same code. > > > > > > So register_savevm_live() get passed slirp_state_version() (currently == > > > 4) > > > > > > & slirp_state_load() get the version_id from QEMU. > > > > Mmm, but do we guarantee that the current version of slirp will be able > > to read blobs produced by future versions of slirp? > > > > Future extensions of the format would have to be so that the current > > version could discard their content without issues. > > > > Perhaps qemu should actually explicitly pass 4 to > > register_savevm_live(), for that function to only record that format > > (and thus get compatibility of course) and only bump to greater values > > when qemu is modified to make use of a functionality which requires > > extending the blob format, which then makes it unreadable by older qemu > > releases, but that is fine for qemu. > > If QEMU wants to make use of functionality that requires the new blob > format, it would have to restrict that based on machine type. That way > it can ensure full compatibility with old QEMU.
Library compatibility for migration blobs is messy; we've had the same problem with usbredir. It's very difficult to keep track of; for example lets say that libslirp gets used by 3 or 4 different projects, and the package maintainer for libslirp in your favorite distro updates it - it's not necessarily obvious to them that doing so could break qemu migration. The ideal way is to work in terms of features and not versions; so that a machine type can enable libslirp-feature-foo in the new machine type and only then will the migration contents change. Dave > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
