qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts
Date: Mon, 23 Nov 2009 07:01:38 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

Juan Quintela wrote:
Gleb Natapov <address@hidden> wrote:
On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
Paolo Bonzini wrote:
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older version
doesn't know about? Do you just ignore it?
I'd go with chunk instead of feature bits, specifying them like in
the PNG specification:
You mean, each device would have multiple sections?  We already use
chunks for each device state.

Each device can send device info in multiple formats (each format with
its own ID) and destination will choose the one it supports.

RAM anyone?  You send 1GB of info in different formats, just in case :)

In this case, I think that the only two realistic solutions are to
increase negotiation during migration:

- source -> target: I can save this devices with this versions:
   "cpu" 10 - 12
   "apic" 3
   "ide" 2-4
   "virtio-net" 5-10
   ....
- target -> source:
   * I don't support "virtio-net" at all -> failed migration
   * send it as:
      "cpu" 11
      "apic" 3
      "ide" 2
      "virtio-net" 10
     thankyou very much :)

I'm not at all convinced that you can downgrade the version of a device without exposing a functional change to a guest. In fact, I'm pretty certain that it's provably impossible. Please give a counter example of where this mechanism would be safe.

Having subversions for downstream is a different problem that needs to
be fixed.

Yup. However, I believe the problem is addresses is really what's driving this discussion of optional features.

Regards,

Anthony Liguori

Later, Juan.





reply via email to

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