Comment 43 for bug 1890501

> I'm not clear on what the behavior < v1.3.4 is before
> VIR_MIGRATE_PARAM_PERSIST_XML existed and when
> VIR_MIGRATE_PERSIST_DEST was specified by itself. I
> tried to look at the patch where it was introduced [1]
> and I don't see how/why it wouldn't have the
> vulnerability of exposing other tenant's data upon
> soft reboot. Am I misunderstanding this? If I'm not
> misunderstanding, does that mean there's no way to fix
> this problem for libvirt < v1.3.4?

AFAIK < v1.3.4 this isn't an issue when VIR_MIGRATE_PERSIST_DEST is provided as VIR_MIGRATE_PARAM_DEST_XML is used as the persistent domain on the destination.

I'm not sure how this will look in launchpad but I believe the following part of the VIR_MIGRATE_PARAM_PERSIST_XML patch you referenced covers the previous behaviour:

@@ -4566,14 +4568,20 @@ qemuMigrationRun(virQEMUDriverPtr driver,
     cookieFlags |= QEMU_MIGRATION_COOKIE_NETWORK |
                    QEMU_MIGRATION_COOKIE_STATS;

+ if (flags & VIR_MIGRATE_PERSIST_DEST && persist_xml &&
+ !(def = qemuMigrationPrepareDef(driver, persist_xml, NULL, NULL)))
+ ret = -1;
+
     if (ret == 0 &&
         (((flags & VIR_MIGRATE_PERSIST_DEST &&
- qemuMigrationCookieAddPersistent(mig, vm->newDef) < 0)) ||
+ qemuMigrationCookieAddPersistent(mig,
+ def ? def : vm->newDef) < 0)) ||
           qemuMigrationBakeCookie(mig, driver, vm, cookieout,
                                   cookieoutlen, cookieFlags) < 0)) {
         VIR_WARN("Unable to encode migration cookie");
     }

The previous behaviour of calling qemuMigrationCookieAddPersistent with vm->newDef (VIR_MIGRATE_PARAM_DEST_XML) when VIR_MIGRATE_PERSIST_DEST is provided can be seen above.