Created attachment 1387134 [details] Log Description of problem: Multiple 'Registering Disk 'OVF_STORE' has been initiated.' messages spamming the audit ui log on register domain flow. The event log ui is spammed wit multiple 'Registering Disk 'OVF_STORE' messages on DR flow. Which seems to be regression. Version-Release number of selected component (if applicable): 4.2.1.3-0.1.el7 How reproducible: 100% Steps to Reproduce: 1. Have a data domain with few VMs and template 2. Detach domain 3. Attach domain Actual results: The event log ui got spammed with multiple messages Expected results: There shouldn't be multiple events in the ui log.
Eyal, can this be related to your recent work?
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.
No, didn't touch around there. According to the description, this is a DR flow.
Michael, Did you notice how many OVF_STORE disks were in the storage domain prior to the deactivation? Moreover, I failed to reproduce the bug. I tried to deactivate a domain with VMs, templates, and VMs that created from the templates as thin. Did you reproduce it with the steps written above?
I have a lot of OVF_STORE disks, the question is how? and why? no idea. Seems that it is reproduce for me as i have plenty of such disks..which seems to be a bug on it's own. But i can't understand how i got to this situation in the first place.
So it seems like there really was a lot of OVF_STORE disks of the storage domain on the environment, which means that this bug is not the root cause of it. Please try to understand how your environment has more than 2 OVF_STORE disks per storage domain and update the bug accordingly. If you didn't find the issue / manage to reproduce it, please close this bug.
Yes, too many OVF_STORAGE disks(which is a bug by it's own), but i have no idea what caused. One assumption is that it caused by sub version templates that was removed from one of the templates and caused this mess. It is seems that it's not possible to import a template if it's sub version template is missing and i'm not sure if this is the expected behaviour. Will try to get to the bottom of that.
I managed to reproduce the bug, and now i have 4 OVF_STORAGE disks. To reproduce: 1) Create VM 2) Create template from it 3) Create another template + sub version template based on template from step 2 4) Remove the sub version template 5) Detach the data domain 6) From here, on each detach domain, 2 new OVF_STORAGE disks will be added to the domain. Now i got to situation i have more then 2 OVF_STORAGE disks.
Created attachment 1387666 [details] new engine log
Allon, can you please revisit this bug because it is a completely different from the initially reported bug.
(In reply to Eyal Shenitzky from comment #10) > Allon, can you please revisit this bug because it is a completely different > from the initially reported bug. This, in fact, sounds worse than the previously reported bug. I don't quite understand what you're asking me here.
Got what I needed, just wanted to know if it is still targeted to the same version
Managed to reproduce with more tight steps: 1) Create data-center with host 2) Add storage domain [A] to the data-center from step 1 (initialize the data-center) 3) Deactivate storage domain A -> 2 OVF_STORE disks was added 5) Detach storage domain A 6) Attach storage domain A back to the data-center from step 1 (initialize the data-center) 7) Deactivate storage domain A -> 2 more OVF_STORE disks was added This issue reproduces only when data-center is reinitialized by a storage domain. The template is not related to the bug.
This bug exists for a long time, remove the regression and blocker flags.
According to the steps from comment #13, OVF_STORE disks are not created after second SD deactivation. Used: rhvm-4.2.2.1-0.1.el7.noarch vdsm-4.20.19-1.el7ev.x86_64
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 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.