Bug 1335309 - Set optimal clock source in Windows guests using the guest agent
Summary: Set optimal clock source in Windows guests using the guest agent
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-guest-agent
Version: 3.5.7
Hardware: x86_64
OS: Windows
high
high
Target Milestone: ovirt-4.0.2
: ---
Assignee: Vinzenz Feenstra [evilissimo]
QA Contact: Petr Matyáš
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-11 21:21 UTC by Robert McSwain
Modified: 2023-09-14 03:22 UTC (History)
25 users (show)

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.
Clone Of:
Environment:
Last Closed: 2016-08-23 21:08:53 UTC
oVirt Team: Virt
Target Upstream Version:
Embargoed:
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 21:34 UTC, Bob Sibley
no flags Details
IOmeter 8k random wrts with Fibre (29.39 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-05-24 21:38 UTC, Bob Sibley
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:1700 0 normal SHIPPED_LIVE rhev-guest-tools-iso bug fix and enhancement update for RHV 4.0 2016-09-02 21:28:41 UTC
oVirt gerrit 60635 0 master MERGED windows: Apply timer usage parameters for best performance 2020-08-04 09:49:42 UTC
oVirt gerrit 61301 0 ovirt-4.0 MERGED windows: Apply timer usage parameters for best performance 2020-08-04 09:49:43 UTC

Description Robert McSwain 2016-05-11 21:21:04 UTC
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 21:34:15 UTC
Created attachment 1161220 [details]
IOmeter 8k random wrts with SSD

Comment 6 Bob Sibley 2016-05-24 21:38:01 UTC
Created attachment 1161221 [details]
IOmeter 8k random wrts with Fibre

Comment 7 Bob Sibley 2016-05-24 21:53:57 UTC
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 11:33:08 UTC
Moving to agent, based on https://bugzilla.redhat.com/show_bug.cgi?id=1277353#c28

Comment 13 Vinzenz Feenstra [evilissimo] 2016-07-25 09:42:24 UTC
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 15:22:52 UTC
Verified on 4.0.2-3

Comment 17 errata-xmlrpc 2016-08-23 21:08:53 UTC
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

Comment 18 Red Hat Bugzilla 2023-09-14 03:22:31 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


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