| Message ID | 1483e0d74dcfd183ff46dd63cc57e1fe8b775bf8.1454680535.git.amit.shah@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 05/02/2016 14:56, Amit Shah wrote: > Commit 8304402033e8dbe8e379017d51ed1dd8344f1dce changed the name of the > e1000-82540em device to e1000. This was flagged: > > Section "e1000-82540em" does not exist in dest > > Add the mapping to the changed section names dictionary so the checker > can proceed. > > Signed-off-by: Amit Shah <amit.shah@redhat.com> > Acked-by: Jason Wang <jasowang@redhat.com> > Message-Id: <7ccfe834c897142dceaa4da87c13b7059fa12aa8.1450416947.git.amit.shah@redhat.com> > Signed-off-by: Amit Shah <amit.shah@redhat.com> > --- > scripts/vmstate-static-checker.py | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/scripts/vmstate-static-checker.py b/scripts/vmstate-static-checker.py > index b6c0bbe..b5ecaf6 100755 > --- a/scripts/vmstate-static-checker.py > +++ b/scripts/vmstate-static-checker.py > @@ -99,6 +99,7 @@ def get_changed_sec_name(sec): > # Section names can change -- see commit 292b1634 for an example. > changes = { > "ICH9 LPC": "ICH9-LPC", > + "e1000-82540em": "e1000", > } > > for item in changes: > This means that 2.5 cannot migrate 2.4 virtual machines, right? Is that something we want to rectify in 2.6 by making e1000-82540em an alias of e1000 (instead of the other way round)? Paolo
On (Thu) 11 Feb 2016 [14:04:06], Paolo Bonzini wrote: > > > On 05/02/2016 14:56, Amit Shah wrote: > > Commit 8304402033e8dbe8e379017d51ed1dd8344f1dce changed the name of the > > e1000-82540em device to e1000. This was flagged: > > > > Section "e1000-82540em" does not exist in dest > > > > Add the mapping to the changed section names dictionary so the checker > > can proceed. > > > > Signed-off-by: Amit Shah <amit.shah@redhat.com> > > Acked-by: Jason Wang <jasowang@redhat.com> > > Message-Id: <7ccfe834c897142dceaa4da87c13b7059fa12aa8.1450416947.git.amit.shah@redhat.com> > > Signed-off-by: Amit Shah <amit.shah@redhat.com> > > --- > > scripts/vmstate-static-checker.py | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/scripts/vmstate-static-checker.py b/scripts/vmstate-static-checker.py > > index b6c0bbe..b5ecaf6 100755 > > --- a/scripts/vmstate-static-checker.py > > +++ b/scripts/vmstate-static-checker.py > > @@ -99,6 +99,7 @@ def get_changed_sec_name(sec): > > # Section names can change -- see commit 292b1634 for an example. > > changes = { > > "ICH9 LPC": "ICH9-LPC", > > + "e1000-82540em": "e1000", > > } > > > > for item in changes: > > > > This means that 2.5 cannot migrate 2.4 virtual machines, right? Is that > something we want to rectify in 2.6 by making e1000-82540em an alias of > e1000 (instead of the other way round)? You're right; I misread it. With that commit (8304402033): 2.4 with e1000-82540em will not migrate to 2.5 with e1000-82540em. This is despite they're aliased (so the cmdline is backward compatible), but the migration device name actually changed. Of course, 2.5->2.4 will also not work. Since 2.4 emits 'e1000-82540em' as the device name in the migration stream, and 2.5 emits just 'e1000', we have two different names for the same device in two versions. To fix this, we'll need a hack on the dest side to allow e1000 and e1000-82540em in the migration stream for the device, and this can be done for 2.6 and 2.5.stable. Jason, can you attempt this? Amit
On 02/22/2016 08:39 PM, Amit Shah wrote: > On (Thu) 11 Feb 2016 [14:04:06], Paolo Bonzini wrote: >> >> On 05/02/2016 14:56, Amit Shah wrote: >>> Commit 8304402033e8dbe8e379017d51ed1dd8344f1dce changed the name of the >>> e1000-82540em device to e1000. This was flagged: >>> >>> Section "e1000-82540em" does not exist in dest >>> >>> Add the mapping to the changed section names dictionary so the checker >>> can proceed. >>> >>> Signed-off-by: Amit Shah <amit.shah@redhat.com> >>> Acked-by: Jason Wang <jasowang@redhat.com> >>> Message-Id: <7ccfe834c897142dceaa4da87c13b7059fa12aa8.1450416947.git.amit.shah@redhat.com> >>> Signed-off-by: Amit Shah <amit.shah@redhat.com> >>> --- >>> scripts/vmstate-static-checker.py | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/scripts/vmstate-static-checker.py b/scripts/vmstate-static-checker.py >>> index b6c0bbe..b5ecaf6 100755 >>> --- a/scripts/vmstate-static-checker.py >>> +++ b/scripts/vmstate-static-checker.py >>> @@ -99,6 +99,7 @@ def get_changed_sec_name(sec): >>> # Section names can change -- see commit 292b1634 for an example. >>> changes = { >>> "ICH9 LPC": "ICH9-LPC", >>> + "e1000-82540em": "e1000", >>> } >>> >>> for item in changes: >>> >> This means that 2.5 cannot migrate 2.4 virtual machines, right? Is that >> something we want to rectify in 2.6 by making e1000-82540em an alias of >> e1000 (instead of the other way round)? > You're right; I misread it. With that commit (8304402033): > > 2.4 with e1000-82540em will not migrate to 2.5 with e1000-82540em. > > This is despite they're aliased (so the cmdline is backward > compatible), but the migration device name actually changed. > > Of course, 2.5->2.4 will also not work. > > Since 2.4 emits 'e1000-82540em' as the device name in the migration > stream, and 2.5 emits just 'e1000', we have two different names for > the same device in two versions. > > To fix this, we'll need a hack on the dest side to allow e1000 and > e1000-82540em in the migration stream for the device, and this can be > done for 2.6 and 2.5.stable. > > Jason, can you attempt this? > > > Amit Sure, but just need to understand the "problem". If I understand this correctly, the issue only happen for JSON description at the end of migration stream, and it won't break migration in fact?
On (Tue) 23 Feb 2016 [15:02:58], Jason Wang wrote: > >> This means that 2.5 cannot migrate 2.4 virtual machines, right? Is that > >> something we want to rectify in 2.6 by making e1000-82540em an alias of > >> e1000 (instead of the other way round)? > > You're right; I misread it. With that commit (8304402033): > > > > 2.4 with e1000-82540em will not migrate to 2.5 with e1000-82540em. > > > > This is despite they're aliased (so the cmdline is backward > > compatible), but the migration device name actually changed. > > > > Of course, 2.5->2.4 will also not work. > > > > Since 2.4 emits 'e1000-82540em' as the device name in the migration > > stream, and 2.5 emits just 'e1000', we have two different names for > > the same device in two versions. > > > > To fix this, we'll need a hack on the dest side to allow e1000 and > > e1000-82540em in the migration stream for the device, and this can be > > done for 2.6 and 2.5.stable. > > > > Jason, can you attempt this? > > > Sure, but just need to understand the "problem". If I understand this > correctly, the issue only happen for JSON description at the end of > migration stream, and it won't break migration in fact? No, this does break migration. The stream contained 'e1000-82540em' as the section header for the device earlier. It now only has 'e1000'. So a newer qemu will only accept 'e1000', but not 'e1000-82540em' (from an older release). Amit
* Amit Shah (amit.shah@redhat.com) wrote: > On (Tue) 23 Feb 2016 [15:02:58], Jason Wang wrote: > > >> This means that 2.5 cannot migrate 2.4 virtual machines, right? Is that > > >> something we want to rectify in 2.6 by making e1000-82540em an alias of > > >> e1000 (instead of the other way round)? > > > You're right; I misread it. With that commit (8304402033): > > > > > > 2.4 with e1000-82540em will not migrate to 2.5 with e1000-82540em. > > > > > > This is despite they're aliased (so the cmdline is backward > > > compatible), but the migration device name actually changed. > > > > > > Of course, 2.5->2.4 will also not work. > > > > > > Since 2.4 emits 'e1000-82540em' as the device name in the migration > > > stream, and 2.5 emits just 'e1000', we have two different names for > > > the same device in two versions. > > > > > > To fix this, we'll need a hack on the dest side to allow e1000 and > > > e1000-82540em in the migration stream for the device, and this can be > > > done for 2.6 and 2.5.stable. > > > > > > Jason, can you attempt this? > > > > > Sure, but just need to understand the "problem". If I understand this > > correctly, the issue only happen for JSON description at the end of > > migration stream, and it won't break migration in fact? > > No, this does break migration. > > The stream contained 'e1000-82540em' as the section header for the > device earlier. It now only has 'e1000'. So a newer qemu will only > accept 'e1000', but not 'e1000-82540em' (from an older release). OK, so do we need to get this fixed for 2.6 - i.e. now. Dave > > Amit -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On 04/05/2016 09:32 PM, Dr. David Alan Gilbert wrote: > * Amit Shah (amit.shah@redhat.com) wrote: >> On (Tue) 23 Feb 2016 [15:02:58], Jason Wang wrote: >>>>> This means that 2.5 cannot migrate 2.4 virtual machines, right? Is that >>>>> something we want to rectify in 2.6 by making e1000-82540em an alias of >>>>> e1000 (instead of the other way round)? >>>> You're right; I misread it. With that commit (8304402033): >>>> >>>> 2.4 with e1000-82540em will not migrate to 2.5 with e1000-82540em. >>>> >>>> This is despite they're aliased (so the cmdline is backward >>>> compatible), but the migration device name actually changed. >>>> >>>> Of course, 2.5->2.4 will also not work. >>>> >>>> Since 2.4 emits 'e1000-82540em' as the device name in the migration >>>> stream, and 2.5 emits just 'e1000', we have two different names for >>>> the same device in two versions. >>>> >>>> To fix this, we'll need a hack on the dest side to allow e1000 and >>>> e1000-82540em in the migration stream for the device, and this can be >>>> done for 2.6 and 2.5.stable. >>>> >>>> Jason, can you attempt this? >>>> >>> Sure, but just need to understand the "problem". If I understand this >>> correctly, the issue only happen for JSON description at the end of >>> migration stream, and it won't break migration in fact? >> No, this does break migration. >> >> The stream contained 'e1000-82540em' as the section header for the >> device earlier. It now only has 'e1000'. So a newer qemu will only >> accept 'e1000', but not 'e1000-82540em' (from an older release). > OK, so do we need to get this fixed for 2.6 - i.e. now. > > Dave Sorry for the late response. Have a try with 2.4 -> 2.5 migration and it works. Looking at save_section_header(), it will save se->idstr which seems always be "e1000" even if e1000-82540em is used in cli, or is there anything I missed? > >> Amit > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On (Wed) 06 Apr 2016 [09:48:19], Jason Wang wrote: > > > On 04/05/2016 09:32 PM, Dr. David Alan Gilbert wrote: > > * Amit Shah (amit.shah@redhat.com) wrote: > >> On (Tue) 23 Feb 2016 [15:02:58], Jason Wang wrote: > >>>>> This means that 2.5 cannot migrate 2.4 virtual machines, right? Is that > >>>>> something we want to rectify in 2.6 by making e1000-82540em an alias of > >>>>> e1000 (instead of the other way round)? > >>>> You're right; I misread it. With that commit (8304402033): > >>>> > >>>> 2.4 with e1000-82540em will not migrate to 2.5 with e1000-82540em. > >>>> > >>>> This is despite they're aliased (so the cmdline is backward > >>>> compatible), but the migration device name actually changed. > >>>> > >>>> Of course, 2.5->2.4 will also not work. > >>>> > >>>> Since 2.4 emits 'e1000-82540em' as the device name in the migration > >>>> stream, and 2.5 emits just 'e1000', we have two different names for > >>>> the same device in two versions. > >>>> > >>>> To fix this, we'll need a hack on the dest side to allow e1000 and > >>>> e1000-82540em in the migration stream for the device, and this can be > >>>> done for 2.6 and 2.5.stable. > >>>> > >>>> Jason, can you attempt this? > >>>> > >>> Sure, but just need to understand the "problem". If I understand this > >>> correctly, the issue only happen for JSON description at the end of > >>> migration stream, and it won't break migration in fact? > >> No, this does break migration. > >> > >> The stream contained 'e1000-82540em' as the section header for the > >> device earlier. It now only has 'e1000'. So a newer qemu will only > >> accept 'e1000', but not 'e1000-82540em' (from an older release). > > OK, so do we need to get this fixed for 2.6 - i.e. now. > > > > Dave > > Sorry for the late response. > > Have a try with 2.4 -> 2.5 migration and it works. Looking at > save_section_header(), it will save se->idstr which seems always be > "e1000" even if e1000-82540em is used in cli, or is there anything I missed? OK, sorry for the wrong alarm. The VMStateDescription's 'name' field has remained the same; but the section name has changed, which is fine (that isn't transmitted over the wire). So my initial reading was correct - and the whitelist I added in 1483e0d74dcfd183ff46dd63cc57e1fe8b775bf8 is fine. So nothing needed for the migration stream. Thanks, Jason. Amit
On 04/06/2016 09:52 PM, Amit Shah wrote: > On (Wed) 06 Apr 2016 [09:48:19], Jason Wang wrote: >> >> On 04/05/2016 09:32 PM, Dr. David Alan Gilbert wrote: >>> * Amit Shah (amit.shah@redhat.com) wrote: >>>> On (Tue) 23 Feb 2016 [15:02:58], Jason Wang wrote: >>>>>>> This means that 2.5 cannot migrate 2.4 virtual machines, right? Is that >>>>>>> something we want to rectify in 2.6 by making e1000-82540em an alias of >>>>>>> e1000 (instead of the other way round)? >>>>>> You're right; I misread it. With that commit (8304402033): >>>>>> >>>>>> 2.4 with e1000-82540em will not migrate to 2.5 with e1000-82540em. >>>>>> >>>>>> This is despite they're aliased (so the cmdline is backward >>>>>> compatible), but the migration device name actually changed. >>>>>> >>>>>> Of course, 2.5->2.4 will also not work. >>>>>> >>>>>> Since 2.4 emits 'e1000-82540em' as the device name in the migration >>>>>> stream, and 2.5 emits just 'e1000', we have two different names for >>>>>> the same device in two versions. >>>>>> >>>>>> To fix this, we'll need a hack on the dest side to allow e1000 and >>>>>> e1000-82540em in the migration stream for the device, and this can be >>>>>> done for 2.6 and 2.5.stable. >>>>>> >>>>>> Jason, can you attempt this? >>>>>> >>>>> Sure, but just need to understand the "problem". If I understand this >>>>> correctly, the issue only happen for JSON description at the end of >>>>> migration stream, and it won't break migration in fact? >>>> No, this does break migration. >>>> >>>> The stream contained 'e1000-82540em' as the section header for the >>>> device earlier. It now only has 'e1000'. So a newer qemu will only >>>> accept 'e1000', but not 'e1000-82540em' (from an older release). >>> OK, so do we need to get this fixed for 2.6 - i.e. now. >>> >>> Dave >> Sorry for the late response. >> >> Have a try with 2.4 -> 2.5 migration and it works. Looking at >> save_section_header(), it will save se->idstr which seems always be >> "e1000" even if e1000-82540em is used in cli, or is there anything I missed? > OK, sorry for the wrong alarm. > > The VMStateDescription's 'name' field has remained the same; but the > section name has changed, which is fine (that isn't transmitted over > the wire). So my initial reading was correct - and the whitelist I > added in 1483e0d74dcfd183ff46dd63cc57e1fe8b775bf8 is fine. > > So nothing needed for the migration stream. > > Thanks, Jason. > > Amit > Thanks for the confirmation.
diff --git a/scripts/vmstate-static-checker.py b/scripts/vmstate-static-checker.py index b6c0bbe..b5ecaf6 100755 --- a/scripts/vmstate-static-checker.py +++ b/scripts/vmstate-static-checker.py @@ -99,6 +99,7 @@ def get_changed_sec_name(sec): # Section names can change -- see commit 292b1634 for an example. changes = { "ICH9 LPC": "ICH9-LPC", + "e1000-82540em": "e1000", } for item in changes: