Bug 2073120 - The CPU resources are not properly freed upon dedicated VM hibernation .
Summary: The CPU resources are not properly freed upon dedicated VM hibernation .
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.5.0
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ovirt-4.5.0
: 4.5.0.2
Assignee: Liran Rotenberg
QA Contact: Polina
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-04-07 16:31 UTC by Polina
Modified: 2022-04-28 09:26 UTC (History)
3 users (show)

Fixed In Version: ovirt-engine-4.5.0.2
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-04-28 09:26:34 UTC
oVirt Team: Virt
Embargoed:
pm-rhel: ovirt-4.5?


Attachments (Terms of Use)
engine log (334.26 KB, application/gzip)
2022-04-07 16:31 UTC, Polina
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-45572 0 None None None 2022-04-07 16:33:43 UTC

Description Polina 2022-04-07 16:31:34 UTC
Created attachment 1871362 [details]
engine log

Description of problem:
When suspending VM we expect to free all CPU resources. Then the resume must be successfully done on the same host. we have an error instead and VM is resumed on other host.

Version-Release number of selected component (if applicable):
ovirt-engine-4.5.0.1-605.90f87fe14688.14.el8ev.noarch

How reproducible:
100%

Steps to Reproduce:
1. Build a VM on the base of the last infra template and configure it with dedicated policy . Configure the CPU topology to take max of the resources, like for example on host 2:8:2 (serval19.lab.eng.tlv2.redhat.com), run VM 15:1:2.
2. Run the VM and then suspend, wait a minute 
3. Resume the VM


Actual results:
VM is always resumed on different host and there is an error in engine

2022-04-07 14:12:33,626+03 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-58) [816717b2-17ea-4d94-b9ca-ad3a08904aeb] EVENT_ID: USER_FAILED_RUN_VM(54), Failed to run VM golden_env_mixed_virtio_0 due to a failed validation: [Cannot run VM. There is no host that satisfies current scheduling constraints. See below for details:, The host host_mixed_1 did not satisfy internal filter CpuPinning because doesn't have enough CPUs for the dedicated CPU policy that the VM is set with..] (User: admin@internal-authz).


Expected results:
VM resumed on the same host without error


Additional info: in the attached engine.log the timestamp for error  is 2022-04-07 14:12:33,626+03

Comment 1 Polina 2022-04-07 17:33:37 UTC
the similar scenario with pausing the dedicated VM behaves correctly . VM is resumed on the same host with the correct pinning

Comment 2 Arik 2022-04-11 11:28:22 UTC
Pausing is different - and it makes sense that it works properly with the current mechanism
It (clearing of the resources) might be missing in the transition to SUSPENDED, need to check

Comment 3 Liran Rotenberg 2022-04-13 14:53:15 UTC
Works for me, moving back to QE. Please try again on latest version (Beta as a minimum - 4.5.0.2).

Comment 4 Polina 2022-04-18 09:20:34 UTC
Hi Liran , I verified it on ovirt-engine-4.5.0.2-0.7.el8ev.noarch.
No error. Though VM is always resumed on another host. please confirm it is not a problem if no error happens.

Comment 5 Liran Rotenberg 2022-04-24 06:56:48 UTC
To me it worked on the same host. Can you switch all other hosts to maintenance and see it works on the same single one?

Comment 6 Arik 2022-04-24 09:27:37 UTC
We don't guarantee to restore a suspended vm on the host that it previously ran - that's not an issue
We are supposed to reserve the resources on the scheduled host and alter the CPU pinning, which I believe we don't do at the moment, though

Comment 7 Polina 2022-04-24 09:46:24 UTC
yes, the VM is restarted on the same host if other hosts are in maintenance.

also, the important is that now there is no internal filter CpuPinning Error.

Closing the bug for ovirt-engine-4.5.0.2-0.7.el8ev.noarch.

Comment 8 Sandro Bonazzola 2022-04-28 09:26:34 UTC
This bugzilla is included in oVirt 4.5.0 release, published on April 20th 2022.

Since the problem described in this bug report should be resolved in oVirt 4.5.0 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.


Note You need to log in before you can comment on or make changes to this bug.