Hi, What is the most simpliest way to backward migrate VMs from oVirt 4.4 to oVirt 4.3 ? Is it possible to use export domain or there are some other ways ? Thank you.
Export domain should work, with the usual constraints that you have to detach/attach the whole domain and you'd probably want to test with one or a few pilot VMs first. There could be issues with 'base' templates etc. for VMs that where created as new on 4.4: be sure to try every machine type first. Ideally you have 4.4 and 4.3 farms side by side, instead of rebasing your hosts on 4.3 and *then* finding issues. Things to watch out for are hardware base lines (those mitigation-enhanced CPU types can be nasty), BIOS types (Q35 vs. all others) etc. Personally I see OVA files as something that should be least risky and minimal functionality that just ought to always work. The oVirt team doesn't seem to share my opinion and views OVA as a VMware->oVirt migration tool, mostly. I still try to use OVA export/import for critical VMs, because sometimes it means I can at least resurrect them on a stand-alone KVM host (even VMware should work in theory: in practice I've seen both VMware and VirtualBox barf at oVirt generated OVA exports). Note that there is an issue with OVA exports from oVirt 4.3: They can result in empty disks due to a race condition that wasn't fixed even with the last 4.3 release. In your case, that shouldn't bite you, as you are moving in the other direction. But should you decide to go forward again be sure to check your 4.3 OVA exports via 'du -h <OVA-file>' showing more than a few KB of actuall alloaction vs. the potentially multi-TB 'sparse' disk full of zeros 'ls -l' might hint at. With oVirt I consider blind faith as extremely ill advised. Everything you haven't tested several times after every change of every component yourself, is much more likely to fail than you ever thought befit a product that carries "a free open-source virtualization solution for your entire enterprise" on its home page.
First and foremost that’s something we do not support if your VMs live in a 4.4+ cluster level in your oVirt 4.4. The upgrade path for VM configuration is one way only. if it’s just a handful of VMs it might be way easier to just recreate those VMs and move disks I also wonder what’s reason for running 4.3 these days, we really do not develop/patch it for 10 months by now. Thanks, michal
On 31. 3. 2021, at 23:08, Thomas Hoberg <thomas@hoberg.net> wrote:
Export domain should work, with the usual constraints that you have to detach/attach the whole domain and you'd probably want to test with one or a few pilot VMs first.
There could be issues with 'base' templates etc. for VMs that where created as new on 4.4: be sure to try every machine type first. Ideally you have 4.4 and 4.3 farms side by side, instead of rebasing your hosts on 4.3 and *then* finding issues. Things to watch out for are hardware base lines (those mitigation-enhanced CPU types can be nasty), BIOS types (Q35 vs. all others) etc.
Personally I see OVA files as something that should be least risky and minimal functionality that just ought to always work. The oVirt team doesn't seem to share my opinion and views OVA as a VMware->oVirt migration tool, mostly.
I still try to use OVA export/import for critical VMs, because sometimes it means I can at least resurrect them on a stand-alone KVM host (even VMware should work in theory: in practice I've seen both VMware and VirtualBox barf at oVirt generated OVA exports).
Note that there is an issue with OVA exports from oVirt 4.3: They can result in empty disks due to a race condition that wasn't fixed even with the last 4.3 release. In your case, that shouldn't bite you, as you are moving in the other direction. But should you decide to go forward again be sure to check your 4.3 OVA exports via 'du -h <OVA-file>' showing more than a few KB of actuall alloaction vs. the potentially multi-TB 'sparse' disk full of zeros 'ls -l' might hint at.
With oVirt I consider blind faith as extremely ill advised. Everything you haven't tested several times after every change of every component yourself, is much more likely to fail than you ever thought befit a product that carries "a free open-source virtualization solution for your entire enterprise" on its home page. _______________________________________________ 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/GDJSP7UVVAORL3...
I personally consider the fact that you gave up on 4.3/CentOS7 before CentOS 8 could have even been remotely reliable to run "a free open-source virtualization solution for your entire enterprise", a rather violent break of trust. I understand Redhat's motivation with Python 2/3 etc., but users just don't. Please just try for a minute to view this from a user's perspective. With CentOS 7 supported until 2024, we naturally expect the added value on top via oVirt to persist just as long. And with CentOS 8 support lasting until the end of this year, oVirt 4.4 can't be considered "Petrus" or a rock to build on. Most of us run oVirt simply because we are most interested in the VMs it runs (tenants paying rent). We're not interested in keeping oVirt itself stable and from failing after any update to the house of cards. And yes, by now I am sorry to have chosen oVirt at all, finding that 4.3 was abandonend before 4.4 or the CentOS 8 below was even stable and long before the base OS ran out of support. To the users out there oVirt is a platform, a tool, not a means to itself.
Hi Thomas,
On 1. 4. 2021, at 23:44, Thomas Hoberg <thomas@hoberg.net> wrote:
I personally consider the fact that you gave up on 4.3/CentOS7 before CentOS 8 could have even been remotely reliable to run "a free open-source virtualization solution for your entire enterprise", a rather violent break of trust.
it wasn’t really any different from past big releases. It’s been in development for roughly a year. Sure, there were hiccups during el7->el8 transition, but it didn’t seem to me any worse than when we moved from el6 to el7.
I understand Redhat's motivation with Python 2/3 etc., but users just don't. Please just try for a minute to view this from a user's perspective.
it’s not RedHat’s motivation, it’s python 2 end of life that was on January 2020 already. Every larger project written in python suffered, we already exceeded py2 EOL by several months but it couldn’t have been avoided. Users may not care, but there’s no way for developers to work around a language deprecation/redesign. I do not see how we could do anything about it.
With CentOS 7 supported until 2024, we naturally expect the added value on top via oVirt to persist just as long.
oVirt has nothing to do with CentOS, it’s just been our choice to build on as a stable and ubiquitous OS to build on, but it doesn’t define our own lifecycle.
And with CentOS 8 support lasting until the end of this year, oVirt 4.4 can't be considered "Petrus" or a rock to build on.
right, the end of good old CentOS model is a big issue we have to sort out before the end of the year. There’s been previous threads on this topic, we do have CentOS Stream support for development, for stable user environment we will probably need something else. Things are in motion, there’s “free” RHEL offering, there are multiple other clones like Rocky or Alma, patches on the way to support them.
Most of us run oVirt simply because we are most interested in the VMs it runs (tenants paying rent).
We're not interested in keeping oVirt itself stable and from failing after any update to the house of cards.
And yes, by now I am sorry to have chosen oVirt at all, finding that 4.3 was abandonend before 4.4 or the CentOS 8 below was even stable and long before the base OS ran out of support.
I’m sorry for your experience. It’s understandable end users do not see the developer’s issues. But this is an open source project, some involvement is kind of expected. if you’re looking for a guaranteed support without dealing with “details” you can always consider commercial offering, be it RHV or VMware or whatever else. Maintaining older versions is usually “the thing” that you get with commercial products. OSS projects usually offer backward compatibility only to a certain degree depending of available resources. We don’t really have them, we cannot maintain python2, we cannot maintain CentOS 7 or keep running CentOS 8 program. If there is anyone interested in help, provide automation for older versions, keep fixing it, add other operating system support and maintain it, then absolutely, please come forward and let’s do that by all means. Thanks, michal
To the users out there oVirt is a platform, a tool, not a means to itself. _______________________________________________ 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/JHSFTNGNOMYNCE...
participants (3)
-
KSNull Zero -
Michal Skrivanek -
Thomas Hoberg