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

[Li Zhijian]

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.


> 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.

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)