[ovirt-devel] Re: q35 changes

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