On Wed, Nov 9, 2011 at 7:16 PM, Juan Quintela <quint...@redhat.com> wrote: > This series goes as RFC, because we need to arrive to a solution for > qcow2. In RHEL5/6 we have the equivalent of patch1 integrated to fix > this issue.
We need to solve this for all block drivers, not just qcow2. Josh: Have you ever tested live migration with rbd? Just want to check if there are any issues to be aware of. I asked on #ceph and it seems multiple initiators to a RADOS block device are allowed - this means Ceph doesn't impose an additional requirement beyond what were trying to solve for file systems here. Let me share the situation with QED. Opening the image file causes the L1 table to be loaded and reading the first cluster will also cache an L2 table. Furthermore, QED has a dirty bit in the file header to detect unclean shutdown. The dirty bit will be triggered if both source and destination machines have the image open for read-write access simultaneously. Because of this we either need to delay opening the image on the destination or we need to open the image in read-only mode on the destination and then reopen in the actual mode once the destination has flushed. I think the delayed open solution is cleanest but probably requires a final state during live migration where the source says, "I've transferred everything now, please prepare to take over". At that point the destination can open all block devices and if there is an error can still fail migration. Unfortunately doing this at the critical point during live migration means that there is a latency/timeout situation in case the destination has trouble opening block devices. We'd want to abort migration and continue running on the source but a large timeout means long down-time during failed migration. Thoughts? Stefan