On Tue, Apr 14, 2020 at 10:25 AM Dominik Holler <dholler(a)redhat.com> wrote:
On Fri, Apr 10, 2020 at 8:13 AM Michal Skrivanek <
michal.skrivanek(a)redhat.com> wrote:
>
>
> On 9 Apr 2020, at 10:35, Dominik Holler <dholler(a)redhat.com> wrote:
>
>
>
> On Wed, Apr 8, 2020 at 5:34 PM Michal Skrivanek <
> michal.skrivanek(a)redhat.com> wrote:
>
>>
>>
>> On 8 Apr 2020, at 14:55, Dominik Holler <dholler(a)redhat.com> wrote:
>>
>>
>>
>> On Wed, Apr 8, 2020 at 2:48 PM Michal Skrivanek <
>> michal.skrivanek(a)redhat.com> wrote:
>>
>>>
>>>
>>> On 8 Apr 2020, at 13:52, Dominik Holler <dholler(a)redhat.com> wrote:
>>>
>>>
>>>
>>> On Wed, Apr 8, 2020 at 1:35 PM Michal Skrivanek <
>>> michal.skrivanek(a)redhat.com> wrote:
>>>
>>>>
>>>> > On 8 Apr 2020, at 11:32, Michal Skrivanek <
>>>> michal.skrivanek(a)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?
, to have a
justification for the required code change in OST network suite to
introduce the workaround.
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...
>>>>
>>>
>>>
>>
>