Bug 1646161
| Summary: | IndexOutOfBoundsException: Index: 0, Size: 0 during import of VM | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Petr Kubica <pkubica> | ||||
| Component: | BLL.Storage | Assignee: | shani <sleviim> | ||||
| Status: | CLOSED CANTFIX | QA Contact: | Elad <ebenahar> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 4.2.7.1 | CC: | bugs, cshao, eshenitz, frolland, lsvaty, pkubica, tnisan | ||||
| Target Milestone: | ovirt-4.3.4 | Flags: | rule-engine:
ovirt-4.3+
|
||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-04-07 09:43:18 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
Petr Kubica
2018-11-05 09:47:17 UTC
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP. > Short info what happened: There are 4 groups of VMs after migration > - VMs which was sucessfully imported after migration of domain no action item here > - VMs listed (and should be there) but couldn't be imported - message > General command validation failure already WA, I think this bug is related to this issue These 2 are still blockers in our production, should we create separate bugs? > - VMs which are listed but they're deleted before detaching domain These VMs metadata were incorrect on SD, and had to be fixed from backup of DB. Afterwards VMs were successfully restored. > - VMs which was on storage domain before detaching, but after attaching in > secondary datacenter these VMs are not listed anywhere. > These VMs can be seen in backup-DB, however, in current DB after attaching SD they are not listed. On the SD we can see them, however we suspect wrong metadata as oVirt wont list them. Any WA here? Furthermore, scanning discs on the storage domain, is not finding all the discs that we can see on SD (lvdisplay), can this be cause again by wrong metadata, or can we suspect some missing crucial data from storage domain, thus potentially lost of data? > These 2 are still blockers in our production, should we create separate bugs? > > - VMs which are listed but they're deleted before detaching domain > These VMs metadata were incorrect on SD, and had to be fixed from backup of > DB. > Afterwards VMs were successfully restored. No, this is expected since the OVF update failed > > > - VMs which was on storage domain before detaching, but after attaching in > > secondary datacenter these VMs are not listed anywhere. > > > These VMs can be seen in backup-DB, however, in current DB after attaching > SD they are not listed. On the SD we can see them, however we suspect wrong > metadata as oVirt wont list them. > > Any WA here? Just import their disks and recreate the VMs > > Furthermore, > > scanning discs on the storage domain, is not finding all the discs that we > can see on SD (lvdisplay), can this be cause again by wrong metadata, or can > we suspect some missing crucial data from storage domain, thus potentially > lost of data? Do you mean scanning disk using oVirt? (In reply to Eyal Shenitzky from comment #11) > > These 2 are still blockers in our production, should we create separate bugs? > > > - VMs which are listed but they're deleted before detaching domain > > These VMs metadata were incorrect on SD, and had to be fixed from backup of > > DB. > > Afterwards VMs were successfully restored. > > No, this is expected since the OVF update failed > > > > > - VMs which was on storage domain before detaching, but after attaching in > > > secondary datacenter these VMs are not listed anywhere. > > > > > These VMs can be seen in backup-DB, however, in current DB after attaching > > SD they are not listed. On the SD we can see them, however we suspect wrong > > metadata as oVirt wont list them. > > > > Any WA here? > > Just import their disks and recreate the VMs Their disks are not listed too (in disk import). > > > > Furthermore, > > > > scanning discs on the storage domain, is not finding all the discs that we > > can see on SD (lvdisplay), can this be cause again by wrong metadata, or can > > we suspect some missing crucial data from storage domain, thus potentially > > lost of data? > Do you mean scanning disk using oVirt? Yes, I do. I will attach logs from scanning disk. Created attachment 1504710 [details]
lvscan and engine.log - scan disk
We've tried to reproduce it in the scenario described and in other scenarios concerning missing memory disks (on the same domain, different domain, missing domain, domain on another pool) and they all worked correctly. The only way to reach the exception is when the memory disk entity exists yet a corresponding image entity is missing from the database which is a situation that should never happen and we could not reproduce. For now we cannot reproduce and thus cannot find a solution so we're postponing to 4.3, if you can provide any other data please do (In reply to Tal Nisan from comment #14) > We've tried to reproduce it in the scenario described and in other scenarios > concerning missing memory disks (on the same domain, different domain, > missing domain, domain on another pool) and they all worked correctly. > The only way to reach the exception is when the memory disk entity exists > yet a corresponding image entity is missing from the database which is a > situation that should never happen and we could not reproduce. > For now we cannot reproduce and thus cannot find a solution so we're > postponing to 4.3, if you can provide any other data please do We still have environment where did it happen if it could help. This environment exists from RHEV 3.3 I could provide an access to this environment. Ping me on IRC or send me email about details if you're interested. This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP. Not a blocker, this is a corner case This is a corner case in which an image chain is not updated correctly in the database, most likely due to a failed live merge in older Engine/VDSM versions, once the situation exists there's not much to do aside for following the manual steps mentioned in the comments, closing the bug due to that |