Hi 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. > > Normally we tie data format changes to the machine type. How are > we going to achieve such machine type associations with an external > libslirp ? Is this relevant for slirp? I don't see any version tied to machine type. Am I missing something? thanks > > It seems to me that if a libslirp wants to change live migration > format, it will need to support both the old and new formats > indefinitely, and the new format must be an opt-in. QEMU can > then tell libslirp which migraiton format based on the machine > type. > > ok > > 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 :|
