On 31 Aug 2020, at 21:20, Arik Hadas <ahadas(a)redhat.com>
wrote:
On Mon, Aug 31, 2020 at 8:41 PM <thomas(a)hoberg.net
<mailto:thomas@hoberg.net>> wrote:
Testing the 4.3 to 4.4 migration... what I describe here is facts is mostly observations
and conjecture, could be wrong, just makes writing easier...
While 4.3 seems to maintain a default emulated machine type (pc-i440fx-rhel7.6.0 by
default), it doesn't actually allow setting it in the cluster settings: Could be
built-in, could be inherited from the default template... Most of my VMs were created with
the default on 4.3.
oVirt 4.4 presets that to pc-q35-rhel8.1.0 and that has implications:
1. Any VM imported from an export on a 4.3 farm, will get upgraded to Q35, which
unfortunately breaks things, e.g. network adapters getting renamed as the first issue I
stumbled on some Debian machines
2. If you try to compensate by lowering the cluster default from Q35 to pc-i44fx the
hosted-engine will fail, because it was either built or came as Q35 and can no longer find
critical devices: It evidently doesn't take/use the VM configuration data it had at
the last shutdown, but seems to re-generate it according to some obscure logic, which
fails here.
that is currently the case, yes. We have
https://bugzilla.redhat.com/show_bug.cgi?id=1871694 - should be fixed by that, right?
I've tried creating a bit of backward compatibility by creating another template
based on pc-i440fx, but at the time of the import, I cannot switch the template.
If I try to downgrade the cluster, the hosted-engine will fail to start and I can't
change the template of the hosted-engine to something Q35.
Currently this leaves me in a position where I can't separate the move of VMs from
4.3 to 4.4 and the upgrade of the virtual hardware, which is a different mess for every OS
in the mix of VMs.
Recommendations, tips anyone?
If you have to preserve the i440fx chipset, you can create another cluster that is set
with legacy bios and import the VMs to that cluster.
The drawback in the alternative you tested (importing it to a q35 cluster and override
the chipset/emulated machine before launching the VM) is that on import we
convert the VM to q35 (changing devices, clearing PCI addresses) and later the VM is
converted back to i440fx - so it's less recommended.
once the HE problem goes away it should be perfectly fine to just use that one cluster in
i440fx mode if you prefer to. It’s q35 only because it’s a new one and we assume a new one
is for new stuff. For upgraded setups the cluster is left as it was.
P.S. A hypervisor reconstructing the virtual hardware from anywhere but storage at every
launch, is difficult to trust IMHO.
_______________________________________________
Users mailing list -- users(a)ovirt.org <mailto:users@ovirt.org>
To unsubscribe send an email to users-leave(a)ovirt.org
<mailto:users-leave@ovirt.org>
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/users@ovirt.org/message/36WNCP6YMRM...
<
https://lists.ovirt.org/archives/list/users@ovirt.org/message/36WNCP6YMRM...
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-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/users@ovirt.org/message/PAJJNL44JII...