On 04/11/2014 12:41 AM, Alexander Graf wrote: > > On 10.04.2014, at 16:35, Alexey Kardashevskiy <a...@ozlabs.ru> wrote: > >> On 04/10/2014 10:10 PM, Alexander Graf wrote: >>> >>> 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 <a...@ozlabs.ru> 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. >> >> >> Then what is the purpose of many, many VMSTATE_.*_EQUAL? > > Probably legacy from old vmstate layouts.
So this should not be used from now on? >> And I do not want to send configuration by the proposed patch, I want to >> make sure that the new guest is able to continue. Why exactly is this bad? > > It's not bad, but we should solve this properly, not one field at a time. -- Alexey