Bug 2064907
Summary: | [RFE] Support measuring sub chain | ||
---|---|---|---|
Product: | [oVirt] vdsm | Reporter: | Nir Soffer <nsoffer> |
Component: | General | Assignee: | Nir Soffer <nsoffer> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Nir Soffer <nsoffer> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.50 | CC: | ahadas, bugs, dfodor, kwolf, sfishbai |
Target Milestone: | ovirt-4.5.1 | Keywords: | CodeChange, FutureFeature |
Target Release: | --- | Flags: | pm-rhel:
ovirt-4.5?
pm-rhel: planning_ack? pm-rhel: devel_ack+ pm-rhel: testing_ack? |
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | vdsm-4.50.1.2 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-06-19 16:28:47 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 2041352 |
Description
Nir Soffer
2022-03-16 20:42:19 UTC
Kevin, do you see any issue with the suggested solution, or a simpler way to do this? Yes, this looks like the correct approach to me. The only way I see to simplify the 'qemu-img measure' command line is if we introduced something like a --base option which would work based on a filename, though identifying base images by their filename is something that we have been hesitant to do in newer interfaces. But on the command line it might be justified. On the other hand, changing QEMU means that you'd have to wait for a release containing the new feature, so your approach is probably more practical. Of course, in the live merge of the active layer case, the required size can change while the commit job is running. If you relied on the overestimation to make this go unnoticed before, you need to make sure now to monitor and dynamically extend not only the active layer, but also the commit target when it fills up to near its current size. (Probably you already do this, mentioning it just in case.) (In reply to Kevin Wolf from comment #2) > The only way I see to simplify the 'qemu-img measure' command line is if we > introduced something like a --base option which would work based on a > filename, though identifying base images by their filename is something that > we have been hesitant to do in newer interfaces. This would be useful for other users of qemu-img, but I'm not sure how many users need this functionality. I think the current situation is very good; qemu-img make it easy to do the common operations, and if you have special needs the json file name gives you lot of power to do what you need in simple and clear way. > But on the command line it > might be justified. On the other hand, changing QEMU means that you'd have > to wait for a release containing the new feature, so your approach is > probably more practical. Right, we want to use this with RHV 4.4 on RHEL 8.6 now. If qemu-img in RHEL 9 will support --base, oVirt will likey use it. > Of course, in the live merge of the active layer case, the required size can > change while the commit job is running. If you relied on the overestimation > to make this go unnoticed before, you need to make sure now to monitor and > dynamically extend not only the active layer, but also the commit target > when it fills up to near its current size. (Probably you already do this, > mentioning it just in case.) Unfortunately we don't monitor or extend the base volume yet, so live merge may fail with ENOSPC. I hope this will be improved in RHV 4.4.z. Our current live merge uses a very dumb allocation - allocating extra ~5g per merge. If you have 50g mostly empty image, after 10 live merges the image will fully allocated even if there is no actual data in the image. This space will eventually cause oVirt storage domain to become full when there is lot of available space in the underlying stoarge. With this mechanism, we can ensure that on every merge, we have certain amount of free space in the image. If the image was extended in a previous live merge and there is enough free space, we will not extend it again. The fix for this bug added internal API alowing measuring sub chain, and an option in vdsm API to use it. Future engine can use the new API to measure sub chain when validation storage opeartions. This change enables correct extend in cold and live merge, tracked upstream in: - https://github.com/oVirt/vdsm/issues/134 (fixed in ovirt 4.5.1) - https://github.com/oVirt/vdsm/issues/188 (expected in ovirt 4.5.1) This bugzilla is included in oVirt 4.5.1 release, published on June 22nd 2022. Since the problem described in this bug report should be resolved in oVirt 4.5.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |