This reverts commit c2e60ad0e5124482942164e5fec088157f5e716a.
Turns out this check is excessively strict: there are ways
other than <memtune><hard_limit> to raise the memory locking
limit for QEMU processes, one prominent example being
tweaking /etc/security/limits.conf.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1431793
---
src/qemu/qemu_domain.c | 10 ----------
tests/qemuxml2argvdata/qemuxml2argv-mlock-on.xml | 3 ---
2 files changed, 13 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index c239a06..8fa43f2 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -2919,16 +2919,6 @@ qemuDomainDefValidate(const virDomainDef *def,
}
}
- /* Memory locking can only work properly if the memory locking limit
- * for the QEMU process has been raised appropriately: the default one
- * is extrememly low, so there's no way the guest will fit in there */
- if (def->mem.locked && !virMemoryLimitIsSet(def->mem.hard_limit)) {
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("Setting <memoryBacking><locked> requires
"
- "<memtune><hard_limit> to be set as
well"));
- goto cleanup;
- }
-
if (qemuDomainDefValidateVideo(def) < 0)
goto cleanup;
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-mlock-on.xml
b/tests/qemuxml2argvdata/qemuxml2argv-mlock-on.xml
index 2046663..20a5eaa 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-mlock-on.xml
+++ b/tests/qemuxml2argvdata/qemuxml2argv-mlock-on.xml
@@ -3,9 +3,6 @@
<uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
<memory unit='KiB'>219136</memory>
<currentMemory unit='KiB'>219136</currentMemory>
- <memtune>
- <hard_limit unit='KiB'>256000</hard_limit>
- </memtune>
<memoryBacking>
<locked/>
</memoryBacking>
--
2.7.4