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

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1331321

Summary:	QEMU: memory-backend-file doesn't fall back to regular RAM
Product:	Red Hat Enterprise Linux 7	Reporter:	Yumei Huang <yuhuang>
Component:	qemu-kvm-rhev	Assignee:	Igor Mammedov <imammedo>
Status:	CLOSED NOTABUG	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	chayang, juzhang, knoel, michen, qzhang, virt-maint, xfu
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-08-09 13:57:54 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Yumei Huang 2016-04-28 09:52:17 UTC

Description of problem:
Qemu quits directly when boot guest with no enough hugepages allocated. As https://bugzilla.redhat.com/show_bug.cgi?id=1329086#c3 says,  qemu should continue when no enough hugepages allocated. 

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.5.0-4.el7
kernel-3.10.0-373.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. allocate 600M hugepages on host 
#echo 300 > /proc/sys/vm/nr_hugepages

# cat /proc/meminfo | grep -i hugepage
AnonHugePages:      6144 kB
HugePages_Total:     300
HugePages_Free:      300
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

# mount
none on /mnt/kvm_hugepage type hugetlbfs (rw,relatime,seclabel,pagesize=2048K)

2. boot guest with 1G hugepage
/usr/libexec/qemu-kvm  -m 1G,slots=4,maxmem=32G -smp 4 \

-object memory-backend-file,mem-path=/mnt/kvm_hugepage,size=1G,id=mem-mem1   -device pc-dimm,id=dimm-mem1,memdev=mem-mem1 \

-drive file=/home/guest/RHEL-Server-7.3-64-virtio.qcow2,id=drive-virtio-disk1,media=disk,cache=none,snapshot=off,format=qcow2,aio=native,if=none  -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,bootindex=0  -monitor stdio -vnc :0

3.

Actual results:
Qemu quits, and prints:
"qemu-kvm: -object memory-backend-file,mem-path=/mnt/kvm_hugepage,size=1G,id=mem-mem1: unable to map backing store for hugepages: Cannot allocate memory"


Expected results:
Qemu should continue and not quit. 

Additional info:

Comment 2 Luiz Capitulino 2016-04-29 13:45:54 UTC

Igor, shouldn't memory-backend-file fall back to regular RAM the same way -mem-path does? If not, then I think it's a good idea to document the difference in semantics in the manpage.

Comment 3 Igor Mammedov 2016-08-09 13:57:54 UTC

(In reply to Luiz Capitulino from comment #2)
> Igor, shouldn't memory-backend-file fall back to regular RAM the same way
> -mem-path does? If not, then I think it's a good idea to document the
> difference in semantics in the manpage.

I don't think that it ever did nor should,
it's configuration error and user should fix it either by switching to ram backend or allocating more hugepages instead of silent fallback and getting performance regressions.

I'd do the same for -mem-path, but that would break 'broken' setups out there
so it can't be fixed and we have to live with it.