On Fri, Jan 25, 2013 at 05:16:46PM +0800, Wenchao Xia wrote:
于 2013-1-24 17:47, Stefan Hajnoczi 写道:
Case 3:
* What does "blank data" mean? Besides that the use case
makes sense.
Will remove the words.
* When discussing this use case in the past it was suggested that the
guest doesn't need to be paused during the LVM snapshot. Instead the
QEMU block layer might be able to queue I/O requests, allowing the
guest to run.
That is a good idea, but seems need more work(event, block layer...),
hope it can be added as an enchancement of this case. Now let the
dedicated storage software/hardware take the job by pausing for a while
(<200ms?)
Yes, allowing the guest to continue but queuing I/O will require extra
block layer work and maybe a QMP command. There is a also a risk: if
the snapshot takes too long to complete, the guest may notice that its
I/O request are taking a long time. It may decide that they have timed
out and report an error to the application or in the message logs.
In the beginning it's easier to pause the VM but let's keep queuing I/O
in mind so it can be added later, if necessary.
Yep, the code should leave a room for queuing.
I have updated the wiki, which added the step details of the cases
. Cases 3 are fixed, which have best performance in qemu management
type. But I am not sure if it is workable in theory to export base
data of an qcow2 image having internal snapshot, what do you think
of it?
Yes, it is theoretically possible to access snapshot data while the
guest is running.
Open the qcow2 read-only and use bdrv_snapshot_load_tmp() to activate
the snapshot without modifying the qcow2 file on disk. This is pretty
easy to implement today by adding options to qemu-nbd or the in-process
NBD server QMP commands.
Stefan