Bug 1813711
| Summary: | Migration fails immediately | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] cockpit-ovirt | Reporter: | Eric <eevans> | ||||||
| Component: | Generic | Assignee: | Gal Zaidman <gzaidman> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | meital avital <mavital> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 0.14.2 | CC: | bugs, cshao, didi, eevans, eslutsky, rbarry, sdickers | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2020-04-03 14:36:21 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | UX | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Please attach all relevant logs - /var/log/ovirt-engine/* from engine and /var/log/vdsm/* from hosts. Thanks! I replied to the email and sent the requested logs. I will post them here. Engine log: The logs are at this url: https://1drv.ms/u/s!AvgvEzKKSZHbg_9349wQ1D_YzHulxw?e=cZ48NM If you have any questions or need more information please let me know. Scott, can you please have a look? I suspect a UI issue, not sure. For reference, this is also discussed on the users mailing list, thread subject: [ovirt-users] cannot manually migrate vm's I checked the UI logs and nothing is there....no entries at all but I did upgrade to 4.3.9.5. I will try migration and check ui log again. Nothing in the UI log but this is in the engine.log. 2020-03-23 07:41:58,197-04 INFO [org.ovirt.engine.core.utils.servlet.ServletUtils] (default task-47) [] Can't read file '/usr/share/ovirt-engine/files/spice/SpiceVersion.txt' for request '/ovirt-engine/services/files/spice/SpiceVersion.txt' -- 404 2020-03-23 07:42:07,792-04 WARN [org.ovirt.engine.core.bll.SearchQuery] (default task-47) [78de8211-936e-425b-8c56-5a0f9b4e3148] ResourceManager::searchBusinessObjects - Invalid search text - ''VMs : id='' 2020-03-23 07:42:12,390-04 WARN [org.ovirt.engine.core.bll.SearchQuery] (default task-47) [f7a412d8-bda7-4762-baf9-873f6027b6dd] ResourceManager::searchBusinessObjects - Invalid search text - ''VMs : id='' 2020-03-23 07:42:18,919-04 WARN [org.ovirt.engine.core.bll.SearchQuery] (default task-47) [53e8fc17-9173-426f-b953-92b2ce1d6bcf] ResourceManager::searchBusinessObjects - Invalid search text - ''VMs : id='' Thanks, Eric. Can you please check your browser's console when this happens? Also restoring needinfo on Scott. Created attachment 1674441 [details]
console-export-2020-3-29_6-2-3.txt from Eric
Eric - can you verify the version of ovirt-engine and ovirt-engine-ui-extensions in your environment where the VM migrate dialog is not working? rpm -q ovirt-engine ovirt-engine-ui-extensions From the logs, the frontend code that is supposed to fetch the list of valid target hosts for migration is failing. This is unusual as webadmin should be pushing the selected VM ids to the plugin as the VMs are selected. I'll look into this further. On my test environment: $ rpm -q ovirt-engine ovirt-engine-ui-extensions ovirt-engine-4.3.9.4-1.el7.noarch ovirt-engine-ui-extensions-1.0.10-1.el7.noarch the problem is not reproducible. Looking at the content of the ovirt-engine-ui-extensions commit log [1] indicates that v1.0.10 is the last release that is compatible with ovirt-engine 4.3. This is due to the webadmin plugin api breaking change in 4.4 [2], and change [3] to adopt to it in ui-extensions. I don't see any changes in ui-extensions after the 1.0.10 release that would be useful (or even work) if [3] was reverted on the 1.0.x branch and released as 1.0.14. [1] - https://gerrit.ovirt.org/gitweb?p=ovirt-engine-ui-extensions.git;a=shortlog [2] - https://gerrit.ovirt.org/104488 [3] - https://gerrit.ovirt.org/104513 My output for rpm -q ovirt-engine ovirt-engine-ui-extensions: ovirt-engine-4.3.9.5-0.0.master.20200316152751.git0470641.el7.noarch ovirt-engine-ui-extensions-1.0.13-1.20200303git3b594b8.el7.noarch (In reply to Eric from comment #10) > My output for rpm -q ovirt-engine ovirt-engine-ui-extensions: > > ovirt-engine-4.3.9.5-0.0.master.20200316152751.git0470641.el7.noarch > ovirt-engine-ui-extensions-1.0.13-1.20200303git3b594b8.el7.noarch Ok there is your problem! If you roll-back `ovirt-engine-ui-extensions` to 1.0.10 and you should be ok. I downgraded to 1.0.10 and problem solved. I am still confused how the newer version got installed. Thanks for your help. Thanks for the report, Eric. You probably tried upgrading to 4.4 alpha and gave up in the middle, but didn't rollback everything. If so, you can check your 'yum history' and 'yum history undo ID' for all IDs of transactions in which you updated stuff to 4.4. If it's something else, and you suspect a bug on our side (in packaging, announcements, whatever), please open one. Thanks!
Scott - you might want to make 4.3 engine:
Conflicts: %{name}-ui-extensions >= 1.0.11
(or whatever). And perhaps next time call it '1.1' or even '2.0' when breaking backwards-compatibility (and then also add such a line, which will then make more sense). Thanks :-)
I openend BZ1835554 to implement the suggestion in comment #13. |
Created attachment 1670359 [details] Screen shot of error in UI. Description of problem: Manual Migration and load balancing are not working unless you put the host node into maintenance mode. If you try to manually migrate a vm if fails immediately with the message "Could not fetch data needed for migration operation. Version-Release number of selected component (if applicable): After upgrade to 4.39 How reproducible: By trying to manually migrate any vm. Steps to Reproduce: 1. Right click or highlight any vm 2. chose migrate 3. Actual results: fails immediately. Expected results: vm migration window opens for migration operation Additional info: No additional corresponding with the time of the attempted migration in engine log, libvirt or vmsm logs.