Bug 1349817
Summary: | iotune policy queries raising exceptions in vdsm | ||
---|---|---|---|
Product: | [oVirt] vdsm | Reporter: | Michal Skrivanek <michal.skrivanek> |
Component: | General | Assignee: | Steven Rosenberg <srosenbe> |
Status: | CLOSED WORKSFORME | QA Contact: | Polina <pagranat> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.18.4 | CC: | bugs, dfediuck, msivak |
Target Milestone: | --- | Flags: | michal.skrivanek:
planning_ack?
michal.skrivanek: devel_ack? michal.skrivanek: testing_ack? |
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: | 2018-06-19 13:48:13 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | SLA | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1363728 | ||
Bug Blocks: |
Description
Michal Skrivanek
2016-06-24 10:51:02 UTC
We can only solve this by monitoring the event stream between vdsm - engine, because we have no way of detecting a finished migration or stopped VM soon enough (the engine calls destroy almost immediately and the status in vdsm is then lost). the point of the bug is to eliminate a traceback, not necessarily all invocations of the API - that is fine and expected to happen. We just need to respond with a regular response with err code, not raising exceptions in vdsm code. Events would help, but not 100% resolve it I guess. I wonder if this still happens when done over jsonrpc. I attempted to simulate this by deploying two hosts and one VM from ovirt-engine. One host was running vdsm version 4.20.17-1 and the other 4.20.27.1-1. The mom versions were 0.5.11-1 for the older version and 0.5.12-1 for the current version. I tested both migration between both hosts and shutting down the VM from both hosts. This error did not occur. For the host running mom version 0.5.11-1, there were errors when migrating from this host and shutting down the VM when running on the host and they were the same related to the code handling GuestCpuTune. However, being that no errors occurred when migrating from, migrating to and shutting down the VM from the host running the current version, with changes to the code handling the GuestCpuTune, we may assume that both issues are no longer relevant. |