Bug 1298527
Summary: | KeyError in getVmMemoryStats when VMs are migrating | ||
---|---|---|---|
Product: | [oVirt] mom | Reporter: | Francesco Romani <fromani> |
Component: | Core | Assignee: | bugs <bugs> |
Status: | CLOSED WONTFIX | QA Contact: | Shira Maximov <mshira> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 0.5.1 | CC: | bugs, dfediuck, fromani, mgoldboi, michal.skrivanek, mshira, msivak, pkliczew |
Target Milestone: | --- | Flags: | sbonazzo:
ovirt-4.2-
|
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-01-17 11:52:01 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
Francesco Romani
2016-01-14 11:02:11 UTC
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA. oVirt 4.0 beta has been released, moving to RC milestone. oVirt 4.0 beta has been released, moving to RC milestone. Martin, Francesco, if the the VM is already DOWN at vdsm then we just need to ignore it in the collector if we are not doing so today. Except we won't know that, because the engine will collect the result first sometimes. We need to be able to start listening to the events between vdsm and engine to handle this properly. (In reply to Martin Sivák from comment #5) > Except we won't know that, because the engine will collect the result first > sometimes. We need to be able to start listening to the events between vdsm > and engine to handle this properly. +1 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). What about querying vdsm source or destination for the vm? We are querying the source (localhost). But the VM just suddenly disappears when the migration is finished - migration finished, event to engine, engine calls destroy, vdsm removes all traces about the vm. MOM will never talk to anybody else than the local VDSM or libvirt. Is this still relevant when we move to event monitoring? If so, is it relevant for 4.2? The event monitoring would fix it. This bug actually depends on one of the event monitoring bugs. how exactly would it fix it? can you enumerate the exact flow of actions? By actually telling MOM that the VM is not available anymore? We can then use that information to not request data from VDSM.. how does that solve a situation of MOM receiving this event while there is an inflight getVmMemoryStats request in vdsm already? This is about MOM traceback not vdsm. And the event means the VM finished and there is a result to be collected. It takes time for the VM structure to be destroyed and that is another request that needs to be done from the engine first. So it will not break any in-flight requests. And not other requests will be done since MOM will know that someone is about to call VM.destroy. This is just annoying and we have too many other issues for now. Please reopen if it appears too often. |