On 08.07.2016 11:50, Kevin Wolf wrote: > Am 08.07.2016 um 04:56 hat Fam Zheng geschrieben: >> On Tue, 07/05 15:37, Kevin Wolf wrote: >>> Am 17.06.2016 um 11:23 hat Kevin Wolf geschrieben: >>>> Am 03.06.2016 um 10:48 hat Fam Zheng geschrieben: >>>>> Respect the locking mode from CLI or QMP, and set the open flags >>>>> accordingly. >>>>> >>>>> Signed-off-by: Fam Zheng <[email protected]> >>>>> Reviewed-by: Max Reitz <[email protected]> >>> >>>> This is the wrong level to implement the feature. You would only be able >>>> to configure the locking on the top level image this way (because what >>>> we're doing here is BB, not BDS configuration). If you want to allow >>>> configuration per node, you need to put the options into >>>> bdrv_runtime_opts and interpret them in bdrv_open_common(). >>>> >>>> Otherwise we would have to specify in the blockdev-add documentation >>>> that this works only on the top level, but I don't see a reason for >>>> such a restriction. >>> >>> And actually, after some more thinking about block device configuration, >>> I'm not sure any more whether letting the user configure this on the >>> node level, at least as the primary interface. >>> >>> A node usually knows by itself what locking mode it needs to request >>> from its children, depending on the locking mode that the parent node >>> requested for it. It could be passing down the locking mode (raw >>> format), it could require a stricter locking mode (non-raw formats never >>> work with r/w sharing) or it could even be less strict (backing files >>> are normally ro/ and can therefore be shared, even if the guest can't >>> share its image). >>> >>> The real origin of the locking requirement is the top level. So maybe >>> the right interface for guest devices is adding a qdev option that tells >>> whether the guest can share the image. For NBD servers, we'd add a QMP >> >> I think most block devices are not designed to share the data, so in general >> it's hard to imagine this as a device property. > > Well, it's really a guest OS (or even guest application) property, but > obviously that doesn't exist. And the device is the qemu component that > is the closest to the guest. We generally have options about behaviour > that the guest expects at the device level.
Can the guest device really make a qualified decision here? If you're using raw as the image format, sharing may be fine, if you're using qcow2, it most likely is not. I think whether to lock a BDS chain is a host-side property and has not a lot to do with the guest, thus it should be a BDS property. I can imagine that a guest may say that sharing should be disallowed under all circumstances, but a guest is never able to decide to allow sharing. Max
signature.asc
Description: OpenPGP digital signature
