> 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:
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.
> I'm not clear on what the behavior < v1.3.4 is before PARAM_PERSIST_ XML existed and when PERSIST_ DEST was specified by itself. I
> VIR_MIGRATE_
> VIR_MIGRATE_
> 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 @@ qemuMigrationRu n(virQEMUDriver Ptr driver, COOKIE_ NETWORK |
QEMU_ MIGRATION_ COOKIE_ STATS;
cookieFlags |= QEMU_MIGRATION_
+ if (flags & VIR_MIGRATE_ PERSIST_ DEST && persist_xml && epareDef( driver, persist_xml, NULL, NULL))) PERSIST_ DEST && okieAddPersiste nt(mig, vm->newDef) < 0)) || okieAddPersiste nt(mig,
qemuMigrati onBakeCookie( mig, driver, vm, cookieout,
cookieoutlen, cookieFlags) < 0)) {
VIR_WARN( "Unable to encode migration cookie");
+ !(def = qemuMigrationPr
+ ret = -1;
+
if (ret == 0 &&
(((flags & VIR_MIGRATE_
- qemuMigrationCo
+ qemuMigrationCo
+ def ? def : vm->newDef) < 0)) ||
}
The previous behaviour of calling qemuMigrationCo okieAddPersiste nt with vm->newDef (VIR_MIGRATE_ PARAM_DEST_ XML) when VIR_MIGRATE_ PERSIST_ DEST is provided can be seen above.