On 4/16/20 10:19 AM, Lukas Svaty wrote:


On Thu, Apr 16, 2020 at 10:03 AM Lucie Leistnerova <[email protected] <mailto:[email protected]>> 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?
Yes. I just wanted to ask how to easily fix it.


    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 <[email protected]
    <mailto:[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/
                        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 --
                            [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
                            oVirt Code of Conduct:
                            
https://www.ovirt.org/community/about/community-guidelines/
                            List Archives:
                            
https://lists.ovirt.org/archives/list/[email protected]/message/L2Z4LNRMWPWNLPTZ4HULDDTXMH2DUN7S/




    <vm_static.txt><cluster.txt><vds_dymamic.txt>


    _______________________________________________
    Devel mailing list [email protected]  <mailto:[email protected]>
    To unsubscribe send an email [email protected]  
<mailto:[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/

-- Lucie Leistnerova
    Senior Quality Engineer, QE Cloud, RHVM
    Red Hat EMEA

    IRC: lleistne @ #rhev-qe

    _______________________________________________
    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
    oVirt Code of Conduct:
    https://www.ovirt.org/community/about/community-guidelines/
    List Archives:
    
https://lists.ovirt.org/archives/list/[email protected]/message/FELZSQCQW32V4XZBKAWYAVMBKWMDGXSV/



--

Lukas Svaty

RHV QE

--
Lucie Leistnerova
Senior Quality Engineer, QE Cloud, RHVM
Red Hat EMEA

IRC: lleistne @ #rhev-qe

_______________________________________________
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/III6HOVY47M3MWLY7HOUKCKW75WVDFIA/

Reply via email to