similar to: HugePages - can't start guest that requires them

Yeah, Dominique, your wiki was one of the many docs I read through before/during/after starting down this primrose path... thanks for writing it. I'm an Arch user, and I couldn't find anything to indicate qemu, as its compiled for Arch, will look in /etc/default/qemu-kvm. And now that I've got the right page size, the instances are starting... The reason I want to use the page element

As I mentioned, I got the instances to launch... but they're only taking HugePages from "Node 0", when I believe my setup should pull from both nodes. [atlas] http://sprunge.us/FSEf [prometheus] http://sprunge.us/PJcR 2015-02-03 16:51:48 root@eanna i ~ # virsh start atlas Domain atlas started 2015-02-03 16:51:58 root@eanna i ~ # virsh start prometheus Domain prometheus started

*facepalm* Now that I'm re-reading the documentation it's obvious that <page/> and @nodeset are for the guest, "This tells the hypervisor that the guest should have its memory allocated using hugepages instead of the normal native page size." Pretty clear there. Thank you SO much for the guidance, I'll return to my tweaking. I'll report back here with my results.

On 09.02.2015 18:19, G. Richard Bellamy wrote: > First I'll quickly summarize my understanding of how to configure numa... > > In "//memoryBacking/hugepages/page[@nodeset]" I am telling libvirt to > use hugepages for the guest, and to get those hugepages from a > particular host NUMA node. No, @nodeset refers to guest NUMA nodes. > > In

On Fri, Jan 30, 2015 at 03:33:43PM -0800, G. Richard Bellamy wrote: >Hello All, > >I'm trying to enable hugepages, I've turned off THP (Transparent Huge >Pages), and enabled hugepages in memoryBacking, and set my 2MB >hugepages count via sysctl. > >I'm getting "libvirtd[5788]: Failed to autostart VM 'atlas': internal >error: Unable to find any

Regarding fine tuning my explanation about what system does de actual mounting of Hugepages, you?re probably right?. Thanks for the correction. On upstart systems (like Ubuntu) the mounting of Hugepages is done by the init script qemu-kvm.conf Van: G. Richard Bellamy [mailto:rbellamy at pteradigm.com] Verzonden: zondag 1 februari 2015 0:02 Aan: Dominique Ramaekers CC: libvirt-users at

Did you create a mount for the hugepages? If you did, that's maybe the problem. I did that also at first but with libvirt it isn't necessary and in my case, it broke hugepages... If I'm not mistaking, libvirt takes care of the hugepages mount. A while ago, I've written a wiki to use hugepages in libvirt and Ubuntu. https://help.ubuntu.com/community/KVM%20-%20Using%20Hugepages

First I'll quickly summarize my understanding of how to configure numa... In "//memoryBacking/hugepages/page[@nodeset]" I am telling libvirt to use hugepages for the guest, and to get those hugepages from a particular host NUMA node. In "//numatune/memory[@nodeset]" I am telling libvirt to pin the memory allocation to the guest from a particular host numa node. In

On Tue, Feb 10, 2015 at 1:14 AM, Michal Privoznik <mprivozn@redhat.com> wrote: > On 09.02.2015 18:19, G. Richard Bellamy wrote: >> First I'll quickly summarize my understanding of how to configure numa... >> >> In "//memoryBacking/hugepages/page[@nodeset]" I am telling libvirt to >> use hugepages for the guest, and to get those hugepages from a

On 04.02.2015 01:59, G. Richard Bellamy wrote: > As I mentioned, I got the instances to launch... but they're only > taking HugePages from "Node 0", when I believe my setup should pull > from both nodes. > > [atlas] http://sprunge.us/FSEf > [prometheus] http://sprunge.us/PJcR [pasting interesting nits from both XMLs] <domain type='kvm'

On 2014/9/25 2:05, Eric Blake wrote: > On 09/24/2014 02:05 AM, Linhaifeng wrote: >> Hi, >> >> I want to use virsh to create a VM with the qemu parameter '-object memory-backend-file,id=mem,size=2048M,mem-path=/mnt/huge,share=on -numa node,memdev=mem'. > > Looking at tests/qemuxml2argvdata/qemuxml2argv-hugepages-pages.args, I > see several instances of

Hi, I want to use this qemu command '-object memory-backend-file,id=mem,size=2048M,mem-path=/mnt/huge,share=on' with libvirt but i can't find the 'mem-path' and 'share' in the documentation. because the vhost-user backend based on 'share=on' parameter and libvirt support vhostuser i guess there maybe another way to support this parameter? this is my xml:

Hi, I’m struggling with virsh not detecting my hugepage mount. I have the following kernel command line: BOOT_IMAGE=/vmlinuz-4.8.13-gentoo root=/dev/mapper/gensd-gentoo ro quiet splash intel_iommu=on video=efifb:off,vesafb:off,simplefb:off splash=verbose,theme:livedvd-aurora kvm.ignore_msrs=1 transparent_hugepage=never hugepages=3072 softlevel=qemuvm My startup script outputs the following:

On 2014/10/8 16:57, Martin Kletzander wrote: > On Wed, Oct 08, 2014 at 10:03:47AM +0800, Linhaifeng wrote: >> Hi, >> >> I want to use this qemu command '-object memory-backend-file,id=mem,size=2048M,mem-path=/mnt/huge,share=on' with libvirt but i can't find the 'mem-path' and 'share' in the documentation. >> because the vhost-user backend

On 20.02.2015 21:32, G. Richard Bellamy wrote: > <snip/> > > I've modified my config [1] based on my understanding, and am running > into a new error. Basically I'm hitting the oom-killer [2] even though > the hard_limit [3] of memtune is below the total number of hugepages > set for that NUMA nodeset. > Just drop the hard_limit. It's a blackbox we should

Hello, I am working on implementing SEV support in OpenStack. There are some questions that came up in the discussion of the spec [0] [0] https://review.openstack.org/#/c/641994/ As far as i understand, the memory for SEV machines need to be pinned so that it doesn't migrate to swap and page migration. ROMS, UEFI pflash and video RAM should be pinned too. Initially we planned to use

Hi, I want to use virsh to create a VM with the qemu parameter '-object memory-backend-file,id=mem,size=2048M,mem-path=/mnt/huge,share=on -numa node,memdev=mem'. How to write the XML file?

We have implemented hugepage support for guests in following manner In our implementation we added a parameter hugepage_num which is specified in the config file of the DomU. It is the number of hugepages that the guest is guaranteed to receive whenever the kernel asks for hugepage by using its boot time parameter or reserving after booting (eg. Using echo XX > /proc/sys/vm/nr_hugepages).

This is the latest version of a patch that adds hugepage support to the Xen hypervisor in a PV environment. It is against the latest xen-unstable tree on xenbits.xensource.com. I believe this version addresses the comments made about the previous version of the patch. Hugepage support must be enabled via the hypervisor command line option "allowhugepage". It assumes the guest

[moderator note: I'm forwarding a stripped down version of the original mail which was rejected in the moderator queue. I stripped the 3.3 megabyte .tar.bz2 of the log file attachment, which is inappropriate for a technical list. Either trim the log to the relevant portion, or host the log externally and have your list email merely give a URL of the externally-hosted file] >