* Gerd Hoffmann (kra...@redhat.com) wrote:
> Hi,
>
> > I think the first two patches are the most controversial;
> > they remove migration support for old version of virtio-net and
> > virtio-serial;
> > (for virtio-net versions prior to 0.11 and for virtio-serial prior to 0.13).
> > I'm working on the basis that migration has bit rotted enough so
> > that the streams aren't migration compatible for that long back
> > on upstream - but if anyone knows otherwise please shout.
>
> We've gone great lengths to avoid new versions by using subsections
> instead for *years*. So if we are going to cut live migration support
> from ancient versions now: Can we possibly remove the versioning
> altogether?
Short answer: no
Longer answer: I'm saying we can remove some compatibility from very
old versions, especially if we probably lost the compatibility anyway,
but we should stick to trying to maintain compatibility where possible.
I've just tested an upstream 0.12.5 migration and it doesn't work;
/opt/qemu-0.12/bin/qemu-system-x86_64 -cpu core2duo -M pc-0.12 --enable-kvm -m
1G /home/vms/f20-raw.raw -nographic
migrating to:
1.1.2, 1.2.2, 2.5.1
all fail with:
qemu: warning: error while loading state for instance 0x0 of device 'ram'
and I've not dug into why.
(Migration to 1.0.1 hangs instead).
Given that, there doesn't seem to be any point in trying to maintain
compatibility for loading a stream produced by 0.11 for example.
As you know, we do jump through hoops downstream to have one
very specific 0.12 derivative migrate to our current releases,
and yes this patch set means I'm going to have to do a bit more
work to make that keep happening in one corner of it.
Although if I'm lucky by then if I can get the rest of this
code to be using VMState then it'll be much easier to do
the 0.12 compatibility code.
Dave
> cheers,
> Gerd
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
