How can you avoid breaking 4.3.11 legacy VMs imported in 4.4.1 during a migration?
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. 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? P.S. A hypervisor reconstructing the virtual hardware from anywhere but storage at every launch, is difficult to trust IMHO.
I might have found one: You can set the emulated machine to 'legacy' before the first launch. No idea yet, if it will actually work, because the boot disk was copied empty...
On a machine that survived the import, that worked as expected. May want to add that to a check list, that the original machine type for legacy isn't carried over after an import but needs to be set explicitly.
On Mon, Aug 31, 2020 at 8:41 PM <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.
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.
P.S. A hypervisor reconstructing the virtual hardware from anywhere but storage at every launch, is difficult to trust IMHO. _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@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/36WNCP6YMRM3MG...
Thanks for the suggestion, I tried that, but I didn't get very far on a single node HCI cluster... And I'm afraid it won't be much better on HCI in general, which is really the use case I am most interested in. Silently converting VMs is something rather unexpected from a hypervisor, doing it twice my result in the same machine here only by accident. That type of design decision needs highlighting in the documentation, because users just won't be expecting it.
On Tue, Sep 1, 2020 at 1:22 AM <thomas@hoberg.net> wrote:
Thanks for the suggestion, I tried that, but I didn't get very far on a single node HCI cluster... And I'm afraid it won't be much better on HCI in general, which is really the use case I am most interested in.
Yes, that requires at least one more host for the second cluster
Silently converting VMs is something rather unexpected from a hypervisor, doing it twice my result in the same machine here only by accident.
That type of design decision needs highlighting in the documentation, because users just won't be expecting it. _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@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/MUGBA2TBEEIHIJ...
On 31 Aug 2020, at 21:20, Arik Hadas <ahadas@redhat.com> wrote:
On Mon, Aug 31, 2020 at 8:41 PM <thomas@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@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@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/36WNCP6YMRM3MG... <https://lists.ovirt.org/archives/list/users@ovirt.org/message/36WNCP6YMRM3MG44WIVHLVOUD2MACDQ5/> _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@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/PAJJNL44JIIY3R...
participants (3)
-
Arik Hadas -
Michal Skrivanek -
thomas＠hoberg.net