similar to: about sharing the hugepage memory segment between the host and the container

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thanks a lot you two, yes hugetlbfs is not mounted, when libvirtd is started… It was a long night. Did put it to fstab and since I do not allocate them on regular boots, it won’t eat my ram (that was the main consideration for doing it like this). As a last means before going to sleep, I added <qemu:arg value='-numa'/>

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:

Hi All, First time mailing here. I have installed on a CentOS 7.0 KVM (with DPDK and OVS) one Deep Packet Inspection VM. I have one channel and some virtual traffic generator. The traffic is lost between dpdk vhostuser and the DPI VM. The setup is attached. Any suggestions or ideas? Regarding the OVS+DPDK configuration, the following configuration is already made: - SELINUX is disabled - QEMU

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

> Fine, however Red Hat would also need a way to test ivshmem code, with > proper quality assurance (that also benefits upstream, of course). With > ivshmem this is not possible without the out-of-tree packages. You did not reply to my question: how to get the list of things that are/will be disabled by Redhat? About Redhat's QA, I do not care. About Qemu's QA, I do care ;) I

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

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

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

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 usable hugetlbfs mount for 16777216 KiB" where atlas is one of my guests and 16777216 KiB is the

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).

Il 13/06/2014 11:26, Vincent JARDIN ha scritto: >> Markus especially referred to parts *outside* QEMU: the server, the >> uio driver, etc. These out-of-tree, non-packaged parts of ivshmem >> are one of the reasons why Red Hat has disabled ivshmem in RHEL7. > > You made the right choices, these out-of-tree packages are not required. > You can use QEMU's ivshmem

Il 13/06/2014 11:26, Vincent JARDIN ha scritto: >> Markus especially referred to parts *outside* QEMU: the server, the >> uio driver, etc. These out-of-tree, non-packaged parts of ivshmem >> are one of the reasons why Red Hat has disabled ivshmem in RHEL7. > > You made the right choices, these out-of-tree packages are not required. > You can use QEMU's ivshmem

(+merging with Paolo's email because of overlaps) >> see inline (I am not on all mailing list, please, keep the cc list). >> >>> 1. ivshmem code needs work, but has no maintainer >> See David's contributions: >> http://patchwork.ozlabs.org/patch/358750/ > > We're grateful for David's patch for qemu-char.c, but this isn't ivshmem >

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

I am trying to connect a KVM-QEMU VM to OVS-DPDK vhostuser port. But, I am encountering a few errors. Since I am very new to libvrt and Linux I am not able to sort them out. Any guidance in this regard would be a great help. These are my System Logs: Mar 28 18:03:04 dpdk-OptiPlex-5040 libvirtd.service: 1529: debug : virCommandRunAsync:2429 : About to run LIBVIRT_LOG_OUTPUTS=3:stderr

Hi, On 12/12/18 3:56 PM, Michael S. Tsirkin wrote: > On Fri, Dec 07, 2018 at 06:52:31PM +0000, Jean-Philippe Brucker wrote: >> Sorry for the delay, I wanted to do a little more performance analysis >> before continuing. >> >> On 27/11/2018 18:10, Michael S. Tsirkin wrote: >>> On Tue, Nov 27, 2018 at 05:55:20PM +0000, Jean-Philippe Brucker wrote:

On 2018-12-12 3:27 pm, Auger Eric wrote: > Hi, > > On 12/12/18 3:56 PM, Michael S. Tsirkin wrote: >> On Fri, Dec 07, 2018 at 06:52:31PM +0000, Jean-Philippe Brucker wrote: >>> Sorry for the delay, I wanted to do a little more performance analysis >>> before continuing. >>> >>> On 27/11/2018 18:10, Michael S. Tsirkin wrote: >>>> On

On 2019/3/9 ??3:48, Andrea Arcangeli wrote: > Hello Jeson, > > On Fri, Mar 08, 2019 at 04:50:36PM +0800, Jason Wang wrote: >> Just to make sure I understand here. For boosting through huge TLB, do >> you mean we can do that in the future (e.g by mapping more userspace >> pages to kenrel) or it can be done by this series (only about three 4K >> pages were vmapped

On Tue, Mar 12, 2019 at 10:52:15AM +0800, Jason Wang wrote: > > On 2019/3/11 ??8:48, Michael S. Tsirkin wrote: > > On Mon, Mar 11, 2019 at 03:40:31PM +0800, Jason Wang wrote: > > > On 2019/3/9 ??3:48, Andrea Arcangeli wrote: > > > > Hello Jeson, > > > > > > > > On Fri, Mar 08, 2019 at 04:50:36PM +0800, Jason Wang wrote: > > > >

On 2019/3/11 ??8:48, Michael S. Tsirkin wrote: > On Mon, Mar 11, 2019 at 03:40:31PM +0800, Jason Wang wrote: >> On 2019/3/9 ??3:48, Andrea Arcangeli wrote: >>> Hello Jeson, >>> >>> On Fri, Mar 08, 2019 at 04:50:36PM +0800, Jason Wang wrote: >>>> Just to make sure I understand here. For boosting through huge TLB, do >>>> you mean we can do