[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] RFC: migration with temporary external snapshot design considerations



Hi, all.

  The result of "[RFC] live migration of VMs with internal snapshots"
discussion is that it is nice to have ability to migrate images with internal
snapshots while keeping intact their internal snaphot structure. Current qemu
drive mirror functionality drops this structure and it is possible to
workaround the issue with the help of taking extenal snapshot on source and
then blockcommiting it back on destination after migration.

  The technique of creating temporary external snapshot could be useful in
other cases too. For example in case of migration with disks on non cache
coherent shared filesystem AFAIU. Thus I want to consider (and in case it is
reasonable implement too) this functionality aside from migration with internal
snapshots task where we have another issue of moving snapshot metadata to
destination.

  The whole topic of design comes from the fact that blockcommit can fail. The
fail itself is not a problem as AFAIK commiting active image does not
invalidate it and can be restarted later. So the question is to when and how
handle it. This can happen on source when we rollback after unsuccessfull
migration or on destination as on finish phase in case of blockcommit fail
we can't fail the migration anymore. I see two options.

1. Leave this situation to the mgmt. Thus we need to expose the fact of
external snapshot in domain config and somehow signal that mgmt need to take
care of situation. Well the fact that we expose this technical snapshot to
upper level doubts the whole idea of making the workaround in libvirt itself.

2. Have some kind of background task in libvirt that will try to blockcomit
with some policy. Well again, we introduce a policy which is considered to
reside in mgmt and introduce background task which makes libvirt mgmt-like
too.

  In anyway we will need to take special care while we have uncommited
temporary snapshot. For example if we take internal snapshot at this
time then it will be in temporary snapshot and be melted away after
temporary snapshot is committed. Other block operations are probably
are be affected too in this or another way. We can disable such operations
for uncommited temporary snapshot. In case of mgmt managment this is job
of mgmt and in case of libvirt managment this should be done in libvirt.

  All that said I guess the first approach is not the way to go as it fails to
archive the goal - hide the details from mgmt layer. As to the second one I'd
be glad to hear opinions of the community.

 Nikolay


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]