Bug 1625240
Summary: | Move disk (cold or live) fails with "InvalidParameterException: Invalid parameter: 'initial size=" | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [oVirt] vdsm | Reporter: | Elad <ebenahar> | ||||||
Component: | Core | Assignee: | Eyal Shenitzky <eshenitz> | ||||||
Status: | CLOSED WORKSFORME | QA Contact: | Avihai <aefrat> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 4.20.31 | CC: | aefrat, bugs, bzlotnik, eshenitz, nsoffer, sv, tnisan | ||||||
Target Milestone: | ovirt-4.3.5 | Keywords: | Reopened | ||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2019-05-16 12:31: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: | |||||||||
Attachments: |
|
Description
Elad
2018-09-04 13:08:45 UTC
Benny, can you have a look please? The problem appears to be the disk having 0 bytes as it's size. I am not sure how it came to be since it was created over two years ago. I will check if this issue is reproducible today as well This probably causes https://bugzilla.redhat.com/show_bug.cgi?id=1625669 as wll I couldn't reproduce it and I found this bug: https://bugzilla.redhat.com/1434927 As this disk was created before the validation was introduced, I suppose it was possible back then, probably with incorrect params sent via REST *** This bug has been marked as a duplicate of bug 1434927 *** *** Bug 1625669 has been marked as a duplicate of this bug. *** I disagree with closing this bug. The fact that the disk was created before the validation was introduced doesn't mean we can ignore such cases. What should a customer do in case he encounters it? Delete the disk? This is not a good approach. We have taken care of the root cause that can lead to such an issue, it's a corner case that can only be encountered when sending bad parameters via REST and was taken care of quite quick after the 4.1 GA so there are slim chances that a customer will hit that. In a case where a customer will we can create a KB that contains steps to rectify the situation I seem to have hit this same problem today when trying to move a disk on oVirt 4.2. ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-77) [] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), VDSM blade15.crt.lan command HSMGetAllTasksStatusesVDS failed: Error creating a new volume: (u"Volume creation e6171aae-2c5b-4c91-84fc-506c0e835928 failed: Invalid parameter: 'initial size=122016117'",) Is there a way to rectify this problem? Hi Simon, can you please attach the logs? Created attachment 1492417 [details]
engine.log
(In reply to Benny Zlotnik from comment #2) > The problem appears to be the disk having 0 bytes as it's size. This is probably result of failed resize. Eyal is working on similar bug. (In reply to Benny Zlotnik from comment #3) > I couldn't reproduce it and I found this bug: > https://bugzilla.redhat.com/1434927 > > As this disk was created before the validation was introduced, I suppose it > was possible back then, probably with incorrect params sent via REST No, this is not the same issue, and not a duplicate. But this may be a duplicate of Eyals bug about setting disk size to zero before resize. If resize fail, the disk size remaun zero. Created attachment 1492431 [details]
vdsm.log
The failing disk is VirtIO-SCSI on a ISCSI storage domain. Thin provisioned. There are a number of snapshots for the disk as well. This bug was closed as DUP of a bug that was fixed in 4.1.2. Also, it was seen by users in 4.2 (see comment #8). Hence, re-opening. Elad, please explain how to reproduce this. The error: 2018-09-04 15:10:51,101+0300 ERROR (tasks/6) [storage.Volume] The requested initial 78090314752 is bigger than the max size 0 (blockVolume:346) Say that the disk size is 0. How do you create disk with size of zero bytes? How are you going to use disk with size of zero bytes? I think the only thing we can do with such disk is delete it, as it cannot contain any data. This was seen for disk migration, also by Simon (see comment #13). Apart from that, I don't have any more information on how to reproduce. It seems like there might be a miss(In reply to Nir Soffer from comment #16) > Elad, please explain how to reproduce this. > > The error: > > 2018-09-04 15:10:51,101+0300 ERROR (tasks/6) [storage.Volume] The > requested initial 78090314752 is bigger than the max size 0 (blockVolume:346) > > Say that the disk size is 0. How do you create disk with size of zero bytes? I think that you confused with another bug, this error doesn't show in the attached VDSM log. > > How are you going to use disk with size of zero bytes? I think the only thing > we can do with such disk is delete it, as it cannot contain any data. Is this bug still reproduced? Not that I'm aware of, Avihai? (In reply to Elad from comment #19) > Not that I'm aware of, Avihai? AFAIK, We did not encounter this issue lately. If you do not have enough data to investigate/solve it please close it and if this resurfaces we will reopen it. We investigate an issue when engine sends invalid size (0, or < parent size). The fix discussed is to use the parent size. Elad, can you share details of the broken image with size=0? qemu-img info /dev/vg-name/lv-name vdsm-client Volume getInfo storagepoolID=... storagedomainID=... imageID=... volumeID=... |