qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd


From: Wenchao Xia
Subject: Re: [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd
Date: Mon, 22 Jul 2013 13:20:58 +0800
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7

Eric, I'd like to have a discuss about snapshot and vmbackup in
qemu/libvirt with management stack's perspective, what is your time
zone? I hope to ping you in IRC.

On 07/17/2013 08:03 AM, Wenchao Xia wrote:
This series allow user to read internal snapshot's contents without qemu-img
convert. Another purpose is that, when qemu is online and have taken an
internal snapshot, let user invoke qemu-nbd to do any thing on it except write.

This brings two interesting issues:
1 is it safe to let qemu-nbd and qemu access that file at same time?

Probably not, for the same reason we tell people to not use qemu-img
while qemu is active on a file.

I think it is safe, since qemu-nbd is read only. The data will be correct from
qemu-nbd, if qemu does not delete that snapshot when qemu-nbd is running, and
data is flushed to storage after qemu take that snapshot so that qemu-nbd
would see the correct data.

You're making assumptions that qemu won't be touching any metadata in a
manner in which the read-only qemu-nbd could get confused; I'm not sure
we are ready to make that guarantee.  I think the export has to be from
the running qemu process itself, rather than from a second process.


2 should an nbd-server exporting internal snapshot be added in qemu?
I think no. Compared with driver-backup, the snapshot, or COW happens
in storage level, so it allows another program to read it itself. Actually
it should be OK to let another server other than qemu's host, do the
export I/O job, if data is flushed.

Unfortunately, I disagree, and think the answer to this question is yes,
we need to do the export from within the single qemu process, if we want
to guarantee safety.


Next step:
As demonstrated before, an explict API should be added, which make sure
all I/O request is flushed and sent to underlining storage, and cache
is sync if it is writeback type. So at qemu level, we can make sure
no request is left behind, before qemu-nbd start. That API should
also benefit 3rd party block snapshot solution, such as LVM2.

More:
With this patch and previous qcow2 snapshot at block device level, I think
export/import/backup solution around qcow2, is nearly complete at qemu's
level. It can do similar things as backing chain but with better performance,
Some small optimization place are left:

1 compare two snapshot's data to get the diff with help of qcow2's L1/L2 table.
2 convertion between external snapshot and internal snapshot.

This series need following series applied first:
[PATCH V5 0/8] add internal snapshot support at block device level
http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg01831.html

Wenchao Xia (4):
   1 snapshot: distinguish id and name in load_tmp
   2 qemu-nbd: support internal snapshot export
   3 qemu-nbd: add doc for internal snapshot export
   4 qemu-iotests: add 057 internal snapshot export with qemu-nbd case

  block/qcow2-snapshot.c     |   16 +++++++-
  block/qcow2.h              |    5 ++-
  block/snapshot.c           |   37 ++++++++++++++++++-
  include/block/block_int.h  |    4 ++-
  include/block/snapshot.h   |    4 ++-
  qemu-img.c                 |    7 +++-
  qemu-nbd.c                 |   56 ++++++++++++++++++++++++++++-
  qemu-nbd.texi              |    3 ++
  tests/qemu-iotests/057     |   87 ++++++++++++++++++++++++++++++++++++++++++++
  tests/qemu-iotests/057.out |   26 +++++++++++++
  tests/qemu-iotests/group   |    1 +
  11 files changed, 237 insertions(+), 9 deletions(-)
  create mode 100755 tests/qemu-iotests/057
  create mode 100644 tests/qemu-iotests/057.out








--
Best Regards

Wenchao Xia




reply via email to

[Prev in Thread] Current Thread [Next in Thread]