[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 (X11/20090825)

Juan Quintela wrote:
Dor Laor <address@hidden> 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
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
- edit the savevm format in an easy way.

But this would only kick in when using pc-0.11 or something, right?


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]