On Mar 20, 2019, at 12:42 PM, Ryan Barry <rbarry@redhat.com> wrote:

On Wed, Mar 20, 2019, 1:16 PM Darrell Budic <budic@onholyground.com> wrote:
Inline:

On Mar 20, 2019, at 4:25 AM, Roy Golan <rgolan@redhat.com> wrote:

On Mon, 18 Mar 2019 at 22:14, Darrell Budic <budic@onholyground.com> wrote:
I agree, been checking some of my more disk intensive VMs this morning, switching them to noop definitely improved responsiveness. All the virtio ones I’ve found were using deadline (with RHEL/Centos guests), but some of the virt-scsi were using deadline and some were noop, so I’m not sure of a definitive answer on that level yet. 

For the hosts, it depends on what your backend is running. With a separate storage server on my main cluster, it doesn’t matter what the hosts set for me. You mentioned you run hyper converged, so I’d say it depends on what your disks are. If you’re using SSDs, go none/noop as they don’t benefit from the queuing. If they are HDDs, I’d test cfq or deadline and see which gave better latency and throughput to your vms. I’d guess you’ll find deadline to offer better performance, but cfq to share better amongst multiple VMs. Unless you use ZFS underneath, then go noop and let ZFS take care of it.

On Mar 18, 2019, at 2:05 PM, Strahil <hunter86_bg@yahoo.com> wrote:

Hi Darrel,

Still, based on my experience we shouldn't queue our I/O in the VM, just to do the same in the Host.

I'm still considering if I should keep deadline  in my hosts or to switch to 'cfq'.
After all, I'm using Hyper-converged oVirt and this needs testing.
What I/O scheduler  are  you using on the  host?


Our internal scale team is testing now 'throughput-performance' tuned profile and it gives
promising results, I suggest you try it as well.
We will go over the results of a comparison against the virtual-guest profile
, if there will be evidence for improvements we will set it as the default (if it won't degrade small,medium scale envs). 

I don’t think that will make a difference in this case. Both virtual-host and virtual-guest include the throughput-performance profile, just with “better” virtual memory tunings for guest and hosts. None of those 3 modify the disk queue schedulers, by default, at least not on my Centos 7.6 systems.

Re my testing, I have virtual-host on my hosts and virtual-guest on my guests already.

Unfortunately, the ideal scheduler really depends on storage configuration. Gluster, ZFS, iSCSI, FC, and NFS don't align on a single "best" configuration (to say nothing of direct LUNs on guests), then there's workload considerations.

The scale team is aiming for a balanced "default" policy rather than one which is best for a specific environment.

That said, I'm optimistic that the results will let us give better recommendations if your workload/storage benefits from a different scheduler

Agreed, but that wasn’t my point, I was commenting that those tuned profiles do not set schedulers, so that won’t make a difference, disk scheduler wise. Or are they testing changes to the default policy config? Good point on direct LUNs too.

And a question, why not virtual-guest if you’re talking about in guest/engine defaults? Or are they testing host profiles, in which case the question becomes why not virtual-host? Or am I missing where they are testing the scheduler?

I’m already using virtual-host on my hosts, which appears to have been set by the ovirt node setup process, and virtual-guest in my RHEL based guests, which I’ve been setting with puppet for a long time now.