[Sheepdog] VDI locking, migration and qemu
FUJITA Tomonori
fujita.tomonori at lab.ntt.co.jp
Mon Nov 30 05:46:08 CET 2009
On Sun, 29 Nov 2009 02:57:04 +0900
MORITA Kazutaka <morita.kazutaka at lab.ntt.co.jp> wrote:
> On 11/29/2009 12:45 AM, Chris Webb wrote:
> > MORITA Kazutaka <morita.kazutaka at lab.ntt.co.jp> 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.
More information about the sheepdog
mailing list