On 11/02/2012 09:00 AM, Kuniyasu Suzaki wrote: >> You are not the first to request this - libvirt would also like the >> ability to have read-only access into the contents of an internal >> snapshot while the rest of qemu continues to write into the image. > > Do you mean that libvirt can change the access mode of internal > harddisk from read-write to read-only?
No. I meant that reading an internal snapshot (a read-only operation) while still using the rest of the qcow2 file read-write for live operation would be a nice feature. The very nature of the qcow2 file format means that you cannot have two writers at the same time; the best you can do is expose the snapshots as a read-only backing file of yet another qcow2 file if you want a second writer based on the state of the snapshot without interfering with the first writer. > Please tell me how to change the mode by libvirt. Libvirt can't support reading of internal snapshots until qemu supports it. In other words, it's a feature no one has written yet, but which several people want. > > Does the qemu which has read-only access only, use another COW file? > Nested COWs sound interested, but the inter COW must be read-only, I think. Correct - any reading of internal snapshots must be read-only - you are required to use external backing files before you can have multiple writers sharing a common backing file. > >>> 2. Use Paolo's runtime NBD server to export the snapshot slave when >>> the VM is forked: >> >> An NBD server on top of the read-only state is an additional step that >> will make access easier. > > Does an NBD work as COW? It looks convenient. Rather, I'm thinking of making the NBD of the read-only internal snapshot be the backing file of the new qcow2 layer. But yes, NBD is probably the best way for qemu to expose the contents of an internal snapshot, rather than inventing yet another protocol. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
