[libvirt PATCH 08/17] qemu: Set limits only when explicitly asked to do so

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The current code is written under the assumption that, for all
limits except the core size, asking for the limit to be set to
zero is a no-op, and so the operation is performed
unconditionally.

While this is the behavior we want for the QEMU driver, the
virCommand and virProcess facilities are generic, and should not
implement this kind of policy: asking for a limit to be set to
zero should result in that limit being set to zero every single
time.

Add some checks in the QEMU driver, effectively moving the
policy where it belongs.

Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx>
---
 src/qemu/qemu_domain.c    |  5 +++--
 src/qemu/qemu_migration.c |  2 ++
 src/qemu/qemu_process.c   | 15 ++++++++++++---
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 17fa71c21b..54d8bd0d3a 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -9259,9 +9259,10 @@ qemuDomainAdjustMaxMemLock(virDomainObjPtr vm,
         vm->original_memlock = 0;
     }
 
-    /* Trying to set the memory locking limit to zero is a no-op */
-    if (virProcessSetMaxMemLock(vm->pid, bytes) < 0)
+    if (bytes > 0 &&
+        virProcessSetMaxMemLock(vm->pid, bytes) < 0) {
         return -1;
+    }
 
     return 0;
 }
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index d7231f68ae..e44931dcfa 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -2950,6 +2950,7 @@ qemuMigrationDstPrepareAny(virQEMUDriverPtr driver,
     }
 
     if (STREQ_NULLABLE(protocol, "rdma") &&
+        vm->def->mem.hard_limit > 0 &&
         virProcessSetMaxMemLock(vm->pid, vm->def->mem.hard_limit << 10) < 0) {
         goto stopjob;
     }
@@ -4199,6 +4200,7 @@ qemuMigrationSrcRun(virQEMUDriverPtr driver,
     switch (spec->destType) {
     case MIGRATION_DEST_HOST:
         if (STREQ(spec->dest.host.protocol, "rdma") &&
+            vm->def->mem.hard_limit > 0 &&
             virProcessSetMaxMemLock(vm->pid, vm->def->mem.hard_limit << 10) < 0) {
             goto exit_monitor;
         }
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 92e33707c0..c05cbe3570 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -7022,9 +7022,18 @@ qemuProcessLaunch(virConnectPtr conn,
      * significant amount of memory, so we need to set the limit accordingly */
     maxMemLock = qemuDomainGetMemLockLimitBytes(vm->def, false);
 
-    virCommandSetMaxMemLock(cmd, maxMemLock);
-    virCommandSetMaxProcesses(cmd, cfg->maxProcesses);
-    virCommandSetMaxFiles(cmd, cfg->maxFiles);
+    /* For all these settings, zero indicates that the limit should
+     * not be set explicitly and the default/inherited limit should
+     * be applied instead */
+    if (maxMemLock > 0)
+        virCommandSetMaxMemLock(cmd, maxMemLock);
+    if (cfg->maxProcesses > 0)
+        virCommandSetMaxProcesses(cmd, cfg->maxProcesses);
+    if (cfg->maxFiles > 0)
+        virCommandSetMaxFiles(cmd, cfg->maxFiles);
+
+    /* In this case, however, zero means that core dumps should be
+     * disabled, and so we always need to set the limit explicitly */
     virCommandSetMaxCoreSize(cmd, cfg->maxCore);
 
     VIR_DEBUG("Setting up security labelling");
-- 
2.26.2




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux