On 2012-03-27 18:39, Anthony Liguori wrote: > On 03/27/2012 11:22 AM, Jan Kiszka wrote: >> On 2012-03-27 17:59, Avi Kivity wrote: >>> On 03/27/2012 11:55 AM, Jan Kiszka wrote: >>>> On 2012-03-27 10:55, Vasilis Liaskovitis wrote: >>>>> Hi, >>>>> >>>>> is live migration between qemu-kvm stable-0.15 and stable-1.0 trees possible? >>>>> When I live migrate a VM from 1.0 to 0.15, the destination side 0.15 qemu-kvm >>>>> exits with: >>>>> (qemu) Unknown savevm section or instance 'i8259' 0 >>>>> >>>>> That's expected, since commit "i8259:convert to qdev" 747c70af78f7088f182c87e683bdf847beead1e4 >>>>> introduces the i8259 device in the qdev tree. >>>>> >>>>> The other direction (live migrate from 0.15.1 to 1.0.0) seems to work fine. >>>>> Are any other issues expected in this direction? >>>>> >>>>> The vmstate for i8259 has not changed between these trees afaict. If the >>>>> qdev-ified i8259 is reverted from stable-1.0 tree (to restore live-migration >>>>> compatibility between the versions), would you expect problems? >>>> >>>> The legacy instance IDs used in old versions are not written out by >>>> newer ones. They are just accepted on reading to allow moving forward. >>>> There are more devices in the tree that used those instance IDs, not >>>> only the i8259. Reverting the qdev conversion may reactivate backward >>>> migratability for 1.0->0.15 (unless there are others as well). But that >>>> will definitely be over after 1.1 as inrevertible code depends on the >>>> qdev conversion. >>> >>> Is this true even for -M pc-0.15? >> >> Yes. Alias IDs enable modeling according to qdev (back then) for devices >> that wrote oddly numbered states in the past and porting them over to >> the new format. Adding some compat write-out mode would probably be >> feasible but would also require some thoughts and quite a bit work to >> integrate this cleanly in vmstate. >> >> I guess this just remained unnoticed because the introduction of the >> alias ID concept and first conversions happened at a time when lots of >> devices increased their vmstate version anyway. > > So, since we're approaching 1.1, we should really discuss release criteria for > 1.1 with respect to live migration. I'd prefer to avoid surprises in this release. > > My expectation is that migration works from: > > qemu-1.0 -M 1.0 => qemu-1.1 -M 1.1 > qemu-1.1 -M 1.0 <= qemu-1.1 -M 1.0 Besides the instance ID thing, I found two further blockers: - kvm-tpr-op (kvmvapic), easy to disable in non-1.1 machines - vmstate fix for i8254 which involved a version bump from 2 to 3. That is actually now compatible with qemu-kvm and should not cause troubles there. But it breaks the backward-migration scenario for QEMU. I have no good idea how to resolve this while pleasing all consumers we care about. Any suggestions? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
