|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts |
Date: | Mon, 23 Nov 2009 07:09:51 -0600 |
User-agent: | Thunderbird 2.0.0.23 (X11/20090825) |
Juan Quintela wrote:
Dor Laor <address@hidden> wrote:I will go further, and think that this kind of issues should be put intothe machine type.
I agree.
If you start qemu with -M pc-0.10, it should save the state in a 0.10 compatible way (that don't happens at the moment, but it should work that way).
Yes, that's a very good point.
The solution here is simpler - Every guest visible change should translate into cmdline option. This is part of the machine type and in addition should be configurable. It's an issue we all should keep in the back of our heads and popup when a new capability/change are introduced.I think this creates again a exponential posibilities, when we are only interested in some small part of the combinations. Upstream: It only cares about what was is 0.10, 0.11 and 0.12, three combinations, not all possible combinations of all devices. Downstream: (we for instance) care about RHEL5.4 RHEL5.5 or similar, not all other possible combinations. Notice that this is important, we change devices constantly, but we need new machine types ... once each X months, i.e. they are much less.
Yes, I think this is an important point to keep things under control. Supporting all possible combinations of different git versions is going to be unrealistically difficult. However, making sure that we can reproduce the major versions would work well.
A test suite that ran in the guest and tried to fingerprint the machine would be pretty helpful. Dump the full config for each PCI device, where they sit in the device model, etc. Dump ACPI tables. For a subset of devices we support, query as much info as possible. Dump it all to a config file.
We could run it against 0.11, then when 0.12 rolls around, run it again in a guest with -M pc-0.11. A simple diff of the two config files would tell us whether we broke guest compatibility.
Which protocol should we use? You're smarter than me, please suggest one. wrt the above guest abi issue, we should write a qemu spec with clear definitions for devices, drivers, versions, etc. Looking forward interesting fruitful discussion,My idea here is that we need to have further use of machine descriptions, once that is done, we need something like a new property for qdev (version?). Once there, each device could do: - if version != last_version -> die (what it happens now) - do someting sensible, not use the "new" features not existing on that version - edit the savevm format in an easy way.
But this would only kick in when using pc-0.11 or something, right? Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |