> On 15 Apr 2020, at 22:14, Dominik Holler <[email protected]> wrote: > > > > On Wed, Apr 15, 2020 at 8:54 PM Michal Skrivanek <[email protected] > <mailto:[email protected]>> wrote: > > >> On 14 Apr 2020, at 11:05, Dominik Holler <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> >> On Tue, Apr 14, 2020 at 10:25 AM Dominik Holler <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> On Fri, Apr 10, 2020 at 8:13 AM Michal Skrivanek >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> On 9 Apr 2020, at 10:35, Dominik Holler <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> On Wed, Apr 8, 2020 at 5:34 PM Michal Skrivanek >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> On 8 Apr 2020, at 14:55, Dominik Holler <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>> On Wed, Apr 8, 2020 at 2:48 PM Michal Skrivanek >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On 8 Apr 2020, at 13:52, Dominik Holler <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> >>>>> On Wed, Apr 8, 2020 at 1:35 PM Michal Skrivanek >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> > On 8 Apr 2020, at 11:32, Michal Skrivanek <[email protected] >>>>> > <mailto:[email protected]>> 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. 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 >>>>> <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 -- [email protected] <mailto:[email protected]> >>>>> To unsubscribe send an email to [email protected] >>>>> <mailto:[email protected]> >>>>> 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/[email protected]/message/L2Z4LNRMWPWNLPTZ4HULDDTXMH2DUN7S/ >>>>> >>>>> <https://lists.ovirt.org/archives/list/[email protected]/message/L2Z4LNRMWPWNLPTZ4HULDDTXMH2DUN7S/> >>>> >>> >> > <vm_static.txt><cluster.txt><vds_dymamic.txt>
_______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/MRYYO4VJPEA6AX6I5OQ6IKCD7FUXYOS4/
