Re: [Qemu-devel] [PATCH 2/2] migration: send and check the devices between source and distination at the begining

[Dr. David Alan Gilbert]

* Li Zhijian (address@hidden) wrote:
> 
> 
> On 09/30/2016 05:58 PM, Dr. David Alan Gilbert wrote:
> > * Li Zhijian (address@hidden) 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 / address@hidden / Manchester, UK
> > 
> > 
> > .
> > 
> 
> -- 
> Best regards.
> Li Zhijian (8555)
> 
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK