When persistent migration of a transient domain is requested but no
custom XML is passed to the migration API we would just let the
destination daemon make a persistent definition from the live definition
itself. This is not a problem now, but once the destination daemon
starts replacing the original CPU definition with the one from migration
cookie before starting a domain, it would need to add more ugly hacks to
reverse the operation. Let's just always send the persistent definition
in the cookie to make things a bit cleaner.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
---

Notes:
    Version 2:
    - new patch (separated from the original 13/15)

 src/qemu/qemu_migration.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 2cd862875..40564ac63 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -3644,8 +3644,9 @@ qemuMigrationRun(virQEMUDriverPtr driver,
             if (!(persistDef = qemuMigrationPrepareDef(driver, persist_xml,
                                                        NULL, NULL)))
                 goto cleanup;
-        } else if (vm->newDef) {
-            if (!(persistDef = qemuDomainDefCopy(driver, vm->newDef,
+        } else {
+            virDomainDefPtr def = vm->newDef ? vm->newDef : vm->def;
+            if (!(persistDef = qemuDomainDefCopy(driver, def,
                                                  VIR_DOMAIN_XML_SECURE |
                                                  VIR_DOMAIN_XML_MIGRATABLE)))
                 goto cleanup;
-- 
2.13.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, Jun 07, 2017 at 10:37:42AM +0200, Jiri Denemark wrote:
> When persistent migration of a transient domain is requested but no
> custom XML is passed to the migration API we would just let the
> destination daemon make a persistent definition from the live definition
> itself. This is not a problem now, but once the destination daemon
> starts replacing the original CPU definition with the one from migration
> cookie before starting a domain, it would need to add more ugly hacks to
> reverse the operation. Let's just always send the persistent definition
> in the cookie to make things a bit cleaner.
> 
> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
> ---
> 
> Notes:
>     Version 2:
>     - new patch (separated from the original 13/15)
> 
>  src/qemu/qemu_migration.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, Jun 07, 2017 at 12:56:52 +0200, Pavel Hrdina wrote:
> On Wed, Jun 07, 2017 at 10:37:42AM +0200, Jiri Denemark wrote:
> > When persistent migration of a transient domain is requested but no
> > custom XML is passed to the migration API we would just let the
> > destination daemon make a persistent definition from the live definition
> > itself. This is not a problem now, but once the destination daemon
> > starts replacing the original CPU definition with the one from migration
> > cookie before starting a domain, it would need to add more ugly hacks to
> > reverse the operation. Let's just always send the persistent definition
> > in the cookie to make things a bit cleaner.
> > 
> > Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
> > ---
> > 
> > Notes:
> >     Version 2:
> >     - new patch (separated from the original 13/15)
> > 
> >  src/qemu/qemu_migration.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>

Thanks for the reviews and forcing me to overcome my laziness :-)

Jirka

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list