Bug 1685777
| Summary: | Block node is read-only when start a qcow2 image on https server and with auto-read-only=on set on its format node | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | aihua liang <aliang> |
| Component: | qemu-kvm | Assignee: | Virtualization Maintenance <virt-maint> |
| qemu-kvm sub component: | Storage | QA Contact: | aihua liang <aliang> |
| Status: | CLOSED WONTFIX | Docs Contact: | |
| Severity: | low | ||
| Priority: | low | CC: | chayang, coli, juzhang, kwolf, ngu, qzhang, rbalakri, virt-maint |
| Version: | 8.1 | Keywords: | Triaged |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1685772 | Environment: | |
| Last Closed: | 2021-03-15 07:33:55 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1685772 | ||
| Bug Blocks: | |||
|
Comment 1
aihua liang
2019-03-06 02:53:11 UTC
Kevin, what do you think of this? (The fact that a qcow2 node with auto-read-only on top of a read-only node isn’t switched to read-only automatically.) I suppose we can make auto-read-only switch nodes to being read-only if we cannot give them the write permission they wish to take. But I’m a bit afraid of the consequences. Won’t this be too automagical? (Like, shouldn’t we then also undo that whenever possible; do we have to switch a node to read-only because another node unshares the write permission; etc.) Or is that maybe what you had in mind all along? Max I think the proper way to do this would be what we do in file-posix: Make it dependent on the users of the node. bdrv_open() would open the image read-only and only attaching a writer changes it to read-write; detaching changes it back. Depending on the use case, just falling back to read-only on startup and leaving it there might be enough and would be much easier. Though this BZ looks like we don't even have an actual use case attached to it? Maybe failure isn't a problem in practice? A solution to this problem (as proposed by Kevin in comment 3) wouldn’t be trivial, so I won’t work on resolving this issue until there is an impact on an actual use case. (Note that in the meantime you simply have to specify read-only=on for the qcow2 node instead of auto-read-only, just as you always did before auto-read-only was introduced.) Max QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. |