Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts

[Anthony Liguori <anthony@codemonkey.ws>]

Juan Quintela wrote:
> Dor Laor <dlaor@redhat.com> wrote:
>   
> I will go further, and think that this kind of issues should be put into
> the 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