Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1089173

Summary: HA VM reservation check ignores insufficient memory on other hosts
Product: Red Hat Enterprise Virtualization Manager Reporter: Lukas Svaty <lsvaty>
Component: ovirt-engineAssignee: Kobi <kianku>
Status: CLOSED NOTABUG QA Contact: Lukas Svaty <lsvaty>
Severity: medium Docs Contact:
Priority: high    
Version: 3.4.0CC: acathrow, dfediuck, gklein, iheim, lpeer, lsvaty, mavital, Rhev-m-bugs, yeylon
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: sla
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-23 14:16:24 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:
Attachments:
Description Flags
engine.log none

Description Lukas Svaty 2014-04-18 07:40:42 UTC
Description of problem:
Setup with 2 hosts 96% of memory consumed on first, second running HA VM with 4GB memory (half of hosts memory). HA VM reservation check is reporting cluster is HA safe. While manual migration fails.

Version-Release number of selected component (if applicable):
is6

How reproducible:
100%

Steps to Reproduce:
1. Consume memory on host1
2. Run HA VM on host2 with memory set to half of host1 total memory
3. HA reservation check reports cluster is HA safe
4. Try to migrate manually VM (fails)

Actual results:
Cluster is HA safe.

Expected results:
Cluster should not be HA safe and appropriate warning should be displayed. Cluster should not be HA safe if manual migration is failing due to the insufficient memory on other host.

Comment 1 Lukas Svaty 2014-04-18 07:42:17 UTC
Created attachment 887447 [details]
engine.log

Actions:
Start VM
Wait for HA check
Manual migration of VM (failed)
Wait for HA check

Comment 2 Lukas Svaty 2014-04-18 08:31:10 UTC
After few more tests it seems it occurs only when memory is allocated manually by other process

python
>>> foo = ' ' * 6845388000

engine with 2 hosts:
2014-04-18 10:25:45,970 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-97) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Available memory of host 10.34.62.203 [969 MB] is under defined threshold [1024 MB].
2014-04-18 10:29:43,098 INFO  [org.ovirt.engine.core.bll.scheduling.HaReservationHandling] (DefaultQuartzScheduler_Worker-84) HA reservation status for cluster cluster_MOM is OK


when memory on hosts is allocated by VMs in engine HA check is correct

Comment 3 Kobi 2014-04-22 08:51:47 UTC
Hi Lukas,
1. For memory monitoring you will need to have guest-agent installed on your VMs.
Can you make sure it is installed and that you have memory monitoring.
Easiest way to check that is in the VM window, you will see the memory bar is bigger than 0% .

2. If (1) is OK and installed, can you please check that you can see that the host is 50% occupied in the hosts window?

10x

Comment 4 Lukas Svaty 2014-04-23 13:48:18 UTC
Hi,

1. GA is running, and memory of VM is counted properly
2. Host memory status 92%

The problem is that HA reservation is checking if it is possible to start migration, not if the host as sufficient amount of memory. In case of manually consuming memory of host (not by VMs in engine). Engine lets you migrate the VM and the migration fails. 

This might be a problem of migration too. Migration should stop the same way as if the memory is consumed by running VM.

I thing these should be unified and so both would not allow user to migrate VM:
When memory of dst-host is consumed by VMs in engine. => Do not allow migration.
When memory of dst-host is consumed by other processes. => Allow migration and fail

Comment 5 Lukas Svaty 2014-04-23 14:16:24 UTC
Closing this bug after consulting this with dev, HA reservation is working correctly as external processes should not allocate large amount of memory on virtualization only hosts.

This is related to migration and should be fixed/proposed as RFE. 

https://bugzilla.redhat.com/show_bug.cgi?id=1090521