Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1335309

Summary: Set optimal clock source in Windows guests using the guest agent
Product: Red Hat Enterprise Virtualization Manager Reporter: Robert McSwain <rmcswain>
Component: ovirt-guest-agentAssignee: Vinzenz Feenstra [evilissimo] <vfeenstr>
Status: CLOSED ERRATA QA Contact: Petr Matyáš <pmatyas>
Severity: high Docs Contact:
Priority: high    
Version: 3.5.7CC: agkesos, alitke, amureini, bazulay, dshaks, ebills, fromani, jbelka, lsurette, lsvaty, michal.skrivanek, mkalinin, mkenneth, nsoffer, rbalakri, rmcswain, rsibley, sbonazzo, sherold, srevivo, tnisan, trichard, ycui, ykaul, ylavi
Target Milestone: ovirt-4.0.2Keywords: Improvement, Performance
Target Release: ---Flags: lsvaty: testing_plan_complete-
Hardware: x86_64   
OS: Windows   
Whiteboard:
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 21:08:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
IOmeter 8k random wrts with SSD
none
IOmeter 8k random wrts with Fibre none

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