Am 04.01.2012 23:40, schrieb Stefan Hajnoczi: > The qcow2 implementation never accesses snapshots directly. Instead > there's the concept of the current L1 table, which means there is a > single global state of the disk. Snapshots are immutable and are > never accessed directly, only copied into the current L1 table. The > single global state makes it a little tricky to access a snapshot > while the VM is running. > > That said, the file format itself doesn't prevent an implementation > from supporting read-only access to snapshots. In theory we can > extend the qcow2 implementation to support this behavior.
And I think in practice we should. I've been meaning to do something like this for too long, but as you know everyone is focussed on external snapshots, so the internal ones don't get the attention they would deserve. > What you want sounds almost like an NBD server that can be > launched/stopped while qemu is already running a VM. This could be a > QEMU monitor command like: > nbd-start tcp::1234 virtio-disk0 --snapshot 20120104 I like this idea. :-) > It would be possible to stop the server using the same <socket, drive, > snapshot> tuple. Note the server needs to provide read-only access, > allowing writes probably has little use and people will hose their > data. > > Paolo: I haven't looked at the new and improved NBD server yet. Does > this sound doable? > > Kevin: I think we need something like qcow2_snapshot_load_tmp() but it > returns a full new BlockDriverState. The hard thing is that duping a > read-only snapshot qcow2 state leads to sharing and lifecycle problems > - what if we want to close the original BlockDriverState, will the > read-only snapshot state prevent this? Yes, creating new read-only BlockDriverStates from one image is exactly the thought that I had when reading this thread. The problem is that the BlockDriverStates wouldn't be fully independent. What if you delete the snapshot that is used by another BlockDriverState etc.? I think the least you would need is to have a separation between one BlockImage (which is a whole qcow2 file) and multiple BlockDriverStates (which is the backend that devices/NBD servers/whatever use). Not sure if such a fundamental block layer change is worth the effort. On the other hand, if Anthony is serious about QOM we'll get a fundamental design change anyway at some point... Kevin
