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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
