On Mon, Aug 31, 2020 at 8:41 PM <thomas(a)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
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
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.
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
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.
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
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: