Project

General

Profile

action #38516

[tools] Disable memory autoballooning on openqaw5-xen

Added by michalnowak about 2 years ago. Updated 9 days ago.

Status:
Workable
Priority:
Low
Assignee:
-
Target version:
Start date:
2018-07-18
Due date:
2018-11-06
% Done:

0%

Estimated time:
Duration: 80

Description

svirt job on Xen may fail with:

[2018-07-18T09:54:56.0344 CEST] [debug] Command executed: virsh  define /var/lib/libvirt/images/openQA-SUT-3.xml
[2018-07-18T09:54:56.0539 CEST] [debug] Command's stdout:
Domain openQA-SUT-3 defined from /var/lib/libvirt/images/openQA-SUT-3.xml

[2018-07-18T09:54:56.0583 CEST] [debug] Command executed: virsh  start openQA-SUT-3
[2018-07-18T09:55:02.0753 CEST] [debug] Command's stderr:
error: Failed to start domain openQA-SUT-3
error: operation failed: Failed to balloon domain0 memory

I tried to disable autoballooning on openqaw5-xen.qa.suse.de in the past but perhaps I did not finish it. Here's how to do that: https://www.suse.com/documentation/sles-12/singlehtml/article_vt_best_practices/article_vt_best_practices.html#sec.vt.best.mem.xen.

History

#1 Updated by okurz about 2 years ago

  • Subject changed from [xen][functional] Disable memory autoballooning on openqaw5-xen to [xen][functional][u] Disable memory autoballooning on openqaw5-xen
  • Target version set to Milestone 19

Should we really disable autoballooning or rather reduce the amount of machines we execute on that host? Reducing the amount of machines sounds like a more conservative approach. I guess QSF would be fine with a little longer waiting time rather than random failures.

#2 Updated by michalnowak about 2 years ago

The host is capable of running much more than three VMs in parallel (that is our current setup), the problem is that sometimes Xen is not fast enough in "transferring" enough free memory from Dom0 to other (i.e. VM's) domain. Random failure might even happen for the first VM to be starter on the host.

Even our developers suggest to turn it off: "The SLES virt documentation recommends setting dom0_mem and disabling autoballooning. This avoids the pitfalls of autoballooning and is a better approach to managing system memory resources. domain0 can always be manually ballooned later, if needed." (https://bugzilla.suse.com/show_bug.cgi?id=943562#c19)

We should do the same in my opinion:

  • disable autoballooning
  • restrict DomU to 2-4 GB of RAM
  • keep the rest of RAM for VMs

#3 Updated by okurz about 2 years ago

ah, cool. Thanks for the explanation.

#4 Updated by okurz almost 2 years ago

  • Due date set to 2018-11-06
  • Target version changed from Milestone 19 to Milestone 20

#5 Updated by coolo almost 2 years ago

  • Project changed from openQA Tests to openQA Infrastructure
  • Category deleted (Infrastructure)

#6 Updated by nicksinger over 1 year ago

  • Status changed from New to Workable

I'm quiet scared to touch that host since I've no clue about XEN. Let's see what happens after I touched it.

#7 Updated by okurz over 1 year ago

  • Subject changed from [xen][functional][u] Disable memory autoballooning on openqaw5-xen to [tools] Disable memory autoballooning on openqaw5-xen
  • Target version deleted (Milestone 20)

nicksinger so you will pick it up?

#8 Updated by okurz 9 days ago

  • Priority changed from Normal to Low
  • Target version set to Ready

nicksinger so, have you touched it? That's what you mentioned in #38516#note-6

Also available in: Atom PDF