Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1335309 - Set optimal clock source in Windows guests using the guest agent [NEEDINFO]
Set optimal clock source in Windows guests using the guest agent
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-guest-agent (Show other bugs)
3.5.7
x86_64 Windows
high Severity high
: ovirt-4.0.2
: ---
Assigned To: Vinzenz Feenstra [evilissimo]
Petr Matyáš
: Improvement, Performance
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-05-11 17:21 EDT by Robert McSwain
Modified: 2018-03-19 09:18 EDT (History)
26 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Setting the USEPLATFORMCLOCK option in bcdedit to "yes" leads to degraded performance on the guest side when the Hyper-V extensions are enabled, which is the default for Red Hat Virtualization for the affected systems (Windows 2008 R2 Server and newer, Windows 7 and newer). The guest agent now removes this option on every start of the guest agent service unless this functionality is disabled in the configuration of the guest agent. When the option apply_timer_configuration in the general section is set to false, the agent will skip this behavior and leave the bcdedit configuration completely untouched.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-08-23 17:08:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
michal.skrivanek: needinfo? (rmcswain)
ylavi: needinfo? (rsibley)
lsvaty: testing_plan_complete-


Attachments (Terms of Use)
IOmeter 8k random wrts with SSD (46.25 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-05-24 17:34 EDT, Bob Sibley
no flags Details
IOmeter 8k random wrts with Fibre (29.39 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-05-24 17:38 EDT, Bob Sibley
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 60635 master MERGED windows: Apply timer usage parameters for best performance 2016-07-25 05:28 EDT
oVirt gerrit 61301 ovirt-4.0 MERGED windows: Apply timer usage parameters for best performance 2016-07-25 05:30 EDT
Red Hat Product Errata RHEA-2016:1700 normal SHIPPED_LIVE rhev-guest-tools-iso bug fix and enhancement update for RHV 4.0 2016-09-02 17:28:41 EDT

  None (edit)
Description Robert McSwain 2016-05-11 17:21:04 EDT
Description of problem:
Customer has several storage domains using Fibre Channel to connect back to a Nimble storage array. We have applied specific recommended settings for Nimble already.

We are testing using a VMWare Hypervisor/Host that connects to the same SAN switches on identical server hardware.  We are not re-installing.  There are 2 separate UCS blades with identical hardware setup. We are trying for a like-for-like configuration in every way.   The data store in VMWare uses Fibre Channel to the Nimble the same as RHEV.  The virtual disks are normal virtual disks. 

In the Testing Results docx file you'll see that the RHEV Windows 2012 R2 guest shows 11393 IO/sec and an average I/O response time of 7 msec, whereas the VMWare Windows 2012 R2 guest shows 65244 IO/sec and an average I/O response time of 1.2 msec. 

We would like to determine what can be done on the RHEV side to get better performance out of this VM.


Version-Release number of selected component (if applicable):
RHEV-M 3.5.7
Red Hat Enterprise Virtualization Hypervisor release 7.2 (20160105.1.el7ev)
Windows 2012 R2 Guests with virtio-win-1.7.2-2.el6.noarch

How reproducible:
100% (see screenshots in the Testing Results doc)

Steps to Reproduce:
1. Install Windows 2012 R2 as a guest in RHEV and VMWare
2. Install guest tools and virtio drivers in the guest
3. Use IOMeter to get performance results

Actual results:
VMWare performs approximately 5x better than RHEV on the same hardware

Expected results:
Similar performance results in both virtualization suites

Additional info:
Customer data coming in a future comment
Comment 5 Bob Sibley 2016-05-24 17:34 EDT
Created attachment 1161220 [details]
IOmeter 8k random wrts with SSD
Comment 6 Bob Sibley 2016-05-24 17:38 EDT
Created attachment 1161221 [details]
IOmeter 8k random wrts with Fibre
Comment 7 Bob Sibley 2016-05-24 17:53:57 EDT
I/O performance of w2k12r2 guest on two types of I/O Fibre and SSD.

Testing was performed on a w2k12r2 guest with updates.

Testing was done using IOmeter with a 20GB ntfs formated disk partion to exceed the guest memory. 

Different cache modes and aio were used. 

1. Hardware

- white box 2 Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- 256GB RAM
- Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD
				

2. Hardware

- white box 4 Intel(R) Xeon(R) CPU X7560  @ 2.27GHz
- 128GB RAM
- 2 ISP2532-based 8Gb Fibre Channel, 1 HP HSV300


 3. Guest machine:
- Win2012r2 w/updates
- virtio-win-0.1.117-1 drivers
- 1 and 7 vCPU
- 10GB RAM
- 30GB raw provisioned disk
- 50GB virtio disk
Comment 9 Yaniv Kaul 2016-07-05 07:33:08 EDT
Moving to agent, based on https://bugzilla.redhat.com/show_bug.cgi?id=1277353#c28
Comment 13 Vinzenz Feenstra [evilissimo] 2016-07-25 05:42:24 EDT
Same fix and impact as: https://bugzilla.redhat.com/show_bug.cgi?id=1354532

Copied information:

Windows XP, Windows Vista and Windows 2003 Server are no longer supported by us and therefore ignored

Windows 2008 Server does not have the USEPLATFORMCLOCK option at all and therefore it's not implemented - From Windows 2008 R2 and above and from Windows 7 and above we're now deleting the value from the configuration - Unless the ovirt guest agent configuration does not have set the 'general.apply_timer_configuration' value to false (if it is false we won't do anything)
Comment 15 Petr Matyáš 2016-07-28 11:22:52 EDT
Verified on 4.0.2-3
Comment 17 errata-xmlrpc 2016-08-23 17:08:53 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-1700.html

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