We are reserving 2 CPU and 16G RAM for the hypervisor. I haven't seen any OOM errors. Where should I look for those? -----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Monday, February 3, 2020 2:47 PM To: Albert Braden <albertb@synopsys.com>; OpenStack Discuss ML <openstack-discuss@lists.openstack.org> Subject: Re: Virtio memory balloon driver On Mon, 2020-02-03 at 21:36 +0000, Albert Braden wrote:
When we build a Centos 7 VM with 1.4T RAM it fails with "[ 17.797177] BUG: unable to handle kernel paging request at ffff988b19478000"
I asked in #centos and they asked me to show a list of devices from a working VM (if I use 720G RAM it works). This is the list:
[root@alberttest1 ~]# lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device 00:04.0 SCSI storage controller: Red Hat, Inc. Virtio block device 00:05.0 SCSI storage controller: Red Hat, Inc. Virtio block device 00:06.0 SCSI storage controller: Red Hat, Inc. Virtio block device 00:07.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory balloon [root@alberttest1 ~]# lsusb Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
They suspect that the "Virtio memory balloon" driver is causing the problem, and that we should disable it. I googled around and found this:
It looks like memory ballooning is deprecated. How can I get rid of the driver? https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linux-2Dkvm.org_page_Projects_auto-2Dballooning&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=XrJBXYlVPpvOXkMqGPz6KucRW_ils95ZMrEmlTflPm8&m=iMCOz64cWwXgiqbpObDBdGZPUoLuQp4G931VKc_hqxI&s=uEnvgAhTPKxJpvz6a3bQisI9406ul8Q2SSHDCV1lqvU&e= states that no qemu that exists today implements that feature but the fact you see it in lspci seams to be in conflict with that. there are several refernce to the feature in later release of qemu and it is documented in libvirt https://urldefense.proofpoint.com/v2/url?u=https-3A__libvirt.org_formatdomain.html-23elementsMemBalloon&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=XrJBXYlVPpvOXkMqGPz6KucRW_ils95ZMrEmlTflPm8&m=iMCOz64cWwXgiqbpObDBdGZPUoLuQp4G931VKc_hqxI&s=DSej4fERS8HGIYb7CaIkbVBpssWtSxCbBRxukkAH0rI&e=
there is no way to turn it off specificly currently and im not aware of it being deprecated. the guest will not interact witht he vitio memory balloon by default. it is there too allow the guest to free memory and retrun it to the host to allow copperation between the guests and host to enable memory oversubscription. i belive this normally need the qemu guest agent to be deploy to work fully. with a 1.4TB vm how much memory have you reserved on the host. qemu will need memory to implement the vm emulation and this tends to increase as the guess uses more resouces. my first incliantion would be to check it the vm was killed as a result of a OOM event on the host.