asking for a blocker, since not setting <acpi> may have serious effect on some guests.
Francesco, I don't see the patch you've mentioned on 4.1 $ git log --grep I40859f2d57a19d60f4fa1e1faf442d072fa0993c ovirt/ovirt-4.1
(In reply to Dan Kenigsberg from comment #2) > Francesco, I don't see the patch you've mentioned on 4.1 > > $ git log --grep I40859f2d57a19d60f4fa1e1faf442d072fa0993c ovirt/ovirt-4.1 because we didn't backport it, it is a master only patch: $ git branch --contains a877434796eeb5af51368f6acdf8ed7c8bf33906 | grep -i ovirt $ so no released version is affected. Lowering priority because of this.
(In reply to Dan Kenigsberg from comment #1) > asking for a blocker, since not setting <acpi> may have serious effect on > some guests. No need for a blocker, see https://bugzilla.redhat.com/show_bug.cgi?id=1472286#c3
Oh, I thought Burman has seen it in ovirt-4.1.
(In reply to Dan Kenigsberg from comment #5) > Oh, I thought Burman has seen it in ovirt-4.1. Only master indeed.
patches merged to master -> MODIFIED
this bug doesn't need doc_text. A mistake slipped in a pre-alpha release. hot(un)plugging should just work as always did.
Hi, Testing this on latest master - 4.2.0-0.0.master.20170725202023.git561151b.el7.centos and vdsm-4.20.1-241.giteb37c05.el7.centos.x86_64 with same results on some guests. Moving back to assigned based on this. 2017-07-26 09:44:31,136+03 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVDSCommand] (DefaultQuartzScheduler8) [a419ccb] FINISH, FullListVDSCommand, return: [{acpiEnable=false
(In reply to Michael Burman from comment #9) > Hi, Hi, > Testing this on latest master - > 4.2.0-0.0.master.20170725202023.git561151b.el7.centos and > vdsm-4.20.1-241.giteb37c05.el7.centos.x86_64 with same results on some > guests. "Some guests" sounds a bit too vague :) When does the fix works, and when it doesnt? It should go like this: 1. NEW VM, with ACPI enabled (default in Engine) * bugged Vdsm -> ACPI disabled -> no hot(un)plug * patched Vdsm -> ACPI enabled -> hot(un)plug works 2. OLD VM, with ACPI enabled (default in Engine), created BEFORE the bug was introduced: * ACPI enabled -> hot(un)plug works 3. OLD VM, with ACPI enabled (default in Engine), **created with buggy Vdsm** * ACPI state was reported by Vdsm as disabled, and I'm quite sure this ended up in the Engine DB. So, if the VM starts again, it will get acpiEnable=false, and Vdsm will dutifully comply TL;DR: please provide one example -with Vdsm logs!- that Vdsm received acpiEnable=true in VM.create and reports acpiEnable=false in FullListVDSCommand
(In reply to Francesco Romani from comment #10) > (In reply to Michael Burman from comment #9) > > Hi, > > Hi, > > > Testing this on latest master - > > 4.2.0-0.0.master.20170725202023.git561151b.el7.centos and > > vdsm-4.20.1-241.giteb37c05.el7.centos.x86_64 with same results on some > > guests. > > "Some guests" sounds a bit too vague :) > When does the fix works, and when it doesnt? > > It should go like this: > 1. NEW VM, with ACPI enabled (default in Engine) > * bugged Vdsm -> ACPI disabled -> no hot(un)plug > * patched Vdsm -> ACPI enabled -> hot(un)plug works > > 2. OLD VM, with ACPI enabled (default in Engine), created BEFORE the bug was > introduced: > * ACPI enabled -> hot(un)plug works > > 3. OLD VM, with ACPI enabled (default in Engine), **created with buggy Vdsm** > * ACPI state was reported by Vdsm as disabled, and I'm quite sure this > ended up in the Engine DB. So, if the VM starts again, it will get > acpiEnable=false, and Vdsm will dutifully comply > > TL;DR: please provide one example -with Vdsm logs!- that Vdsm received > acpiEnable=true in VM.create and reports acpiEnable=false in > FullListVDSCommand Just to make it clear, are you saying that i need to create new VM?? If it had acpiEnable=false before the fix, then it will always start as false?
It actually make no sense. I have 5 VMs created together, 1 VM always get false, all others get true. Please contact me and i provide you the setup. will be faster. Thanks,
(In reply to Michael Burman from comment #11) > (In reply to Francesco Romani from comment #10) > > (In reply to Michael Burman from comment #9) > > > Hi, > > > > Hi, > > > > > Testing this on latest master - > > > 4.2.0-0.0.master.20170725202023.git561151b.el7.centos and > > > vdsm-4.20.1-241.giteb37c05.el7.centos.x86_64 with same results on some > > > guests. > > > > "Some guests" sounds a bit too vague :) > > When does the fix works, and when it doesnt? > > > > It should go like this: > > 1. NEW VM, with ACPI enabled (default in Engine) > > * bugged Vdsm -> ACPI disabled -> no hot(un)plug > > * patched Vdsm -> ACPI enabled -> hot(un)plug works > > > > 2. OLD VM, with ACPI enabled (default in Engine), created BEFORE the bug was > > introduced: > > * ACPI enabled -> hot(un)plug works > > > > 3. OLD VM, with ACPI enabled (default in Engine), **created with buggy Vdsm** > > * ACPI state was reported by Vdsm as disabled, and I'm quite sure this > > ended up in the Engine DB. So, if the VM starts again, it will get > > acpiEnable=false, and Vdsm will dutifully comply > > > > TL;DR: please provide one example -with Vdsm logs!- that Vdsm received > > acpiEnable=true in VM.create and reports acpiEnable=false in > > FullListVDSCommand > > Just to make it clear, are you saying that i need to create new VM?? > If it had acpiEnable=false before the fix, then it will always start as > false? To make sure the fix works (or doesn't) yes, we need to doublecheck creating a new VM. The problem is the following: 1. Engine start a VM with acpiEnable = True (default) 2. Vdsm, because of the bug, fails to set the flag, and reports acpiEnable = False 3. Engine reads back the value reported by Vdsm, and sets acpiEnable = False on the DB (<- this could be one Engine bug) 4. from now on, Engine will read the ACPI state from DB, and always send acpiEnable = false, regardless of the bug or the fix. 5. So even a correct working Vdsm will get acpiEnable = false, and this will prevent hot(un)plug to work. I agree this is highly unpratical, but we must also acknowledge that this happened on a pre-alpha snapshot, so no customer could be affected (once the bug is fixed of course). The users affected by this bug (testers and developers, I'd assume) can fix this issue running the following query (with Engine stopped): update vm_dynamic set acpi_enable=true where vm_guid in (...) one needs to set the list of vm_guid that needs to be fixed.
moving back, please test that according to suggestions above
Based on comment 13^^ moving to VERIFIED New VM - working as expected. acpiEnable = true and hotunplug working. Old VM with the bug - acpiEnable = false and hotunplug doesn't wokring and will never work for this VM. - Option1 to fix DB - Option2 to create new VM Verified on - 4.2.0-0.0.master.20170725202023.git561151b.el7.centos and vdsm-4.20.1-241.giteb37c05.el7.centos.x86_64
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.