| Message ID | 447a8e1d1d24ed89db081c9c912627335267bfbc.1361313340.git.crobinso@redhat.com |
|---|---|
| State | New |
| Headers | show |
20.02.2013 02:39, Cole Robinson wrote: > This switch will turn on all the migration compat bits needed to > perform migration from qemu-kvm to qemu. It's just a stub for now. > > This compat will break incoming migration from qemu < 1.3, but for > distros where qemu-kvm was the only shipped package for years it's > not a big loss (and I don't know any way to avoid it). Actually I think it is relatively easy to support migration from BOTH qemu and qemu-kvm. By adding a _runtime_ command-line switch (such as --qemu-kvm-compat, which has been already mentioned in other context), which modifies that migration stuff (machine definitions) in a reasonable way. It can be done based on this patchset I guess (when it will be polished and proven to work well). And after that is done, this configure option can go away. How do you guys think? Thanks! /mjt
On 02/20/2013 03:30 AM, Michael Tokarev wrote: > 20.02.2013 02:39, Cole Robinson wrote: >> This switch will turn on all the migration compat bits needed to >> perform migration from qemu-kvm to qemu. It's just a stub for now. >> >> This compat will break incoming migration from qemu < 1.3, but for >> distros where qemu-kvm was the only shipped package for years it's >> not a big loss (and I don't know any way to avoid it). > > Actually I think it is relatively easy to support migration from BOTH > qemu and qemu-kvm. By adding a _runtime_ command-line switch (such as > --qemu-kvm-compat, which has been already mentioned in other context), > which modifies that migration stuff (machine definitions) in a reasonable > way. It can be done based on this patchset I guess (when it will be > polished and proven to work well). And after that is done, this > configure option can go away. > > How do you guys think? > That solution works for me too. Thanks, Cole
Il 20/02/2013 18:48, Cole Robinson ha scritto: > > Actually I think it is relatively easy to support migration from BOTH > > qemu and qemu-kvm. By adding a _runtime_ command-line switch (such as > > --qemu-kvm-compat, which has been already mentioned in other context), > > which modifies that migration stuff (machine definitions) in a reasonable > > way. It can be done based on this patchset I guess (when it will be > > polished and proven to work well). And after that is done, this > > configure option can go away. > > > > How do you guys think? > > That solution works for me too. The configure option needs to remain for distros that need it for backwards compatibility. Adding support for migration from both can be done on top. Paolo
On 02/20/2013 01:13 PM, Paolo Bonzini wrote: > Il 20/02/2013 18:48, Cole Robinson ha scritto: >>> Actually I think it is relatively easy to support migration from BOTH >>> qemu and qemu-kvm. By adding a _runtime_ command-line switch (such as >>> --qemu-kvm-compat, which has been already mentioned in other context), >>> which modifies that migration stuff (machine definitions) in a reasonable >>> way. It can be done based on this patchset I guess (when it will be >>> polished and proven to work well). And after that is done, this >>> configure option can go away. >>> >>> How do you guys think? >> >> That solution works for me too. > > The configure option needs to remain for distros that need it for > backwards compatibility. Adding support for migration from both can be > done on top. > Ah, true, I wasn't thinking about it fully. I figured having qemu-kvm be a wrapper script that passed -qemu-kvm-compat would cover us, but in Fedora 18 even qemu-system-x86_64 uses the qemu-kvm migration format, so we will always want the configure option. - Cole
Cole Robinson <crobinso@redhat.com> writes: > This switch will turn on all the migration compat bits needed to > perform migration from qemu-kvm to qemu. It's just a stub for now. > > This compat will break incoming migration from qemu < 1.3, but for > distros where qemu-kvm was the only shipped package for years it's > not a big loss (and I don't know any way to avoid it). > > Signed-off-by: Cole Robinson <crobinso@redhat.com> This can't be a build time option. It's ugly and just reintroduces a fork. I assume the issue with making it a run time option is that libvirt would need to be updated? Why can't qemu-kvm be a script wrapper that passes a fixed flag? Regards, Anthony Liguori > --- > configure | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/configure b/configure > index bf5970f..296f488 100755 > --- a/configure > +++ b/configure > @@ -170,6 +170,7 @@ xfs="" > > vhost_net="no" > kvm="no" > +migrate_from_kvm="no" > gprof="no" > debug_tcg="no" > debug="no" > @@ -759,6 +760,8 @@ for opt do > ;; > --enable-kvm) kvm="yes" > ;; > + --enable-migration-from-qemu-kvm) migrate_from_kvm="yes" > + ;; > --disable-tcg-interpreter) tcg_interpreter="no" > ;; > --enable-tcg-interpreter) tcg_interpreter="yes" > @@ -1087,6 +1090,9 @@ echo " --enable-bluez enable bluez stack connectivity" > echo " --disable-slirp disable SLIRP userspace network connectivity" > echo " --disable-kvm disable KVM acceleration support" > echo " --enable-kvm enable KVM acceleration support" > +echo " --enable-migration-from-qemu-kvm Allow migration from qemu-kvm." > +echo " This will break migration from " > +echo " qemu < 1.3 in most cases" > echo " --enable-tcg-interpreter enable TCG with bytecode interpreter (TCI)" > echo " --disable-nptl disable usermode NPTL support" > echo " --enable-nptl enable usermode NPTL support" > @@ -3334,6 +3340,7 @@ echo "Linux AIO support $linux_aio" > echo "ATTR/XATTR support $attr" > echo "Install blobs $blobs" > echo "KVM support $kvm" > +echo "Migrate from qemu-kvm $migrate_from_kvm" > echo "TCG interpreter $tcg_interpreter" > echo "fdt support $fdt" > echo "preadv support $preadv" > @@ -3622,6 +3629,9 @@ fi > if test "$signalfd" = "yes" ; then > echo "CONFIG_SIGNALFD=y" >> $config_host_mak > fi > +if test "$migrate_from_kvm" = "yes"; then > + echo "CONFIG_MIGRATE_FROM_QEMU_KVM=y" >> $config_host_mak > +fi > if test "$tcg_interpreter" = "yes" ; then > echo "CONFIG_TCG_INTERPRETER=y" >> $config_host_mak > fi > -- > 1.8.1.2
Il 20/02/2013 21:26, Anthony Liguori ha scritto: > Cole Robinson <crobinso@redhat.com> writes: > >> This switch will turn on all the migration compat bits needed to >> perform migration from qemu-kvm to qemu. It's just a stub for now. >> >> This compat will break incoming migration from qemu < 1.3, but for >> distros where qemu-kvm was the only shipped package for years it's >> not a big loss (and I don't know any way to avoid it). >> >> Signed-off-by: Cole Robinson <crobinso@redhat.com> > > This can't be a build time option. It's ugly and just reintroduces a fork. It is not a fork; it does not change the migration format of QEMU itself, only the parsing of old VMState versions. The importance of the fork will dwindle over time, as the distros EOL the releases that used qemu-kvm. > I assume the issue with making it a run time option is that libvirt > would need to be updated? You cannot update libvirt, because whether to pass the flag or not depends on the _source_ QEMU, which may be an ancient version we cannot add any patch to. > Why can't qemu-kvm be a script wrapper that > passes a fixed flag? See Cole's answer; qemu-system-* also used to be built from qemu-kvm sources in Fedora. Paolo
On 02/20/2013 03:26 PM, Anthony Liguori wrote: > Cole Robinson <crobinso@redhat.com> writes: > >> This switch will turn on all the migration compat bits needed to >> perform migration from qemu-kvm to qemu. It's just a stub for now. >> >> This compat will break incoming migration from qemu < 1.3, but for >> distros where qemu-kvm was the only shipped package for years it's >> not a big loss (and I don't know any way to avoid it). >> >> Signed-off-by: Cole Robinson <crobinso@redhat.com> > > This can't be a build time option. It's ugly and just reintroduces a fork. > > I assume the issue with making it a run time option is that libvirt > would need to be updated? Why can't qemu-kvm be a script wrapper that > passes a fixed flag? > Fedora 18 ships only qemu-kvm-1.2. From that it builds qemu-kvm (with accel=kvm default) and qemu-system-x86_64 (with accel=tcg default). Both still have the migration incompatibility issues compared to plain qemu 1.2, like cirrus mem=16MB. So even if there was a cli option like -qemu-kvm-compat, in Fedora we would want to enable it even for both qemu-kvm and qemu-system-x86_64. Maybe add an option -qemu-kvm-compat=on|off, default to off, but add a configure option to set default=on? We would set default=on in Fedora, but users can still manually turn it off. - Cole > Regards, > > Anthony Liguori > >> --- >> configure | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/configure b/configure >> index bf5970f..296f488 100755 >> --- a/configure >> +++ b/configure >> @@ -170,6 +170,7 @@ xfs="" >> >> vhost_net="no" >> kvm="no" >> +migrate_from_kvm="no" >> gprof="no" >> debug_tcg="no" >> debug="no" >> @@ -759,6 +760,8 @@ for opt do >> ;; >> --enable-kvm) kvm="yes" >> ;; >> + --enable-migration-from-qemu-kvm) migrate_from_kvm="yes" >> + ;; >> --disable-tcg-interpreter) tcg_interpreter="no" >> ;; >> --enable-tcg-interpreter) tcg_interpreter="yes" >> @@ -1087,6 +1090,9 @@ echo " --enable-bluez enable bluez stack connectivity" >> echo " --disable-slirp disable SLIRP userspace network connectivity" >> echo " --disable-kvm disable KVM acceleration support" >> echo " --enable-kvm enable KVM acceleration support" >> +echo " --enable-migration-from-qemu-kvm Allow migration from qemu-kvm." >> +echo " This will break migration from " >> +echo " qemu < 1.3 in most cases" >> echo " --enable-tcg-interpreter enable TCG with bytecode interpreter (TCI)" >> echo " --disable-nptl disable usermode NPTL support" >> echo " --enable-nptl enable usermode NPTL support" >> @@ -3334,6 +3340,7 @@ echo "Linux AIO support $linux_aio" >> echo "ATTR/XATTR support $attr" >> echo "Install blobs $blobs" >> echo "KVM support $kvm" >> +echo "Migrate from qemu-kvm $migrate_from_kvm" >> echo "TCG interpreter $tcg_interpreter" >> echo "fdt support $fdt" >> echo "preadv support $preadv" >> @@ -3622,6 +3629,9 @@ fi >> if test "$signalfd" = "yes" ; then >> echo "CONFIG_SIGNALFD=y" >> $config_host_mak >> fi >> +if test "$migrate_from_kvm" = "yes"; then >> + echo "CONFIG_MIGRATE_FROM_QEMU_KVM=y" >> $config_host_mak >> +fi >> if test "$tcg_interpreter" = "yes" ; then >> echo "CONFIG_TCG_INTERPRETER=y" >> $config_host_mak >> fi >> -- >> 1.8.1.2
Paolo Bonzini <pbonzini@redhat.com> writes: > Il 20/02/2013 21:26, Anthony Liguori ha scritto: >> Cole Robinson <crobinso@redhat.com> writes: >> >>> This switch will turn on all the migration compat bits needed to >>> perform migration from qemu-kvm to qemu. It's just a stub for now. >>> >>> This compat will break incoming migration from qemu < 1.3, but for >>> distros where qemu-kvm was the only shipped package for years it's >>> not a big loss (and I don't know any way to avoid it). >>> >>> Signed-off-by: Cole Robinson <crobinso@redhat.com> >> >> This can't be a build time option. It's ugly and just reintroduces a fork. > > It is not a fork; it does not change the migration format of QEMU > itself, only the parsing of old VMState versions. The importance of the > fork will dwindle over time, as the distros EOL the releases that used > qemu-kvm. Once a distro enables CONFIG_QEMU_KVM, it must keep it enabled forever. So the distros will contineut o do CONFIG_QEMU_KVM whereas upstream does not set it. It's a fork all within the same tree. >> I assume the issue with making it a run time option is that libvirt >> would need to be updated? > > You cannot update libvirt, because whether to pass the flag or not > depends on the _source_ QEMU, which may be an ancient version we cannot > add any patch to. > >> Why can't qemu-kvm be a script wrapper that >> passes a fixed flag? > > See Cole's answer; qemu-system-* also used to be built from qemu-kvm > sources in Fedora. What about having something processed by readconfig that wasn't disabled by -nodefaults? Then we could make it a runtime option, but that's configurable globally. Then the distros can choose the default value in the config file. At least then, we can write unit tests with the option at run time, don't need to sprinkle #ifdefs everywhere, etc. Regards, Anthony Liguori > > Paolo
Il 20/02/2013 22:03, Anthony Liguori ha scritto: > Paolo Bonzini <pbonzini@redhat.com> writes: > >> Il 20/02/2013 21:26, Anthony Liguori ha scritto: >>> Cole Robinson <crobinso@redhat.com> writes: >>> >>>> This switch will turn on all the migration compat bits needed to >>>> perform migration from qemu-kvm to qemu. It's just a stub for now. >>>> >>>> This compat will break incoming migration from qemu < 1.3, but for >>>> distros where qemu-kvm was the only shipped package for years it's >>>> not a big loss (and I don't know any way to avoid it). >>>> >>>> Signed-off-by: Cole Robinson <crobinso@redhat.com> >>> >>> This can't be a build time option. It's ugly and just reintroduces a fork. >> >> It is not a fork; it does not change the migration format of QEMU >> itself, only the parsing of old VMState versions. The importance of the >> fork will dwindle over time, as the distros EOL the releases that used >> qemu-kvm. > > Once a distro enables CONFIG_QEMU_KVM, it must keep it enabled forever. > So the distros will contineut o do CONFIG_QEMU_KVM whereas upstream does > not set it. It's a fork all within the same tree. They will set it for a while. For example, F18 is the last Fedora release that had qemu-kvm < 1.3.0. As soon as F18 goes end-of-life (which is with F21), Fedora will not need to set the configure option anymore. Of course other distros will keep it for years rather than months, but the idea is the same. > What about having something processed by readconfig that wasn't disabled > by -nodefaults? Then we could make it a runtime option, but that's > configurable globally. Then the distros can choose the default value in > the config file. > > At least then, we can write unit tests with the option at run time, > don't need to sprinkle #ifdefs everywhere, etc. That would make sense, but it shouldn't block this patch. What would happen otherwise is that distros (who care about migration compatibility) will just patch their code without even the #ifdefs. It's already happening, these patches are in F18. Paolo
Il 21/02/2013 08:44, Paolo Bonzini ha scritto: > Il 20/02/2013 22:03, Anthony Liguori ha scritto: >> Paolo Bonzini <pbonzini@redhat.com> writes: >> >>> Il 20/02/2013 21:26, Anthony Liguori ha scritto: >>>> Cole Robinson <crobinso@redhat.com> writes: >>>> >>>>> This switch will turn on all the migration compat bits needed to >>>>> perform migration from qemu-kvm to qemu. It's just a stub for now. >>>>> >>>>> This compat will break incoming migration from qemu < 1.3, but for >>>>> distros where qemu-kvm was the only shipped package for years it's >>>>> not a big loss (and I don't know any way to avoid it). >>>>> >>>>> Signed-off-by: Cole Robinson <crobinso@redhat.com> >>>> >>>> This can't be a build time option. It's ugly and just reintroduces a fork. >>> >>> It is not a fork; it does not change the migration format of QEMU >>> itself, only the parsing of old VMState versions. The importance of the >>> fork will dwindle over time, as the distros EOL the releases that used >>> qemu-kvm. >> >> Once a distro enables CONFIG_QEMU_KVM, it must keep it enabled forever. >> So the distros will contineut o do CONFIG_QEMU_KVM whereas upstream does >> not set it. It's a fork all within the same tree. > > They will set it for a while. For example, F18 is the last Fedora > release that had qemu-kvm < 1.3.0. As soon as F18 goes end-of-life > (which is with F21), Fedora will not need to set the configure option > anymore. > > Of course other distros will keep it for years rather than months, but > the idea is the same. > >> What about having something processed by readconfig that wasn't disabled >> by -nodefaults? Then we could make it a runtime option, but that's >> configurable globally. Then the distros can choose the default value in >> the config file. >> >> At least then, we can write unit tests with the option at run time, >> don't need to sprinkle #ifdefs everywhere, etc. > > That would make sense, but it shouldn't block this patch. What would > happen otherwise is that distros (who care about migration > compatibility) will just patch their code without even the #ifdefs. > It's already happening, these patches are in F18. Ping, where do we stand here? Shall we discuss it next Tuesday? Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > Il 21/02/2013 08:44, Paolo Bonzini ha scritto: >> Il 20/02/2013 22:03, Anthony Liguori ha scritto: >>> Paolo Bonzini <pbonzini@redhat.com> writes: >>> >>>> Il 20/02/2013 21:26, Anthony Liguori ha scritto: >>>>> Cole Robinson <crobinso@redhat.com> writes: >>>>> >>>>>> This switch will turn on all the migration compat bits needed to >>>>>> perform migration from qemu-kvm to qemu. It's just a stub for now. >>>>>> >>>>>> This compat will break incoming migration from qemu < 1.3, but for >>>>>> distros where qemu-kvm was the only shipped package for years it's >>>>>> not a big loss (and I don't know any way to avoid it). >>>>>> >>>>>> Signed-off-by: Cole Robinson <crobinso@redhat.com> >>>>> >>>>> This can't be a build time option. It's ugly and just reintroduces a fork. >>>> >>>> It is not a fork; it does not change the migration format of QEMU >>>> itself, only the parsing of old VMState versions. The importance of the >>>> fork will dwindle over time, as the distros EOL the releases that used >>>> qemu-kvm. >>> >>> Once a distro enables CONFIG_QEMU_KVM, it must keep it enabled forever. >>> So the distros will contineut o do CONFIG_QEMU_KVM whereas upstream does >>> not set it. It's a fork all within the same tree. >> >> They will set it for a while. For example, F18 is the last Fedora >> release that had qemu-kvm < 1.3.0. As soon as F18 goes end-of-life >> (which is with F21), Fedora will not need to set the configure option >> anymore. >> >> Of course other distros will keep it for years rather than months, but >> the idea is the same. >> >>> What about having something processed by readconfig that wasn't disabled >>> by -nodefaults? Then we could make it a runtime option, but that's >>> configurable globally. Then the distros can choose the default value in >>> the config file. >>> >>> At least then, we can write unit tests with the option at run time, >>> don't need to sprinkle #ifdefs everywhere, etc. >> >> That would make sense, but it shouldn't block this patch. What would >> happen otherwise is that distros (who care about migration >> compatibility) will just patch their code without even the #ifdefs. >> It's already happening, these patches are in F18. > > Ping, where do we stand here? Shall we discuss it next Tuesday? My only requirement for this patch series is that it *also* be made to be dynamically configurable. This should be toggable with a command line option and the default can be set by configure. At least that makes it testable with make check. Regards, Anthony Liguori > > Paolo
Il 28/02/2013 14:06, Anthony Liguori ha scritto: >>> >> >>> >> That would make sense, but it shouldn't block this patch. What would >>> >> happen otherwise is that distros (who care about migration >>> >> compatibility) will just patch their code without even the #ifdefs. >>> >> It's already happening, these patches are in F18. >> > >> > Ping, where do we stand here? Shall we discuss it next Tuesday? > My only requirement for this patch series is that it *also* be made to > be dynamically configurable. This should be toggable with a command > line option and the default can be set by configure. > > At least that makes it testable with make check. Can you remind me what migration tests we have in make check? Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > Il 28/02/2013 14:06, Anthony Liguori ha scritto: >>>> >> >>>> >> That would make sense, but it shouldn't block this patch. What would >>>> >> happen otherwise is that distros (who care about migration >>>> >> compatibility) will just patch their code without even the #ifdefs. >>>> >> It's already happening, these patches are in F18. >>> > >>> > Ping, where do we stand here? Shall we discuss it next Tuesday? >> My only requirement for this patch series is that it *also* be made to >> be dynamically configurable. This should be toggable with a command >> line option and the default can be set by configure. >> >> At least that makes it testable with make check. > > Can you remind me what migration tests we have in make check? I've got fingerprinting tests in qemu-test that dumps all of the details of PCI devices. If this is a run time switch, I can add fingerprints for qemu-kvm pretty trivially. I'd like to add migration tests soon too. This series doesn't just do migration stuff. It changes the meaning of pc-XXX. Regards, Anthony Liguori > > Paolo
Il 28/02/2013 14:22, Anthony Liguori ha scritto: >>> >> At least that makes it testable with make check. >> > >> > Can you remind me what migration tests we have in make check? > I've got fingerprinting tests in qemu-test that dumps all of the details > of PCI devices. If this is a run time switch, I can add fingerprints > for qemu-kvm pretty trivially. That's a good point. (BTW, funny how we were both thinking of qemu-test, not "make check". But the misunderstanding made my question sound a bit snarky. Sorry). Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > Il 28/02/2013 14:22, Anthony Liguori ha scritto: >>>> >> At least that makes it testable with make check. >>> > >>> > Can you remind me what migration tests we have in make check? >> I've got fingerprinting tests in qemu-test that dumps all of the details >> of PCI devices. If this is a run time switch, I can add fingerprints >> for qemu-kvm pretty trivially. > > That's a good point. (BTW, funny how we were both thinking of > qemu-test, not "make check". But the misunderstanding made my question > sound a bit snarky. Sorry). No problem :-) I really do want to add migration tests too but my queue is a bit too large right now. Regards, Anthony Liguori > > Paolo
diff --git a/configure b/configure index bf5970f..296f488 100755 --- a/configure +++ b/configure @@ -170,6 +170,7 @@ xfs="" vhost_net="no" kvm="no" +migrate_from_kvm="no" gprof="no" debug_tcg="no" debug="no" @@ -759,6 +760,8 @@ for opt do ;; --enable-kvm) kvm="yes" ;; + --enable-migration-from-qemu-kvm) migrate_from_kvm="yes" + ;; --disable-tcg-interpreter) tcg_interpreter="no" ;; --enable-tcg-interpreter) tcg_interpreter="yes" @@ -1087,6 +1090,9 @@ echo " --enable-bluez enable bluez stack connectivity" echo " --disable-slirp disable SLIRP userspace network connectivity" echo " --disable-kvm disable KVM acceleration support" echo " --enable-kvm enable KVM acceleration support" +echo " --enable-migration-from-qemu-kvm Allow migration from qemu-kvm." +echo " This will break migration from " +echo " qemu < 1.3 in most cases" echo " --enable-tcg-interpreter enable TCG with bytecode interpreter (TCI)" echo " --disable-nptl disable usermode NPTL support" echo " --enable-nptl enable usermode NPTL support" @@ -3334,6 +3340,7 @@ echo "Linux AIO support $linux_aio" echo "ATTR/XATTR support $attr" echo "Install blobs $blobs" echo "KVM support $kvm" +echo "Migrate from qemu-kvm $migrate_from_kvm" echo "TCG interpreter $tcg_interpreter" echo "fdt support $fdt" echo "preadv support $preadv" @@ -3622,6 +3629,9 @@ fi if test "$signalfd" = "yes" ; then echo "CONFIG_SIGNALFD=y" >> $config_host_mak fi +if test "$migrate_from_kvm" = "yes"; then + echo "CONFIG_MIGRATE_FROM_QEMU_KVM=y" >> $config_host_mak +fi if test "$tcg_interpreter" = "yes" ; then echo "CONFIG_TCG_INTERPRETER=y" >> $config_host_mak fi
This switch will turn on all the migration compat bits needed to perform migration from qemu-kvm to qemu. It's just a stub for now. This compat will break incoming migration from qemu < 1.3, but for distros where qemu-kvm was the only shipped package for years it's not a big loss (and I don't know any way to avoid it). Signed-off-by: Cole Robinson <crobinso@redhat.com> --- configure | 10 ++++++++++ 1 file changed, 10 insertions(+)