Description of problem:
New tuned profile has to be introduced when cluster has both virt+gluster enabled.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Sanjay, with RHGS we have rhgs-sequential-io and rhgs-random-io profiles. With RHV, I think rhs-virtualization
In case of a node running both RHGS and RHV, do we need a new profile? Or which one of the above is to be used?
If this is not a question for you, please reassign
With RHV, we use virtual-host profile. The differences in the profiles are currently in these 3 values.
kernel.sched_migration_cost_ns which is set to 5000000 in virtual host and it is default value of 50000 for both rhs profiles.
This value is useful for environments that start and run many small VMs. We found that if VMs are relatively idle, they get moved around unless the sched_migration value is bumped up.
vm_dirty_ratio is set to
40 for virtual host
5 for rhs-random-io
20 for rhs-sequential-io
When the host reaches the vm_dirty_ratio threshold, it stops processing to flush dirty blocks. That's why we keep it significantly high for Virtual Host.
vm_dirty_background_ratio is set to
5 for Virtual Host
2 for rhs-random-io
10 for rhs-sequential-io
The host starts flushing dirty blocks in the background when it hits this threshold.
Based on this comparison and taking into account that in a Grafton environment, customers may run workloads with mixed I/O patterns, I think it makes sense to stay with the virtual-host configuration which has a balance between the 2 special I/O profiles for rhgs. That will also account for idle VMs not being moved around in a Grafton environment.
Thanks, Sanjay. I will change the bug to make sure virtual-host is set as default in HC cluster
Changing this from an RFE, as no new profile needed
We will make following changes to fix this bug.
1. 'virtual-host' will be added as one of the tuned profile in the cluster pop up. While creating/editing a cluster, user can choose this profile.
2. If there is no tuned profile is set on the cluster and cluster supports virt service then 'virtual-host' will be used as the default tuned profile.
Agreed with the Gluster team we can move Gluster bugs to ON_QA on engine build.
Created attachment 1265091 [details]
Verified and works fine with build Red Hat Virtualization Manager Version: 126.96.36.199-0.1.el7 and ovirt-host-deploy-1.6.0-1.el7ev.noarch
when there is no profile selected in the cluster and if cluster has virt service enabled then virtual-host will be used as the default tuned profile.
In HCI enviroment when hosts are added to the UI, virtual-host will be set as tuned profile.
[root@rhsqa-grafton6 ~]# tuned-adm list
- balanced - General non-specialized tuned profile
- desktop - Optmize for the desktop use-case
- latency-performance - Optimize for deterministic performance at the cost of increased power consumption
- network-latency - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
- network-throughput - Optimize for streaming network throughput. Generally only necessary on older CPUs or 40G+ networks.
- powersave - Optimize for low power consumption
- throughput-performance - Broadly applicable tuning that provides excellent performance across a variety of common server workloads. This is the default profile for RHEL7.
- virtual-guest - Optimize for running inside a virtual guest.
- virtual-host - Optimize for running KVM guests
Current active profile: virtual-host
when user creates a new cluster which has both virt and gluster services enabled virtual-host can be chosen as tuned-profile. Attaching a screenshot for the same.