On Sun, 29 Nov 2009 02:57:04 +0900 MORITA Kazutaka <[email protected]> wrote:
> On 11/29/2009 12:45 AM, Chris Webb wrote: > > MORITA Kazutaka <[email protected]> writes: > > > >> Even read-only access is not allowed while another qemu is doing > >> write access. However, there is no problem about your patch, I guess. > >> > >> It is because Sheepdog allow us to clone images only from > >> snapshot images. It means a backing image is always read-only. > >> If users specify writable Sheepdog VDI as a backing image, > >> qemu-img returns error. > > > > What about the case of (for example) a qcow2 file backed by a Sheepdog > > image? Is that also restricted to be a snapshot image (and therefore safe) > > or is there a potential problem there? > > Yes, in this case, a backing Sheepdog image is restricted to a snapshot > image, too. > > However, taking other formats into account, bdrv_claim may be required > even when opening as read-only. It is because qcow2 cannot prevent other > VMs write data to an opened backing image. > If so, bdrv_claim need more arguments such as open flags > to notify the opened image is read-only or not, right? If bdrv_open tells us the purpose (opens to create a snapshot, opens to run a VM, etc), we don't need bdrv_claim? The asymmetric API (open vs. close and release) might not be good. Anyway, I guess that it would be better to discuss this lock/release VDI issue on qemu-devel. -- sheepdog mailing list [email protected] http://lists.wpkg.org/mailman/listinfo/sheepdog
