On Tue, Aug 4, 2020 at 7:37 PM <[email protected]> wrote: > > Nir, first of all, thanks a lot for the detailed description and the quick > fix in 4.4! > > I guess I'll be able to paste that single line fix into the 4.3. variant > myself, but I'd rather see that included in the next 4.3 release, too: How > would that work? > > --- > "OVA is not a backup solution": > > From time to time, try to put youself into a user's shoes. > > The fist thing you read about Export Domains, is that they are deprecated: > That doesn't give you the warm fuzzy feeling that you are learning something > useful when you start using them, especially in the context of a migration to > the next release.
This is good, you should not use export domain at this point. We have better replacement (see my other mail). > OVA on the other hand, stands for a maximum of interoperability and when > given a choice between something proprietary and deprecated and a file format > that will port pretty much everywhere, any normal user (who doesn't have the > code behind the scene in his mind), will jump for OVA export/import. I think you already found that OVA are not what you think they are. They work for exporting VMs from the same hypervisor and back, unless you have a tool that know how to convert OVA from one hypervisor to another like virt-v2v. > Also it's just two buttons, no hassle, while it took me a while to get an > Export domain defined, filled, detached, re-attached, and tested. True, ease of use is important. But if you are going to do this a lost, scripting the operation is important, and oVirt has a very powerful API/SDK. > Again from a user's perspective: HCI gluster storage in oVirt is black magic, > especially since disk images are all chunked up. For a user it will probably > take many years of continous oVirt operation until he's confident that he'l > recover VM storage in the case of a serious hickup and that whatever might > have gone wrong or bitrot might have occured, won't carry over to an export > domain. OVA files seem like a nice bet to recover your VM on whatever > platform you can get back running in a minor disaster. What you say is basically that having a backup is useful :-) > In many cases, it doesn't even matter you have to shut down the machine to do > the export, because the machines are application level redundant or simply > it's ok to have them down for a couple of minutes, if you know you can get > them back up no matter what in a comparable time frame, oVirt farm dead or > alive, e.g. on a bare metal machine. How are you going to use the OVA on a bare metal machine? > And then my case, many of the images are just meant to move between an oVirt > farm and a desktop hypervisor. Why do you need the desktop hypervisor? I would like to hear more about this use case. And if you need one, why not use something based on KVM (like virt-manager) so disks from oVirt can work without any change? This will make it easy to move from oVit to desktop hypervisor and back with relatively little effort. > tl;dr > > (working) OVA export and import IMHO are elemental and crucial functionality, > without which oVirt can't be labelled a product. > > I completely appreciate the new backup API, especially with the consistency > enabled for running VMs; perhaps a little less that I'd have to purchase an > extra product to do a fundamental operation with a similar ease as the OVA > export/import buttons, but at least it's there. > > That doesn't mean OVA in/ex isn't important or that in fact a shared > import/export domain would be nice, too. > > Thanks for your time! Thanks Thomas, this is very useful feedback! Nir _______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/4RQBNMRDMDEBLVLVVBVPTOSIHCYSEO5I/
