Bug 1380739 - virtual-host to be default tuned profile when cluster has both virt+gluster enabled.
Summary: virtual-host to be default tuned profile when cluster has both virt+gluster e...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Gluster
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium vote
Target Milestone: ovirt-4.1.0-beta
: 4.1.0.2
Assignee: Ramesh N
QA Contact: RamaKasturi
URL:
Whiteboard:
Depends On:
Blocks: Gluster-HC-2
TreeView+ depends on / blocked
 
Reported: 2016-09-30 12:47 UTC by RamaKasturi
Modified: 2017-03-27 11:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-27 11:07:47 UTC
oVirt Team: Gluster
rule-engine: ovirt-4.1+
rule-engine: planning_ack+
sabose: devel_ack+
sasundar: testing_ack+


Attachments (Terms of Use)
gluster_cluster_tuned_profile (163.81 KB, image/png)
2017-03-21 13:56 UTC, RamaKasturi
no flags Details


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 69452 master MERGED set 'virtual-host' as the default tuned profile 2017-01-03 12:59:35 UTC
oVirt gerrit 69489 ovirt-host-deploy-1.6 MERGED set 'virtual-host' as the default tuned profile 2017-01-09 08:18:14 UTC
oVirt gerrit 69558 master MERGED gluster: Add 'virtual-host' tuned profile 2017-01-09 08:10:46 UTC
oVirt gerrit 69821 ovirt-engine-4.1 MERGED gluster: Add 'virtual-host' tuned profile 2017-01-09 10:44:39 UTC
oVirt gerrit 70311 master MERGED packaging: spec: require newer ovirt-host-deploy 2017-01-13 16:31:52 UTC
oVirt gerrit 70312 ovirt-engine-4.1 MERGED packaging: spec: require newer ovirt-host-deploy 2017-01-13 18:45:28 UTC

Description RamaKasturi 2016-09-30 12:47:59 UTC
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):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Sahina Bose 2016-11-22 05:43:19 UTC
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

Comment 2 Sanjay Rao 2016-11-30 16:14:09 UTC
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.

Comment 3 Sahina Bose 2016-12-08 14:46:12 UTC
Thanks, Sanjay. I will change the bug to make sure virtual-host is set as default in HC cluster

Comment 4 Sahina Bose 2016-12-16 06:03:11 UTC
Changing this from an RFE, as no new profile needed

Comment 5 Ramesh N 2017-01-03 06:25:28 UTC
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.

Comment 6 Eyal Edri 2017-01-23 08:28:46 UTC
Agreed with the Gluster team we can move Gluster bugs to ON_QA on engine build.

Comment 7 RamaKasturi 2017-03-21 13:56:57 UTC
Created attachment 1265091 [details]
gluster_cluster_tuned_profile

Comment 8 RamaKasturi 2017-03-21 13:57:42 UTC
Verified and works fine with build Red Hat Virtualization Manager Version: 4.1.1.2-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
Available profiles:
- 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.


Note You need to log in before you can comment on or make changes to this bug.