Bug 1769339
| Summary: | webadmin - Extend floating disk size on image, ISCSI, thin-prov' disks does not work | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Daniel <dmaaravi> | ||||||||
| Component: | BLL.Storage | Assignee: | shani <sleviim> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Daniel <dmaaravi> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 4.4.0 | CC: | bugs, rdlugyhe, sleviim | ||||||||
| Target Milestone: | ovirt-4.4.0 | Flags: | pm-rhel:
ovirt-4.4+
|
||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: |
Previously, extending a floating QCOW disk did not work because the user interface and REST API ignored the getNewSize parameter. The current release fixes this issue and validates the settings so you can extend a floating QCOW disk.
|
Story Points: | --- | ||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2020-05-20 20:04:24 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: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 1633354 [details]
Extend floating disk via the ui - works for me
working on master.
Hi Daniel, I've tried to extend one of my disks - image disk over iscsi storage domain, and the operation was succeeded. (Attached a gif). Can you please give it another try? Shani I'm guessing you've found the problem since I see a patch was submitted, please comment here with exact steps to reproduce After a talk with Daniel, it seems that the title of the bug is wrong: Extending disks works for RAW disks, but it didn't work well for QCOW disks. In order to reproduce: 1. create a new QCOW disk - Thin provision + check the 'enable incremental backup' option. 2. Edit the disk > extend (by 1GB is also fine, not need to extend by 10GB). Daniel, can you please validate that this scenario is the broken one and update the bug description and title? Created attachment 1635196 [details]
properties of disk which it extension fails
verified via web-admin and rest on engine version 4.4.0-0.13.master.el7 bug is fixed, disk is extended as it should. This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.0 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. |
Created attachment 1633262 [details] engine&vdsm logs Description of problem: Via webadmin I tried to extend a floating disk size by 10G and virtual size does not changed as expected: not in UI and not via RESTAPI. Also checked qemu-img info. Engine log:2019-11-06 10:51:44,690+02 INFO [org.ovirt.engine.core.bll.storage.disk.UpdateDiskCommand] (default task-41) [13259997-41a6-49e6-9d32-bd7e08efe21c] Lock Acquired to object 'EngineLock:{exclusiveLocks='[6037d16e-9b19-4575-a069-27f779bd2b90=DISK]', sharedLocks=''}' 2019-11-06 10:51:44,753+02 INFO [org.ovirt.engine.core.bll.storage.disk.UpdateDiskCommand] (default task-41) [13259997-41a6-49e6-9d32-bd7e08efe21c] Running command: UpdateDiskCommand internal: false. Entities affected : ID: 6037d16e-9b19-4575-a069-27f779bd2b90 Type: DiskAction group EDIT_DISK_PROPERTIES with role type USER 2019-11-06 10:51:44,785+02 INFO [org.ovirt.engine.core.bll.storage.disk.image.ExtendImageSizeCommand] (default task-41) [13259997-41a6-49e6-9d32-bd7e08efe21c] Running command: ExtendImageSizeCommand internal: true. Entities affected : ID: 6037d16e-9b19-4575-a069-27f779bd2b90 Type: DiskAction group EDIT_DISK_PROPERTIES with role type USER 2019-11-06 10:51:44,788+02 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.ExtendImageSizeVDSCommand] (default task-41) [13259997-41a6-49e6-9d32-bd7e08efe21c] START, ExtendImageSizeVDSCommand( ExtendImageSizeVDSCommandParameters:{storagePoolId='8af906e8-006f-4132-8776-13329af71eef', ignoreFailoverLimit='false'}), log id: 230289ef 2019-11-06 10:51:45,090+02 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.ExtendImageSizeVDSCommand] (default task-41) [13259997-41a6-49e6-9d32-bd7e08efe21c] FINISH, ExtendImageSizeVDSCommand, return: , log id: 230289ef 2019-11-06 10:51:45,111+02 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (default task-41) [13259997-41a6-49e6-9d32-bd7e08efe21c] CommandAsyncTask::Adding CommandMultiAsyncTasks object for command '000d5e00-2294-4e76-bdb3-48cf1290dfdc' 2019-11-06 10:51:45,111+02 INFO [org.ovirt.engine.core.bll.CommandMultiAsyncTasks] (default task-41) [13259997-41a6-49e6-9d32-bd7e08efe21c] CommandMultiAsyncTasks::attachTask: Attaching task 'aa34ada4-5235-4813-845f-0fb92205a16a' to command '000d5e00-2294-4e76-bdb3-48cf1290dfdc'. 2019-11-06 10:51:45,131+02 INFO [org.ovirt.engine.core.bll.tasks.AsyncTaskManager] (default task-41) [13259997-41a6-49e6-9d32-bd7e08efe21c] Adding task 'aa34ada4-5235-4813-845f-0fb92205a16a' (Parent Command 'UpdateDisk', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters'), polling hasn't started yet.. 2019-11-06 10:51:45,161+02 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-41) [13259997-41a6-49e6-9d32-bd7e08efe21c] EVENT_ID: USER_UPDATE_DISK(86), Disk ccc was updated by admin@internal-authz. 2019-11-06 10:51:45,162+02 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (default task-41) [13259997-41a6-49e6-9d32-bd7e08efe21c] BaseAsyncTask::startPollingTask: Starting to poll task 'aa34ada4-5235-4813-845f-0fb92205a16a'. 2019-11-06 10:51:56,126+02 INFO [org.ovirt.engine.core.bll.storage.disk.UpdateDiskCommand] (EE-ManagedThreadFactory-engine-Thread-102934) [13259997-41a6-49e6-9d32-bd7e08efe21c] Ending command 'org.ovirt.engine.core.bll.storage.disk.UpdateDiskCommand' successfully. VDSM: 2019-11-06 10:51:44,790+0200 INFO (jsonrpc/4) [vdsm.api] START extendVolumeSize(spUUID='8af906e8-006f-4132-8776-13329af71eef', sdUUID='d9492192-928f-4b2d-af82-ee0d6278549b', imgUUID='6037d16e-9b19-4575-a069-27f779bd2b90', volUUID='8e19a872-08a4-41e1-9f01-cf31b89b2e68', newSize='3221225472') from=::ffff:10.35.162.6,42860, flow_id=13259997-41a6-49e6-9d32-bd7e08efe21c, task_id=aa34ada4-5235-4813-845f-0fb92205a16a (api:48) 2019-11-06 10:51:44,926+0200 INFO (jsonrpc/4) [vdsm.api] FINISH extendVolumeSize return=None from=::ffff:10.35.162.6,42860, flow_id=13259997-41a6-49e6-9d32-bd7e08efe21c, task_id=aa34ada4-5235-4813-845f-0fb92205a16a (api:54) [root@storage-ge7-vdsm3 ~]# qemu-img info /rhev/data-center/8af906e8-006f-4132-8776-13329af71eef/d9492192-928f-4b2d-af82-ee0d6278549b/images/6037d16e-9b19-4575-a069-27f779bd2b90/8e19a872-08a4-41e1-9f01-cf31b89b2e68 image: /rhev/data-center/8af906e8-006f-4132-8776-13329af71eef/d9492192-928f-4b2d-af82-ee0d6278549b/images/6037d16e-9b19-4575-a069-27f779bd2b90/8e19a872-08a4-41e1-9f01-cf31b89b2e68 file format: qcow2 virtual size: 1.0G (1073741824 bytes) disk size: 0 cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false Version-Release number of selected component (if applicable): ovirt-engine-4.4.0-0.4.master.el7.noarch vdsm-4.40.0-127.gitc628cce.el8ev.x86_64 How reproducible: 100% Steps to Reproduce: 1. Login to web admin 2. Navigate to Storage > Disks 3. Create new Image disk with Size 1(GiB) 4. After disk is created, press on it and press edit. 5. Extend size by 10(Gib) Actual results: Actual size stays 1(Gib) Expected results: Actual size should be 11(Gib) Additional info: Logs attached.