I've found that the first export attempt always fails, but subsequent exports tend to work afterwards. Although, it resets after a time. I'm not sure if this is authentication related or not, but it only seems to work for about 24 hours. The easiest way to check that I've found is: 1. Make the initial export and let it finish. 2. Discard that initial export. 3. Export the VM again. 4. Try to archive it. (tar -cvJf a.tar.xz a.ova) 5. Check the file size of the archive, if it's greater than a couple MB you're probably fine. (Do try to import it back and use it, if you want to be sure.) If not, go to step 3. It's definitely a pain, but the alternative would be to boot some other VM and run a clone of the original. I've used FOG in the past for this and it works fine even on the same hypervisor host. (Writes the disk images to a NFS share or local filesystem) But you could use anything. Others here have used Clonezilla. If you have a tape drive or some other external backup device you could pass it through to another VM and use it to write the backup directly. Also, as a sidenote: oVirt 4.4 uses a newer imageio proxy that only seems to work with Chromium based browsers. So don't try using Pale Moon, Waterfox, etc. with it as you'll always get bad exports and failed uploads. I had to find out the hard way. - Patrick Hibbs On Mon, 2022-02-21 at 19:34 +0000, Abe E wrote:

The latest release of 4.3 still contained a bug, essentially a race condition which resulted in the OVA disk not being exported at all. Unfortunately you can't tell from the file size, it's only when you look inside the OVA that you'll see the disk image is actually empty. I hand patched the (single line) fix to make OVA exports work, because they did not update 4.3 at that point any more. https://bugzilla.redhat.com/show_bug.cgi?id=1813028 Since the ability to migrate from one major release to another without such problems, I since struggled with the oVirt team's motto "for the entire enterprise" Yes, see above You can actually export the disks via the browser, but beware that sparse disks may wind up quite big. Unfortunately I relied on VDO/thin to not have me think about disk sizes at all (nasty habit picked up from VMware)... While Clonezilla wasn't so great for backup up complete oVirt hosts, which might have VDO and Gluster bricks on them, it's turned out a great solution for backup up or beaming VMs from one "farm" to another. E.g. I've used it to move VMs from my oVirt 4.3 HCI cluster to my new XCP-NG 8.2 HCI cluster or sometimes even to a temporary VMware VM without storing it externally: Just create a target VM, have both ends move the Clonezilla ISO and start the transfer. I believe backup domains were new in 4.4 so they only work for 4.4 -> 4.4 mobility, but export domains, while deprecated, still work on both sides. So you can create and fill a backup domain on 4.3, disconnect and reconnect it on 4.4 and import machines from there. I believe I've faced some issues with VMs that were too old, or based on templates or whatnot, so it's best to try the export/import fully before taking down and rebuilding the 4.3, so the VMs in the backup domain can actually be recovered. Generally any VM that is Q35 already on 4.3 seems to be less problematic on 4.4. > > Thanks a bunch, I have noticed repeated names helping me, I am very grateful for your > help.

You're welcome. Good to hear you didn't loose anything. Export to OVA has one of the hosts write an OVA file to the selected host's filesystem. (As long as VDSM has write privileges to do so.) The OVA file contains the *entire* VM configuration (Number of CPUs / Chipset / Network Adapters / etc.) in addtion to a copy of the attached disks. The intent of this is to allow importing the VM into another hypervisor. (oVirt, or even other tech entirely such as VMWare / Virtualbox / etc.) This tends to not work very well however due to the previously discussed failures, and the fact that oVirt's conversion code isn't very good. Even between oVirt versions on the same cluster, an exported OVA may not re-import cleanly, if at all. (This is probably related to the lack of a generic CPU target in oVirt, as no other hypervisor solution is going to put forth the effort to maintain compatibility with oVirt's overly-specific CPU model selections, flags, and custom virtual hardware layouts.) Export to Export Domain simply writes the disk images and VM domain XML to the Export Domain for later import into another oVirt instance. (This was the original way oVirt handled backups, and migration between oVirt clusters.) This has been deprecated for a while now, and oVirt 4.4 can't even create a new Export Domain. (Although 4.4 will allow importing an existing one.) Essentially, it's no different than OVA Exports beyond the oVirt specific nature of it. (Both make a complete copy of the VM and attached storage, OVA just adds a translation / compatibility layer step, and it's output is meant to be handled directly by the administrator.) Exporting a template simply exports the template. It has a copy of the disks just like the other two options. With the added caveat that you need to instantiate a new VM from it prior to use. Which may or may not be what you need for backups. Depending on whether or not you have organizational policies / regulatory compliance to worry about. As this will necessitate a bunch of changes in the virtualized hardware. That being said, I can't say to it's reliability as I've never really used templates for backup purposes. If you really need a backup, OVA is fine. (Though you should test re- importing it before calling the job finished.) If you really want to be sure, use an external cloning solution like Clonezilla, (If you only need to back up a few VMs) or something like FOG. (If you need more advanced options, like a regular backup schedule, automated backups / restorations, logging, access control, etc.) - Patrick Hibbs On Tue, 2022-02-22 at 01:24 +0000, Abe E wrote: