4:44 p.m.
On 19/04/17 14:01 +0200, Gianluca Cecchi wrote:
On Wed, Apr 19, 2017 at 8:03 AM, Michal Skrivanek
<mskrivan(a)redhat.com>
wrote:
>
> Why not reserving regular hugepages for VMs on boot?
Do you mean at hypervisor level? In this case it is what I'm doing normally
for physical servers where I install Oracle RDBMS
> then you can use
> it with vdsm hook for that Oracle VM.
Which hook are you referring?
This one:
http://www.ovirt.org/develop/developer-guide/vdsm/hook/hugepages/
?
In case is it still current? In the sense that I need to mount the
hugetblfs virtual file system at hst level?
The hook description seems low detailed...
Normally if I want oracle user able to use huge pages on physical server, I
have to specify
#
# Huge pages
#
vm.hugetlb_shm_group = 2000
# 18GB allocatable
vm.nr_hugepages = 9216
#
where 2000 is the group id for dba group, the main group of oracle user
How to map this with vrtualization?
Eg:
1) vm.hugetlb_shm_group at hypervisor side should be set to the group of
the qemu user as the qemu-kvm process runs with it?
2) Then I have to set VM for VM the hugepages=xxx value in the hook and
that will bypass the sysctl.conf configuration in the guest?
3) I presume I have to set the vm.hugetlb_shm_group parameter at guest
level....
If you are using recent CentOS (or I guess Fedora), there isn't any
extra setup required. Just create the custom property:
On the host where engine is running:
$ engine-config -s "UserDefinedVMProperties=hugepages=^.*$"
$ service ovirt-engine restart
and you should see 'hugepages' when editing a VM under custom properties.
Set the number to (desired memory / 2048) and you're good to go. The
VM will run with it's memory backed by hugepages. If you need
hugepages even inside the VM, do whatever you would do on a physical
host.
mpolednik
Thanks,
Gianluca
> It improves VM performance in
> general, the only drawback is less flexibility since that memory can't
> be used by others unless they specifically ask for hugepages.
>
This seems to confirm that I have to set a statich sysctl.conf entry at
hypervisor level such as
vm.nr_hugepages = YYYY
> Also, I suppose you disable KSM, and I'm not sure about ballooning,
> unless you need it I'd disable it too.
>
I kept the defaults at the moment that I suppose should be
a) KSM disabled
ksm has been configured to start by default as normally, but ksmtuned has
been disabled:
[g.cecchi@ov300 ~]$ sudo systemctl status ksm
● ksm.service - Kernel Samepage Merging
Loaded: loaded (/usr/lib/systemd/system/ksm.service; enabled; vendor
preset: enabled)
Active: active (exited) since Tue 2017-04-11 11:07:28 CEST; 1 weeks 1
days ago
Process: 976 ExecStart=/usr/libexec/ksmctl start (code=exited,
status=0/SUCCESS)
Main PID: 976 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/ksm.service
Apr 11 11:07:28 ov300.datacenter.polimi.it systemd[1]: Starting Kernel
Samepage Merging...
Apr 11 11:07:28 ov300.datacenter.polimi.it systemd[1]: Started Kernel
Samepage Merging.
[g.cecchi@ov300 ~]$ sudo systemctl status ksmtuned
● ksmtuned.service - Kernel Samepage Merging (KSM) Tuning Daemon
Loaded: loaded (/usr/lib/systemd/system/ksmtuned.service; disabled;
vendor preset: disabled)
Active: inactive (dead)
[g.cecchi@ov300 ~]$
b) ballooning enabled for a newly created VM unless I explicitly disable it
(at least I see this happens in 4.1.1)
What to do for a) and b) to not interfere with huge pages?
> The hook is being improved right now in master, but it should be
> usable in stable too.
>
>
I will be happy to test and verify and contribute to its description, as
soon as I understand its usage....
Gianluca
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users