qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH] target-ppc: Add @cpu_dt_id into migr


From: Alexander Graf
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH] target-ppc: Add @cpu_dt_id into migration stream
Date: Thu, 10 Apr 2014 14:10:17 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0


On 08.04.14 03:26, Alexey Kardashevskiy wrote:
On 03/28/2014 12:07 AM, Alexey Kardashevskiy wrote:
On 03/27/2014 11:57 PM, Peter Maydell wrote:
On 27 March 2014 12:49, Alexey Kardashevskiy <address@hidden> wrote:
On 03/27/2014 11:37 PM, Andreas Färber wrote:
Am 27.03.2014 03:41, schrieb Alexey Kardashevskiy:
This should prevent the destination guest from misbehaving when
the threads number is different in "-smp" command.
Sorry, I don't understand. When migrating, surely -smp needs to be the
same on source and destination, so how can they differ?

The idea is that "-smp" does not migrate and if we run source and
destination guests with different numbers in -smp, we end up with weird
machine
Yes, so don't do that. As I understand it:
  (1) if you don't run QEMU with the exact same command line
      and config at both ends then migration won't work
  (2) we don't guarantee to detect and cleanly fail if you
      don't do (1)

It would probably be nice if we did detect config mismatches,
Yep, we do not send the device tree (as libvirt does). Pure command line
matching won't work.

but that seems to me like a problem we should be addressing
more globally than just for one particular config item for
one particular target...

Ok. So. Let's assume I want to implement migration of "-smp" parameters.
What would be the correct way of doing this in terms of the current QOM
principles? Thanks.

You don't. The migration protocol doesn't migrate configuration. If you want to start to transfer VM configuration (which I'd be all in for), do it properly and transfer _all_ configuration.


Alex




reply via email to

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