* Li Zhijian (lizhij...@cn.fujitsu.com) wrote: > > > On 09/30/2016 05:58 PM, Dr. David Alan Gilbert wrote: > > * Li Zhijian (lizhij...@cn.fujitsu.com) wrote: > > > > > > > > > On 09/30/2016 02:15 PM, Amit Shah wrote: > > > > Hi, > > > > > > > > On (Thu) 29 Sep 2016 [19:06:32], Li Zhijian wrote: > > > > > Priviously, if the source and distination have different devices, > > > > > source could goto > > > > > the status "paused (postmigrate)", and the distination will exit that > > > > > means no qemu > > > > > is alive. > > > > > > > > > > After this patch, at above case, source can dectect the some error > > > > > early from distination > > > > > and stop the migration, source keep in status "running". > > > > > > > > How would incoming migrations from previous versions work? > > > > > > You are right. we need to consider more. > > > > > > How about that: > > > we need to introduce a new section type(e.g: QEMU_VM_SECTION_DEVICE_LIST). > > > > > > source side: > > > - at the beginning of qemu_savevm_state_begin(), send > > > QEMU_VM_SECTION_DEVICE_LIST first > > > - original path > > > > > > dst side: > > > - if we got the QEMU_VM_SECTION_DEVICE_LIST, have a check with the > > > devices(name,version) > > > - otherwise original path > > > > Yes, and only send it on new machine types. > > I think a list could be a good idea; I don't worry too much about the > > 'paused (postmigrate)' > > case, because libvirt can spot that the destination failed and then restart > > the source, > Oh, that's what I didn't know before. Thank for your information. > > > > however a list would also fix the opposite case; where the destination has > > an extra device > > that the source does not have, in most cases I think that doesn't cause a > > failure at the moment > What's our expected behavior? I think in most cases(where the destination has > an extra device > that the source does not have), destination seems fine after migration. > > If we expect migration failure, it needs more check.
I think it's a check we could add that would detect more misconfigurations. (you'd have to be careful about devices that just didn't need to send any migration state; and make sure it didn't break existing migrations). > > but the device has an unusual state. > > > > A QEMU_VM_SECTION_DEVICE_LIST would work, but perhaps a subsection of > > vmstate_globalstate > > would work? > > Currently, the vmstate_globalstate was saved/restored at the migration > completion stage while I expect > the beginning of migration. Ah sorry, I was confused; it's vmstate_configuration (see migration/savevm.c) that's saved at the beginning. Dave > And i cook the V2, with a new section type called SECTION_HEADER, any comment > is welcomed. > > Thanks > > > > > Dave > > > > > > > > Please correct me. > > > > > > Thanks > > > Zhijian > > > > > > > > > > > > > > > Amit > > > > > > > > > > > > > > > > > > > > > > > -- > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > > > > > . > > > > -- > Best regards. > Li Zhijian (8555) > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
