• E
    snapshot: prevent migration from stranding snapshot data · e2fb96d9
    Eric Blake 提交于
    Migration is another case of stranding metadata.  And since
    snapshot metadata is arbitrarily large, there's no way to
    shoehorn it into the migration cookie of migration v3.
    
    This patch consolidates two existing locations for migration
    validation into one helper function, then enhances that function
    to also do the new checks.  If we could always trust the source
    to validate migration, then the destination would not have to
    do anything; but since older servers that did not do checking
    can migrate to newer destinations, we have to repeat some of
    the same checks on the destination; meanwhile, we want to
    detect failures as soon as possible.  With migration v2, this
    means that validation will reject things at Prepare on the
    destination if the XML exposes the problem, otherwise at Perform
    on the source; with migration v3, this means that validation
    will reject things at Begin on the source, or if the source
    is old and the XML exposes the problem, then at Prepare on the
    destination.
    
    This patch is necessarily over-strict.  Once a later patch
    properly handles auto-cleanup of snapshot metadata on the
    death of a transient domain, then the only time we actually
    need snapshots to prevent migration is when using the
    --undefinesource flag on a persistent source domain.
    
    It is possible to recreate snapshot metadata on the destination
    with VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE and
    VIR_DOMAIN_SNAPSHOT_CREATE_CURRENT.  But for now, that is limited,
    since if we delete the snapshot metadata prior to migration,
    then we won't know the name of the current snapshot to pass
    along; and if we delete the snapshot metadata after migration
    and use the v3 migration cookie to pass along the name of the
    current snapshot, then we need a way to bypass the fact that
    this patch refuses migration with snapshot metadata present.
    
    So eventually, we may have to introduce migration protocol v4
    that allows feature negotiation and an arbitrary number of
    handshake exchanges, so as to pass as many rpc calls as needed
    to transfer all the snapshot xml hierarchy.
    
    But all of that is thoughts for the future; for now, the best
    course of action is to quit early, rather than get into a
    funky state of stale metadata; then relax restrictions later.
    
    * src/qemu/qemu_migration.h (qemuMigrationIsAllowed): Make static.
    * src/qemu/qemu_migration.c (qemuMigrationIsAllowed): Alter
    signature, and allow checks for both outgoing and incoming.
    (qemuMigrationBegin, qemuMigrationPrepareAny)
    (qemuMigrationPerformJob): Update callers.
    e2fb96d9
qemu_migration.c 96.2 KB