> On 8 Apr 2020, at 11:32, Michal Skrivanek <michal.skrivanek(a)redhat.com&gt; wrote: > > Eh, so no, still not correct. Steven/Shmuel, I guess it could be your [1] or maybe other related recent patches from you, but OST is now broken (again). > With [2] finally fixing the cluster creation OST now runs with a Q35 seabios (as it was supposed to, but wasn’t until now), and the vm2 which has a custom emulated machine of i440fx-rhel-7.4.0 doesn’t run anymore, because apparently it is launched as a q35 VM for the first time, and then failing restart ever since. Sorry, my bad, it’s really getting confusing with the amount of breakages:) It should be fixed just in OST because using a custom i440fx type in a Cluster with q35/seabios is invalid. Well, that’s easy...

> > Please fix ASAP > > Thanks, > michal > > [1] https://gerrit.ovirt.org/#/c/107785/ > [2] https://gerrit.ovirt.org/#/c/108237/ _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW...

On 8 Apr 2020, at 13:52, Dominik Holler <dholler(a)redhat.com&gt; wrote: On Wed, Apr 8, 2020 at 1:35 PM Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: > On 8 Apr 2020, at 11:32, Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: > > Eh, so no, still not correct. Steven/Shmuel, I guess it could be your [1] or maybe other related recent patches from you, but OST is now broken (again). > With [2] finally fixing the cluster creation OST now runs with a Q35 seabios (as it was supposed to, but wasn’t until now), and the vm2 which has a custom emulated machine of i440fx-rhel-7.4.0 doesn’t run anymore, because apparently it is launched as a q35 VM for the first time, and then failing restart ever since. Sorry, my bad, it’s really getting confusing with the amount of breakages:) It should be fixed just in OST because using a custom i440fx type in a Cluster with q35/seabios is invalid. Well, that’s easy... If I run networking-suite-master with additional repo https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/ <https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/> the VMs will use pc-i440fx-rhel8.1.0 type [1]. Is this the same problem, or is this another one?

[1] https://paste.centos.org/view/bff03f73 <https://paste.centos.org/view/bff03f73> > > Please fix ASAP > > Thanks, > michal > > [1] https://gerrit.ovirt.org/#/c/107785/ <https://gerrit.ovirt.org/#/c/107785/> > [2] https://gerrit.ovirt.org/#/c/108237/ <https://gerrit.ovirt.org/#/c/108237/> _______________________________________________ Devel mailing list -- devel(a)ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave(a)ovirt.org <mailto:devel-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW...

On 8 Apr 2020, at 14:55, Dominik Holler <dholler(a)redhat.com&gt; wrote: On Wed, Apr 8, 2020 at 2:48 PM Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: > On 8 Apr 2020, at 13:52, Dominik Holler <dholler(a)redhat.com <mailto:dholler@redhat.com>> wrote: > > > > On Wed, Apr 8, 2020 at 1:35 PM Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: > > > On 8 Apr 2020, at 11:32, Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: > > > > Eh, so no, still not correct. Steven/Shmuel, I guess it could be your [1] or maybe other related recent patches from you, but OST is now broken (again). > > With [2] finally fixing the cluster creation OST now runs with a Q35 seabios (as it was supposed to, but wasn’t until now), and the vm2 which has a custom emulated machine of i440fx-rhel-7.4.0 doesn’t run anymore, because apparently it is launched as a q35 VM for the first time, and then failing restart ever since. > > Sorry, my bad, it’s really getting confusing with the amount of breakages:) > It should be fixed just in OST because using a custom i440fx type in a Cluster with q35/seabios is invalid. > Well, that’s easy... > > > If I run networking-suite-master with additional repo > https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/ <https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/> > the VMs will use > pc-i440fx-rhel8.1.0 type [1]. > > Is this the same problem, or is this another one? I don’t know, you didn’t say what problem you've seen pc-i440fx-rhel8.1.0 type seems to be not valid.

> > [1] > https://paste.centos.org/view/bff03f73 <https://paste.centos.org/view/bff03f73> > > > > > > > > Please fix ASAP > > > > Thanks, > > michal > > > > [1] https://gerrit.ovirt.org/#/c/107785/ <https://gerrit.ovirt.org/#/c/107785/> > > [2] https://gerrit.ovirt.org/#/c/108237/ <https://gerrit.ovirt.org/#/c/108237/> > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org <mailto:devel@ovirt.org> > To unsubscribe send an email to devel-leave(a)ovirt.org <mailto:devel-leave@ovirt.org> > Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> > List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW...

On 9 Apr 2020, at 10:35, Dominik Holler <dholler(a)redhat.com&gt; wrote: On Wed, Apr 8, 2020 at 5:34 PM Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: > On 8 Apr 2020, at 14:55, Dominik Holler <dholler(a)redhat.com <mailto:dholler@redhat.com>> wrote: > > > > On Wed, Apr 8, 2020 at 2:48 PM Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: > > >> On 8 Apr 2020, at 13:52, Dominik Holler <dholler(a)redhat.com <mailto:dholler@redhat.com>> wrote: >> >> >> >> On Wed, Apr 8, 2020 at 1:35 PM Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: >> >> > On 8 Apr 2020, at 11:32, Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: >> > >> > Eh, so no, still not correct. Steven/Shmuel, I guess it could be your [1] or maybe other related recent patches from you, but OST is now broken (again). >> > With [2] finally fixing the cluster creation OST now runs with a Q35 seabios (as it was supposed to, but wasn’t until now), and the vm2 which has a custom emulated machine of i440fx-rhel-7.4.0 doesn’t run anymore, because apparently it is launched as a q35 VM for the first time, and then failing restart ever since. >> >> Sorry, my bad, it’s really getting confusing with the amount of breakages:) >> It should be fixed just in OST because using a custom i440fx type in a Cluster with q35/seabios is invalid. >> Well, that’s easy... >> >> >> If I run networking-suite-master with additional repo >> https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/ <https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/> >> the VMs will use >> pc-i440fx-rhel8.1.0 type [1]. >> >> Is this the same problem, or is this another one? > > I don’t know, you didn’t say what problem you've seen > > > > pc-i440fx-rhel8.1.0 type seems to be not valid. it’s not. I don’t know how/where you create the VMs or the Cluster in network suite. You need to check it’s using the default and not something hardcoded… It is using defaults. It is also easy to reproduce, just import the cirros image as a template and create a VM with "other OS" from this template.

> >> >> [1] >> https://paste.centos.org/view/bff03f73 <https://paste.centos.org/view/bff03f73> >> >> >> >> >> > >> > Please fix ASAP >> > >> > Thanks, >> > michal >> > >> > [1] https://gerrit.ovirt.org/#/c/107785/ <https://gerrit.ovirt.org/#/c/107785/> >> > [2] https://gerrit.ovirt.org/#/c/108237/ <https://gerrit.ovirt.org/#/c/108237/> >> _______________________________________________ >> Devel mailing list -- devel(a)ovirt.org <mailto:devel@ovirt.org> >> To unsubscribe send an email to devel-leave(a)ovirt.org <mailto:devel-leave@ovirt.org> >> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> >> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> >> List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW... >

On Fri, Apr 10, 2020 at 8:13 AM Michal Skrivanek < michal.skrivanek(a)redhat.com&gt; wrote: > > > On 9 Apr 2020, at 10:35, Dominik Holler <dholler(a)redhat.com&gt; wrote: > > > > On Wed, Apr 8, 2020 at 5:34 PM Michal Skrivanek < > michal.skrivanek(a)redhat.com&gt; wrote: > >> >> >> On 8 Apr 2020, at 14:55, Dominik Holler <dholler(a)redhat.com&gt; wrote: >> >> >> >> On Wed, Apr 8, 2020 at 2:48 PM Michal Skrivanek < >> michal.skrivanek(a)redhat.com&gt; wrote: >> >>> >>> >>> On 8 Apr 2020, at 13:52, Dominik Holler <dholler(a)redhat.com&gt; wrote: >>> >>> >>> >>> On Wed, Apr 8, 2020 at 1:35 PM Michal Skrivanek < >>> michal.skrivanek(a)redhat.com&gt; wrote: >>> >>>> >>>> > On 8 Apr 2020, at 11:32, Michal Skrivanek < >>>> michal.skrivanek(a)redhat.com&gt; wrote: >>>> > >>>> > Eh, so no, still not correct. Steven/Shmuel, I guess it could be >>>> your [1] or maybe other related recent patches from you, but OST is now >>>> broken (again). >>>> > With [2] finally fixing the cluster creation OST now runs with a Q35 >>>> seabios (as it was supposed to, but wasn’t until now), and the vm2 which >>>> has a custom emulated machine of i440fx-rhel-7.4.0 doesn’t run anymore, >>>> because apparently it is launched as a q35 VM for the first time, and then >>>> failing restart ever since. >>>> >>>> Sorry, my bad, it’s really getting confusing with the amount of >>>> breakages:) >>>> It should be fixed just in OST because using a custom i440fx type in a >>>> Cluster with q35/seabios is invalid. >>>> Well, that’s easy... >>>> >>>> >>> If I run networking-suite-master with additional repo >>> https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/ >>> the VMs will use >>> >>> - pc-i440fx-rhel8.1.0 type [1]. >>> >>> >>> Is this the same problem, or is this another one? >>> >>> >>> I don’t know, you didn’t say what problem you've seen >>> >>> >> >> pc-i440fx-rhel8.1.0 type seems to be not valid. >> >> >> it’s not. I don’t know how/where you create the VMs or the Cluster in >> network suite. You need to check it’s using the default and not something >> hardcoded… >> >> > It is using defaults. > It is also easy to reproduce, just import the cirros image as a template > and create a VM with "other OS" from this template. > > > ah, glance import, yeah, that seems to be creating wrong templates. you > could tell easily in UI it’s asking you that there’s a disrepancy between > template’s and cluster’s chipset. > - glance import should use q35 because that’s the new default > - vm from template should drop the devices when there’s a difference in > cluster > > Needs to be fixed. > > Is there already a bug reported, or should I report one?

as a workaround, you could probably explicitly set the machine type as vm2 > does in basic suite > > Thanks, > michal > > > >> >> >>> >>> [1] >>> https://paste.centos.org/view/bff03f73 >>> >>> - >>> >>> >>> >>> >>> >>>> > >>>> > Please fix ASAP >>>> > >>>> > Thanks, >>>> > michal >>>> > >>>> > [1] https://gerrit.ovirt.org/#/c/107785/ >>>> > [2] https://gerrit.ovirt.org/#/c/108237/ >>>> _______________________________________________ >>>> Devel mailing list -- devel(a)ovirt.org >>>> To unsubscribe send an email to devel-leave(a)ovirt.org >>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html >>>> oVirt Code of Conduct: >>>> https://www.ovirt.org/community/about/community-guidelines/ >>>> List Archives: >>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW... >>>> >>> >>> >> >

On 14 Apr 2020, at 11:05, Dominik Holler <dholler(a)redhat.com&gt; wrote:  On Tue, Apr 14, 2020 at 10:25 AM Dominik Holler <dholler(a)redhat.com&gt; wrote: > > > On Fri, Apr 10, 2020 at 8:13 AM Michal Skrivanek < > michal.skrivanek(a)redhat.com&gt; wrote: > >> >> >> On 9 Apr 2020, at 10:35, Dominik Holler <dholler(a)redhat.com&gt; wrote: >> >> >> >> On Wed, Apr 8, 2020 at 5:34 PM Michal Skrivanek < >> michal.skrivanek(a)redhat.com&gt; wrote: >> >>> >>> >>> On 8 Apr 2020, at 14:55, Dominik Holler <dholler(a)redhat.com&gt; wrote: >>> >>> >>> >>> On Wed, Apr 8, 2020 at 2:48 PM Michal Skrivanek < >>> michal.skrivanek(a)redhat.com&gt; wrote: >>> >>>> >>>> >>>> On 8 Apr 2020, at 13:52, Dominik Holler <dholler(a)redhat.com&gt; wrote: >>>> >>>> >>>> >>>> On Wed, Apr 8, 2020 at 1:35 PM Michal Skrivanek < >>>> michal.skrivanek(a)redhat.com&gt; wrote: >>>> >>>>> >>>>> > On 8 Apr 2020, at 11:32, Michal Skrivanek < >>>>> michal.skrivanek(a)redhat.com&gt; wrote: >>>>> > >>>>> > Eh, so no, still not correct. Steven/Shmuel, I guess it could be >>>>> your [1] or maybe other related recent patches from you, but OST is now >>>>> broken (again). >>>>> > With [2] finally fixing the cluster creation OST now runs with a >>>>> Q35 seabios (as it was supposed to, but wasn’t until now), and the vm2 >>>>> which has a custom emulated machine of i440fx-rhel-7.4.0 doesn’t run >>>>> anymore, because apparently it is launched as a q35 VM for the first time, >>>>> and then failing restart ever since. >>>>> >>>>> Sorry, my bad, it’s really getting confusing with the amount of >>>>> breakages:) >>>>> It should be fixed just in OST because using a custom i440fx type in >>>>> a Cluster with q35/seabios is invalid. >>>>> Well, that’s easy... >>>>> >>>>> >>>> If I run networking-suite-master with additional repo >>>> https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/ >>>> the VMs will use >>>> >>>> - pc-i440fx-rhel8.1.0 type [1]. >>>> >>>> >>>> Is this the same problem, or is this another one? >>>> >>>> >>>> I don’t know, you didn’t say what problem you've seen >>>> >>>> >>> >>> pc-i440fx-rhel8.1.0 type seems to be not valid. >>> >>> >>> it’s not. I don’t know how/where you create the VMs or the Cluster in >>> network suite. You need to check it’s using the default and not something >>> hardcoded… >>> >>> >> It is using defaults. >> It is also easy to reproduce, just import the cirros image as a template >> and create a VM with "other OS" from this template. >> >> >> ah, glance import, yeah, that seems to be creating wrong templates. you >> could tell easily in UI it’s asking you that there’s a disrepancy between >> template’s and cluster’s chipset. >> - glance import should use q35 because that’s the new default >> - vm from template should drop the devices when there’s a difference in >> cluster >> >> Needs to be fixed. >> >> > Is there already a bug reported, or should I report one? > > I just reported https://bugzilla.redhat.com/1823674, to have a justification for the required code change in OST network suite to introduce the workaround. Dominik, we(me manually, basic suite, QE manually and using REST API) were not able reproduce your issue. Can you confirm it’s happening on a recent build. Not anything in CQ, I mean a recent nightly or recently merge artifacts of ovirt-engine. I looked at your logs and it looked like all the patches should have been there...but I don’t have any other explanation.

Thanks, michal > as a workaround, you could probably explicitly set the machine type as >> vm2 does in basic suite >> >> Thanks, >> michal >> >> >> >>> >>> >>>> >>>> [1] >>>> https://paste.centos.org/view/bff03f73 >>>> >>>> - >>>> >>>> >>>> >>>> >>>> >>>>> > >>>>> > Please fix ASAP >>>>> > >>>>> > Thanks, >>>>> > michal >>>>> > >>>>> > [1] https://gerrit.ovirt.org/#/c/107785/ >>>>> > [2] https://gerrit.ovirt.org/#/c/108237/ >>>>> _______________________________________________ >>>>> Devel mailing list -- devel(a)ovirt.org >>>>> To unsubscribe send an email to devel-leave(a)ovirt.org >>>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html >>>>> oVirt Code of Conduct: >>>>> https://www.ovirt.org/community/about/community-guidelines/ >>>>> List Archives: >>>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW... >>>>> >>>> >>>> >>> >>

> On 15 Apr 2020, at 22:14, Dominik Holler <dholler(a)redhat.com > <mailto:dholler@redhat.com>> wrote: > > > > On Wed, Apr 15, 2020 at 8:54 PM Michal Skrivanek > <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: > > > >> On 14 Apr 2020, at 11:05, Dominik Holler <dholler(a)redhat.com >> <mailto:dholler@redhat.com>> wrote: >> >>  >> >> >> On Tue, Apr 14, 2020 at 10:25 AM Dominik Holler >> <dholler(a)redhat.com <mailto:dholler@redhat.com>> wrote: >> >> >> >> On Fri, Apr 10, 2020 at 8:13 AM Michal Skrivanek >> <michal.skrivanek(a)redhat.com >> <mailto:michal.skrivanek@redhat.com>> wrote: >> >> >> >>> On 9 Apr 2020, at 10:35, Dominik Holler >>> <dholler(a)redhat.com <mailto:dholler@redhat.com>> wrote: >>> >>> >>> >>> On Wed, Apr 8, 2020 at 5:34 PM Michal Skrivanek >>> <michal.skrivanek(a)redhat.com >>> <mailto:michal.skrivanek@redhat.com>> wrote: >>> >>> >>> >>>> On 8 Apr 2020, at 14:55, Dominik Holler >>>> <dholler(a)redhat.com <mailto:dholler@redhat.com>> >>>> wrote: >>>> >>>> >>>> >>>> On Wed, Apr 8, 2020 at 2:48 PM Michal Skrivanek >>>> <michal.skrivanek(a)redhat.com >>>> <mailto:michal.skrivanek@redhat.com>> wrote: >>>> >>>> >>>> >>>>> On 8 Apr 2020, at 13:52, Dominik Holler >>>>> <dholler(a)redhat.com >>>>> <mailto:dholler@redhat.com>> wrote: >>>>> >>>>> >>>>> >>>>> On Wed, Apr 8, 2020 at 1:35 PM Michal >>>>> Skrivanek <michal.skrivanek(a)redhat.com >>>>> <mailto:michal.skrivanek@redhat.com>> wrote: >>>>> >>>>> >>>>> > On 8 Apr 2020, at 11:32, Michal >>>>> Skrivanek <michal.skrivanek(a)redhat.com >>>>> <mailto:michal.skrivanek@redhat.com>> wrote: >>>>> > >>>>> > Eh, so no, still not correct. >>>>> Steven/Shmuel, I guess it could be your >>>>> [1] or maybe other related recent patches >>>>> from you, but OST is now broken (again). >>>>> > With [2] finally fixing the cluster >>>>> creation OST now runs with a Q35 seabios >>>>> (as it was supposed to, but wasn’t until >>>>> now), and the vm2 which has a custom >>>>> emulated machine of i440fx-rhel-7.4.0 >>>>> doesn’t run anymore, because apparently >>>>> it is launched as a q35 VM for the first >>>>> time, and then failing restart ever since. >>>>> >>>>> Sorry, my bad, it’s really getting >>>>> confusing with the amount of breakages:) >>>>> It should be fixed just in OST because >>>>> using a custom i440fx type in a Cluster >>>>> with q35/seabios is invalid. >>>>> Well, that’s easy... >>>>> >>>>> >>>>> If I run networking-suite-master with >>>>> additional repo >>>>> https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/ >>>>> the VMs will use >>>>> >>>>> * >>>>> pc-i440fx-rhel8.1.0 type [1]. >>>>> >>>>> >>>>> Is this the same problem, or is this another one? >>>> >>>> I don’t know, you didn’t say what problem >>>> you've seen >>>> >>>> >>>> >>>> pc-i440fx-rhel8.1.0 type seems to be not valid. >>> >>> it’s not. I don’t know how/where you create the VMs >>> or the Cluster in network suite. You need to check >>> it’s using the default and not something hardcoded… >>> >>> >>> It is using defaults. >>> It is also easy to reproduce, just import the cirros >>> image as a template and create a VM with "other OS" >>> from this template. >> >> ah, glance import, yeah, that seems to be creating wrong >> templates. you could tell easily in UI it’s asking you >> that there’s a disrepancy between template’s and >> cluster’s chipset. >> - glance import should use q35 because that’s the new >> default >> - vm from template should drop the devices when there’s >> a difference in cluster >> >> Needs to be fixed. >> >> >> Is there already a bug reported, or should I report one? >> >> >> >> I just reported https://bugzilla.redhat.com/1823674, to have a >> justification for the required code change in OST network suite >> to introduce the workaround. > > Dominik, > we(me manually, basic suite, QE manually and using REST API) were > not able reproduce your issue. Can you confirm it’s happening on > a recent build. Not anything in CQ, I mean a recent nightly or > recently merge artifacts of ovirt-engine. I looked at your logs > and it looked like all the patches should have been there...but I > don’t have any other explanation. > > > Today I built engine e946364377a49b1ff019dc6b2f77c61fb27e48c5 as > developer installation, did a clean build, cleaned the db, run > engine-setup, imported the CentOS 8 image as template. > I also tried CentOS 7 image on the latest rpm version > 4.4.0-0.5.beta3.20200408120550.gitf94f968ca81.el8 , which results in > the same behavior. > The VM created from the template did not boot because of the issue. > On creating the VM from the template on UI, I get the suspicious warning: > """ > Devices Will Be Changed > In order to create a VM from a template with a different chipset, > device configuration will be changed. This may affect functionality > of the guest software. Are you sure you want to proceed? > Even if I neither modify the template and set only a name for the new VM. > """ > > I attached some db tables which might be relevant, please let me know > if I can provide further information. Thanks. The Cluster is wrong, it is set to Legacy i440fx > > > Thanks, > michal >> >> as a workaround, you could probably explicitly set the >> machine type as vm2 does in basic suite >> >> Thanks, >> michal >> >>>>> >>>>> [1] >>>>> https://paste.centos.org/view/bff03f73 >>>>> >>>>> * >>>>> >>>>> >>>>> >>>>> >>>>> > >>>>> > Please fix ASAP >>>>> > >>>>> > Thanks, >>>>> > michal >>>>> > >>>>> > [1] https://gerrit.ovirt.org/#/c/107785/ >>>>> > [2] https://gerrit.ovirt.org/#/c/108237/ >>>>> _______________________________________________ >>>>> Devel mailing list -- devel(a)ovirt.org >>>>> <mailto:devel@ovirt.org> >>>>> To unsubscribe send an email to >>>>> devel-leave(a)ovirt.org >>>>> <mailto:devel-leave@ovirt.org> >>>>> Privacy Statement: >>>>> https://www.ovirt.org/privacy-policy.html >>>>> oVirt Code of Conduct: >>>>> https://www.ovirt.org/community/about/community-guidelines/ >>>>> List Archives: >>>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW... >>>>> >>>> >>> >> > <vm_static.txt><cluster.txt><vds_dymamic.txt> _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/MRYYO4VJPEA...

On Thu, Apr 16, 2020 at 10:03 AM Lucie Leistnerova <lleistne(a)redhat.com <mailto:lleistne@redhat.com>> wrote: Hi, we did run into similar issue. We have default cluster with Emulated Machine:pc-i440fx-rhel8.2.0 then when we create VM in VM portal, it shows Cluster default(pc-q35-rhel8.2.0) and can't be started. That's the problem with the mixture. I guess its upgraded engine?

Engine version is ovirt-engine-4.4.0-0.32.master.el8ev.noarch and was updated from previous versions and manual upgrade to postgres 12. We did not play with cluster settings, all defaults. Is there a fix other than changing cluster or VM settings manually? Thanks Lucie On 4/16/20 9:27 AM, Michal Skrivanek wrote: > > >> On 15 Apr 2020, at 22:14, Dominik Holler <dholler(a)redhat.com >> <mailto:dholler@redhat.com>> wrote: >> >> >> >> On Wed, Apr 15, 2020 at 8:54 PM Michal Skrivanek >> <michal.skrivanek(a)redhat.com >> <mailto:michal.skrivanek@redhat.com>> wrote: >> >> >> >>> On 14 Apr 2020, at 11:05, Dominik Holler >>> <dholler(a)redhat.com <mailto:dholler@redhat.com>> wrote: >>> >>>  >>> >>> >>> On Tue, Apr 14, 2020 at 10:25 AM Dominik Holler >>> <dholler(a)redhat.com <mailto:dholler@redhat.com>> wrote: >>> >>> >>> >>> On Fri, Apr 10, 2020 at 8:13 AM Michal Skrivanek >>> <michal.skrivanek(a)redhat.com >>> <mailto:michal.skrivanek@redhat.com>> wrote: >>> >>> >>> >>>> On 9 Apr 2020, at 10:35, Dominik Holler >>>> <dholler(a)redhat.com <mailto:dholler@redhat.com>> >>>> wrote: >>>> >>>> >>>> >>>> On Wed, Apr 8, 2020 at 5:34 PM Michal Skrivanek >>>> <michal.skrivanek(a)redhat.com >>>> <mailto:michal.skrivanek@redhat.com>> wrote: >>>> >>>> >>>> >>>>> On 8 Apr 2020, at 14:55, Dominik Holler >>>>> <dholler(a)redhat.com >>>>> <mailto:dholler@redhat.com>> wrote: >>>>> >>>>> >>>>> >>>>> On Wed, Apr 8, 2020 at 2:48 PM Michal >>>>> Skrivanek <michal.skrivanek(a)redhat.com >>>>> <mailto:michal.skrivanek@redhat.com>> wrote: >>>>> >>>>> >>>>> >>>>>> On 8 Apr 2020, at 13:52, Dominik Holler >>>>>> <dholler(a)redhat.com >>>>>> <mailto:dholler@redhat.com>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Apr 8, 2020 at 1:35 PM Michal >>>>>> Skrivanek <michal.skrivanek(a)redhat.com >>>>>> <mailto:michal.skrivanek@redhat.com>> wrote: >>>>>> >>>>>> >>>>>> > On 8 Apr 2020, at 11:32, Michal >>>>>> Skrivanek >>>>>> <michal.skrivanek(a)redhat.com >>>>>> <mailto:michal.skrivanek@redhat.com>> >>>>>> wrote: >>>>>> > >>>>>> > Eh, so no, still not correct. >>>>>> Steven/Shmuel, I guess it could be >>>>>> your [1] or maybe other related >>>>>> recent patches from you, but OST is >>>>>> now broken (again). >>>>>> > With [2] finally fixing the >>>>>> cluster creation OST now runs with a >>>>>> Q35 seabios (as it was supposed to, >>>>>> but wasn’t until now), and the vm2 >>>>>> which has a custom emulated machine >>>>>> of i440fx-rhel-7.4.0 doesn’t run >>>>>> anymore, because apparently it is >>>>>> launched as a q35 VM for the first >>>>>> time, and then failing restart ever >>>>>> since. >>>>>> >>>>>> Sorry, my bad, it’s really getting >>>>>> confusing with the amount of breakages:) >>>>>> It should be fixed just in OST >>>>>> because using a custom i440fx type >>>>>> in a Cluster with q35/seabios is >>>>>> invalid. >>>>>> Well, that’s easy... >>>>>> >>>>>> >>>>>> If I run networking-suite-master with >>>>>> additional repo >>>>>> https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/ >>>>>> the VMs will use >>>>>> >>>>>> * >>>>>> pc-i440fx-rhel8.1.0 type [1]. >>>>>> >>>>>> >>>>>> Is this the same problem, or is this >>>>>> another one? >>>>> >>>>> I don’t know, you didn’t say what problem >>>>> you've seen >>>>> >>>>> >>>>> >>>>> pc-i440fx-rhel8.1.0 type seems to be not valid. >>>> >>>> it’s not. I don’t know how/where you create >>>> the VMs or the Cluster in network suite. You >>>> need to check it’s using the default and not >>>> something hardcoded… >>>> >>>> >>>> It is using defaults. >>>> It is also easy to reproduce, just import the >>>> cirros image as a template and create a VM with >>>> "other OS" from this template. >>> >>> ah, glance import, yeah, that seems to be creating >>> wrong templates. you could tell easily in UI it’s >>> asking you that there’s a disrepancy between >>> template’s and cluster’s chipset. >>> - glance import should use q35 because that’s the >>> new default >>> - vm from template should drop the devices when >>> there’s a difference in cluster >>> >>> Needs to be fixed. >>> >>> >>> Is there already a bug reported, or should I report one? >>> >>> >>> >>> I just reported https://bugzilla.redhat.com/1823674, to >>> have a justification for the required code change in OST >>> network suite to introduce the workaround. >> >> Dominik, >> we(me manually, basic suite, QE manually and using REST API) >> were not able reproduce your issue. Can you confirm it’s >> happening on a recent build. Not anything in CQ, I mean a >> recent nightly or recently merge artifacts of ovirt-engine. >> I looked at your logs and it looked like all the patches >> should have been there...but I don’t have any other explanation. >> >> >> Today I built engine e946364377a49b1ff019dc6b2f77c61fb27e48c5 as >> developer installation, did a clean build, cleaned the db, run >> engine-setup, imported the CentOS 8 image as template. >> I also tried CentOS 7 image on the latest rpm version >> 4.4.0-0.5.beta3.20200408120550.gitf94f968ca81.el8 , which >> results in the same behavior. >> The VM created from the template did not boot because of the issue. >> On creating the VM from the template on UI, I get the suspicious >> warning: >> """ >> Devices Will Be Changed >> In order to create a VM from a template with a different >> chipset, device configuration will be changed. This may affect >> functionality of the guest software. Are you sure you want to >> proceed? >> Even if I neither modify the template and set only a name for >> the new VM. >> """ >> >> I attached some db tables which might be relevant, please let me >> know if I can provide further information. > > Thanks. > The Cluster is wrong, it is set to Legacy i440fx >> >> >> Thanks, >> michal >>> >>> as a workaround, you could probably explicitly set >>> the machine type as vm2 does in basic suite >>> >>> Thanks, >>> michal >>> >>>>>> >>>>>> [1] >>>>>> https://paste.centos.org/view/bff03f73 >>>>>> >>>>>> * >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > >>>>>> > Please fix ASAP >>>>>> > >>>>>> > Thanks, >>>>>> > michal >>>>>> > >>>>>> > [1] >>>>>> https://gerrit.ovirt.org/#/c/107785/ >>>>>> > [2] >>>>>> https://gerrit.ovirt.org/#/c/108237/ >>>>>> _______________________________________________ >>>>>> Devel mailing list -- >>>>>> devel(a)ovirt.org <mailto:devel@ovirt.org> >>>>>> To unsubscribe send an email to >>>>>> devel-leave(a)ovirt.org >>>>>> <mailto:devel-leave@ovirt.org> >>>>>> Privacy Statement: >>>>>> https://www.ovirt.org/privacy-policy.html >>>>>> oVirt Code of Conduct: >>>>>> https://www.ovirt.org/community/about/community-guidelines/ >>>>>> List Archives: >>>>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW... >>>>>> >>>>> >>>> >>> >> <vm_static.txt><cluster.txt><vds_dymamic.txt> > > > _______________________________________________ > Devel mailing list --devel(a)ovirt.org <mailto:devel@ovirt.org> > To unsubscribe send an email todevel-leave(a)ovirt.org <mailto:devel-leave@ovirt.org> > Privacy Statement:https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct:https://www.ovirt.org/community/about/community-guidelines/ > List Archives:https://lists.ovirt.org/archives/list/devel@ovirt.org/message/MR... -- Lucie Leistnerova Senior Quality Engineer, QE Cloud, RHVM Red Hat EMEA IRC: lleistne @ #rhev-qe _______________________________________________ Devel mailing list -- devel(a)ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave(a)ovirt.org <mailto:devel-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FELZSQCQW32... -- Lukas Svaty RHV QE

On 15 Apr 2020, at 22:14, Dominik Holler <dholler(a)redhat.com&gt; wrote: On Wed, Apr 15, 2020 at 8:54 PM Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: > On 14 Apr 2020, at 11:05, Dominik Holler <dholler(a)redhat.com <mailto:dholler@redhat.com>> wrote: > >  > > > On Tue, Apr 14, 2020 at 10:25 AM Dominik Holler <dholler(a)redhat.com <mailto:dholler@redhat.com>> wrote: > > > On Fri, Apr 10, 2020 at 8:13 AM Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: > > >> On 9 Apr 2020, at 10:35, Dominik Holler <dholler(a)redhat.com <mailto:dholler@redhat.com>> wrote: >> >> >> >> On Wed, Apr 8, 2020 at 5:34 PM Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: >> >> >>> On 8 Apr 2020, at 14:55, Dominik Holler <dholler(a)redhat.com <mailto:dholler@redhat.com>> wrote: >>> >>> >>> >>> On Wed, Apr 8, 2020 at 2:48 PM Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: >>> >>> >>>> On 8 Apr 2020, at 13:52, Dominik Holler <dholler(a)redhat.com <mailto:dholler@redhat.com>> wrote: >>>> >>>> >>>> >>>> On Wed, Apr 8, 2020 at 1:35 PM Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: >>>> >>>> > On 8 Apr 2020, at 11:32, Michal Skrivanek <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>> wrote: >>>> > >>>> > Eh, so no, still not correct. Steven/Shmuel, I guess it could be your [1] or maybe other related recent patches from you, but OST is now broken (again). >>>> > With [2] finally fixing the cluster creation OST now runs with a Q35 seabios (as it was supposed to, but wasn’t until now), and the vm2 which has a custom emulated machine of i440fx-rhel-7.4.0 doesn’t run anymore, because apparently it is launched as a q35 VM for the first time, and then failing restart ever since. >>>> >>>> Sorry, my bad, it’s really getting confusing with the amount of breakages:) >>>> It should be fixed just in OST because using a custom i440fx type in a Cluster with q35/seabios is invalid. >>>> Well, that’s easy... >>>> >>>> >>>> If I run networking-suite-master with additional repo >>>> https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/ <https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/> >>>> the VMs will use >>>> pc-i440fx-rhel8.1.0 type [1]. >>>> >>>> Is this the same problem, or is this another one? >>> >>> I don’t know, you didn’t say what problem you've seen >>> >>> >>> >>> pc-i440fx-rhel8.1.0 type seems to be not valid. >> >> it’s not. I don’t know how/where you create the VMs or the Cluster in network suite. You need to check it’s using the default and not something hardcoded… >> >> >> It is using defaults. >> It is also easy to reproduce, just import the cirros image as a template and create a VM with "other OS" from this template. > > ah, glance import, yeah, that seems to be creating wrong templates. you could tell easily in UI it’s asking you that there’s a disrepancy between template’s and cluster’s chipset. > - glance import should use q35 because that’s the new default > - vm from template should drop the devices when there’s a difference in cluster > > Needs to be fixed. > > > Is there already a bug reported, or should I report one? > > > > I just reported https://bugzilla.redhat.com/1823674 <https://bugzilla.redhat.com/1823674>;, to have a justification for the required code change in OST network suite to introduce the workaround. Dominik, we(me manually, basic suite, QE manually and using REST API) were not able reproduce your issue. Can you confirm it’s happening on a recent build. Not anything in CQ, I mean a recent nightly or recently merge artifacts of ovirt-engine. I looked at your logs and it looked like all the patches should have been there...but I don’t have any other explanation. Today I built engine e946364377a49b1ff019dc6b2f77c61fb27e48c5 as developer installation, did a clean build, cleaned the db, run engine-setup, imported the CentOS 8 image as template. I also tried CentOS 7 image on the latest rpm version 4.4.0-0.5.beta3.20200408120550.gitf94f968ca81.el8 , which results in the same behavior. The VM created from the template did not boot because of the issue. On creating the VM from the template on UI, I get the suspicious warning: """ Devices Will Be Changed In order to create a VM from a template with a different chipset, device configuration will be changed. This may affect functionality of the guest software. Are you sure you want to proceed? Even if I neither modify the template and set only a name for the new VM. """ I attached some db tables which might be relevant, please let me know if I can provide further information.

Thanks, michal > > as a workaround, you could probably explicitly set the machine type as vm2 does in basic suite > > Thanks, > michal > >> >>> >>>> >>>> [1] >>>> https://paste.centos.org/view/bff03f73 <https://paste.centos.org/view/bff03f73> >>>> >>>> >>>> >>>> >>>> > >>>> > Please fix ASAP >>>> > >>>> > Thanks, >>>> > michal >>>> > >>>> > [1] https://gerrit.ovirt.org/#/c/107785/ <https://gerrit.ovirt.org/#/c/107785/> >>>> > [2] https://gerrit.ovirt.org/#/c/108237/ <https://gerrit.ovirt.org/#/c/108237/> >>>> _______________________________________________ >>>> Devel mailing list -- devel(a)ovirt.org <mailto:devel@ovirt.org> >>>> To unsubscribe send an email to devel-leave(a)ovirt.org <mailto:devel-leave@ovirt.org> >>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> >>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> >>>> List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW... >>> >> > <vm_static.txt><cluster.txt><vds_dymamic.txt>

We only support up to pc-i440fx-rhel7.6.0 in the GUI on the engine and the Bios Type for compatibility 4.4 needs to be set to Legacy Bios and not Q35.

On Wed, Apr 8, 2020 at 3:56 PM Dominik Holler <dholler(a)redhat.com&gt; wrote: > > > On Wed, Apr 8, 2020 at 2:48 PM Michal Skrivanek < > michal.skrivanek(a)redhat.com&gt; wrote: > >> >> >> On 8 Apr 2020, at 13:52, Dominik Holler <dholler(a)redhat.com&gt; wrote: >> >> >> >> On Wed, Apr 8, 2020 at 1:35 PM Michal Skrivanek < >> michal.skrivanek(a)redhat.com&gt; wrote: >> >>> >>> > On 8 Apr 2020, at 11:32, Michal Skrivanek < >>> michal.skrivanek(a)redhat.com&gt; wrote: >>> > >>> > Eh, so no, still not correct. Steven/Shmuel, I guess it could be your >>> [1] or maybe other related recent patches from you, but OST is now broken >>> (again). >>> > With [2] finally fixing the cluster creation OST now runs with a Q35 >>> seabios (as it was supposed to, but wasn’t until now), and the vm2 which >>> has a custom emulated machine of i440fx-rhel-7.4.0 doesn’t run anymore, >>> because apparently it is launched as a q35 VM for the first time, and then >>> failing restart ever since. >>> >>> Sorry, my bad, it’s really getting confusing with the amount of >>> breakages:) >>> It should be fixed just in OST because using a custom i440fx type in a >>> Cluster with q35/seabios is invalid. >>> Well, that’s easy... >>> >>> >> If I run networking-suite-master with additional repo >> https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/865/ >> the VMs will use >> >> - pc-i440fx-rhel8.1.0 type [1]. >> >> >> Is this the same problem, or is this another one? >> >> >> I don’t know, you didn’t say what problem you've seen >> >> > > pc-i440fx-rhel8.1.0 type seems to be not valid. > > >> >> [1] >> https://paste.centos.org/view/bff03f73 >> >> - >> >> >> >> >> >>> > >>> > Please fix ASAP >>> > >>> > Thanks, >>> > michal >>> > >>> > [1] https://gerrit.ovirt.org/#/c/107785/ >>> > [2] https://gerrit.ovirt.org/#/c/108237/ >>> _______________________________________________ >>> Devel mailing list -- devel(a)ovirt.org >>> To unsubscribe send an email to devel-leave(a)ovirt.org >>> Privacy Statement: https://www.ovirt.org/privacy-policy.html >>> oVirt Code of Conduct: >>> https://www.ovirt.org/community/about/community-guidelines/ >>> List Archives: >>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/L2Z4LNRMWPW... >>> >> >>