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 <tho...@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-le...@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/GDJSP7UVVAORL3WBPKTRZUNZ7SRJ46E6/
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/JBUBR35AM6W5GOTC432DY4JDS6X4ARHM/

Reply via email to