> On 8 Apr 2020, at 11:32, Michal Skrivanek <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
the VMs will use
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.