We have an existing bug:
Bug 1063124 - fail to boot windows 2012 guest with '-cpu SandyBridge,hv_relaxed'

And removing hv_relaxed works around this issue.

(In reply to Chao Yang from comment #3)
> We have an existing bug:
> Bug 1063124 - fail to boot windows 2012 guest with '-cpu
> SandyBridge,hv_relaxed'
> 
> And removing hv_relaxed works around this issue.

Strange, almost as if it is a Windows bug. hv_relaxed is a Microsoft guest-side code only.
Vadim, are there side effects that you can think of?

Clarification:

- it is related to hv_relaxed flag passed to qemu-kvm
- this flag appeared recently in rhevm/vdsm (3.5)
- this flag has appeared in osinfo

os.windows_xp.devices.hyperv.enabled.value = true

- osinfo is inherited to other windows versions
- engine passes 'hypervEnable=true'

2015-01-07 15:22:49,588 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVdsCommand] (DefaultQuartzScheduler_Worker-95) [d55c73b] FINISH, FullListVdsCommand, return: [{displaySecurePort=-1, kvmEnable=true, nicModel=rtl8139,pv, keyboardLayout=en-us, guestDiskMapping={}, displayIp=10.34.63.223, pauseCode=NOERR, nice=0, displayNetwork=rhevm, timeOffset=0, transparentHugePages=true, vmId=512111ac-0692-405c-9c30-c2df35309576, acpiEnable=true, custom={}, spiceSslCipherSuite=DEFAULT, memSize=2048, smp=2, displayPort=5900, emulatedMachine=rhel6.5.0, vmType=kvm, status=Up, memGuaranteedSize=1024, display=vnc, pid=19499, smartcardEnable=false, bootMenuEnable=false, tabletEnable=true, spiceSecureChannels=smain,sinputs,scursor,splayback,srecord,sdisplay,susbredir,ssmartcard, smpCoresPerSocket=1, maxVCpus=16, hypervEnable=true, clientIp=, devices=[Ljava.lang.Object;@7b574541, vmName=jb-w2k12r2-2, cpuType=SandyBridge}], log id: 6ee308ce

- then vdsm checks

    def appendFeatures(self):
        """
        Add machine features to domain xml.

        Currently only
        <features>
            <acpi/>
        <features/>

        for hyperv:
        <features>
            <acpi/>
            <hyperv>
                <relaxed state='on'/>
            </hyperv>
        <features/>
        """

        if (utils.tobool(self.conf.get('acpiEnable', 'true')) or
           utils.tobool(self.conf.get('hypervEnable', 'false'))):
            features = self.dom.appendChildWithArgs('features')

        if utils.tobool(self.conf.get('acpiEnable', 'true')):
            features.appendChildWithArgs('acpi')

        if utils.tobool(self.conf.get('hypervEnable', 'false')):
            hyperv = XMLElement('hyperv')
            features.appendChild(hyperv)

            hyperv.appendChildWithArgs('relaxed', state='on')
            # turns off an internal Windows watchdog, and by doing so avoids
            # some high load BSODs.

- appends to xml domain

            <hyperv>
                <relaxed state='on'/>
            </hyperv>

- which passes hv_relaxed to qemu-kvm

...-cpu SandyBridge,hv_relaxed...

it seems this flag should not be passed for mentioned/impacted windows variants

fyi not related to cluster version in rhevm 3.5, i tried:

- rhel6.6 & 3.4 vdsm in 3.5 rhevm with 3.4 clstr - worked ok
- rhel6.6 & 3.5 vdsm in 3.5 rhevm with 3.4 clstr - not working
- rhel 6.5 & 3.4 vdsm in 3.4 rhevm with 3.4 clstr - worked ok
- rhel7 & vdsm 3.5 in 3.5 rhevm - worked ok

Jiri, do we have a confirmed list of Windows version affected by this?

might be needed to remove it altogether for now since we do not have differentiation in osinfo based on underlying hypervisor release

or a specific ad-hoc code dropping this on RHEL 6 at vdsm side

test - all had hv_relaxed, 3.5 vdsm/rhel6.6:

wxp - ok
w7 32bit - ok
w7 64bit - ok
w2k3 32bit - ok
w2k3 64bit - <not tested, no vm now>
w2k3r2 - ok
w2k8 32bit - ok
w2k8 64bit - ok
w2k8r2 - ok
w8 32bit - ok

w8 64bit - fail
w2k12 - fail
w8.1 32bit - <not tested, no vm now>
w8.1 64bit - fail
w2k12r2 - fail

RHEL 6.x is still the recommended platform (not yet RHEL 7.x) so, either tune osinfo to blacklist w8/w2k12 guests, or disable the feature alltogether.

I'd go first with the blacklist approach, especially considering that there is an underlying qemu issue which, once solved, will allow us to re-enable the feature everywhere.

posted patch on engine to add blacklist and try to save the known-good-and-tested-as-such guest windowses.

contingency plan is to disable the feature alltogether either on VDSM or on osinfo again.

for archives - all windows run ok on rhel7 with hv_relaxed flag

patches merged on all the relevant branches.

ok vt13.7

checked os variants and osinfo file (rhel6 host).

w2k12r2/w2k12 - without hv_relaxed
w8 64bit - without hv_relaxed
w8 32bit - with hv_relaxed
w2k8r2 - with hv_relaxed
...

tested also on RHEL7, no regression, all work ok

RHEV-M 3.5.0 has been released

I am gonna reopen this bug.

Customer is having this issue on RHEV-H 6.6-20150128 with Windows 8.

rhevm-backend-3.5.0-0.32.el6ev.noarch                       Tue Mar 24 14:34:20 2015


rhev-h7: w8 64bit hv_relaxed - ok
rhev-h6: w8 64bit hv_relaxed - fail

(In reply to akotov from comment #19)
> I am gonna reopen this bug.
> 
> Customer is having this issue on RHEV-H 6.6-20150128 with Windows 8.
> 
> rhevm-backend-3.5.0-0.32.el6ev.noarch                       Tue Mar 24
> 14:34:20 2015
> 
> 
> rhev-h7: w8 64bit hv_relaxed - ok
> rhev-h6: w8 64bit hv_relaxed - fail

On Engine side, this patch blacklists hv_relaxed and any other hyperV enlightenment change for windowses >= 8 (client) or >= 2012 (server), regardless what host version is running, node included

Confirmed to work as expected (almost).
The issue was customer is installing Windows 7 using PXE, and PXE environment runs on some limited version of Windows 8.

So the scenario is:

guest type = Windows 7 =>> Error Code: OxOOOOOO1E
guest type = Windows 8 =>> Windows 7 installs, then BSODs at first boot

workaround is to set guest type to Win8, install Win7, change guest type to Windows 7