12:12 a.m.
On Tue, Aug 4, 2020 at 7:37 PM <thomas(a)hoberg.net> 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