> On 6 Jun 2019, at 16:31, Dr. David Alan Gilbert <dgilbert@xxxxxxxxxx> wrote: > >>> >>> So we still need to tie subsections to machine types; that way >>> you don't send them to old qemu's and there for you don't have the >>> problem of the qemu receiving something it doesn't know. >> >> I agree that if there is no way to skip a VMState subsection in the stream, then we must >> have a way to specify to source QEMU to prevent sending this subsection to destination… >> >> I would suggest though that instead of having a flag tied to machine-type, we will have a QMP command >> that can specify names of subsections we explicitly wish to be skipped sending to destination even if their .needed() method returns true. > > I don't like the thought of generically going behind the devices back; > it's pretty rare to have to do this, so adding a qmp command to tweak > properties that we've already got seems to make more sense to me. > >> This seems like a more explicit approach and doesn’t come with the down-side of forever not migrating this VMState subsection > Dave If I understand you correctly, this is what you propose: 1) Have a .post_load() method for VMState subsections that depend on kernel capability to fail migration in case capability do not exist. 2) For specific problematic VMState subsections, add property such that it’s .needed() method will return false in case the property is set to false (value is true by default). 3) Have a QMP command that allows dynamically changing the value of these properties. 4) Properties values are still tied to machine-type? I think not right? I instead propose the following: 1) Same as (1) above. 2) Add a MigrationParameter (and matching MigrationCapability) named “avoid_state” that specifies list of subsection names to avoid sending in migration even if their .needed() method will return false. i.e. We will modify migration/vmstate.c to not even call .needed() method of such subsection. I believe the second proposal have the following advantages: 1) Less error-prone: .needed() methods are written only once and don’t need to take into account additional properties when calculating if they are required or not. Just depend on guest state. 2) Generic: We don’t require additional patch to add a new property to support avoiding sending some subsection in case it doesn’t matter for some workload. As we have discovered only late after msr_smi_count was added (by me) at that point. Second approach allows avoid sending any subsection that is deemed not important to guest workload by migration admin. 3) Not tied to machine-type: Properties are usually tied to machine-type as they need to remain same forever for the lifetime of the guest. However, migration parameters are per-migration and are meant to be tweaked and changed. This allows a guest that used to run on old QEMU and moved to new QEMU to now have better state saved for it’s next future migrations. Currently we indeed have very rare cases like this ([git grep \"x-migrate | wc -l] product only 4 results…) but I’m not sure it’s not only because we haven’t analysed carefully the case of restored properties that it’s property depend on kernel capability. As a start thought, we can start by at least agreeing to implement (1) and consider the property VS MigrationParameter discussion for a later time. What do you think? -Liran
