8:32 p.m.
On Tue, Sep 1, 2020 at 11:26 PM Nir Soffer <nsoffer(a)redhat.com> wrote:
On Sun, Aug 30, 2020 at 7:13 PM <thomas(a)hoberg.net> wrote:
>
> Struggling with bugs and issues on OVA export/import (my clear favorite otherwise,
especially when moving VMs between different types of hypervisors), I've tried pretty
much everything else, too.
>
> Export domains are deprecated and require quite a bit of manual handling.
Unfortunately the buttons for the various operations are all over the place e.g. the
activation and maintenance toggles are in different pages.
Using export domain is not a single click, but it is not that complicated.
But this is good feedback anyway.
> In the end the mechanisms underneath (qemu-img) seem very much the same and suffer
from the same issues (I have larger VMs that keep failing on imports).
I think the issue is gluster, not qemu-img.
> So far the only fool-proof method has been to use the imageio daemon to upload and
download disk images, either via the Python API or the Web-GUI.
How did you try? transfer via the UI is completely different than
transfer using the python API.
From the UI, you get the image content on storage, without sparseness
support. If you
download 500g raw sparse disk (e.g. gluster with allocation policy
thin) with 50g of data
and 450g of unallocated space, you will get 50g of data, and 450g of
zeroes. This is very
slow. If you upload the image to another system you will upload 500g
of data, which will
again be very slow.
From the python API, download and upload support sparseness, so you
will download and
upload only 50g. Both upload and download use 4 connections, so you
can maximize the
throughput that you can get from the storage. From python API, you can
convert the image
format during download/upload automatically, for example download raw
disk to qcow2
image.
Gluster is a challenge (as usual), since when using sharding (enabled
by default for ovirt),
it does not report sparness. So even from the python API you will
download the entire 500g.
We can improve this using zero detection but this is not implemented yet.
I forgot to add that NFS < 4.2 is also a challenge, and will cause
very slow downloads
creating fully allocated files for the same reason. If you use export
domain to move
VMs, you should use NFS 4.2.
Unfortunately oVirt tries hard to prevent you from using NFS 4.2. Not
only this is
not the default, the settings to select version 4.2 are hidden under:
Storage > Domains > domain-name > Manage Domain > Custom Connection
Parameters
Select "V4.2" for NFS Version.
All this can be done only when the storage domain is in maintenance.
With this creating preallocated disks is infinity times faster (using
fallocate()), copying disks
from this domain will can much faster, and downloading raw sparse disk
will be much faster
and more correct, preserving sparseness.
> Transfer times are terrible though, 50MB/s is quite low when the
network below is 2.5-10Gbit and SSDs all around.
In our lab we tested upload of 100 GiB image and 10 concurrent uploads
of 100 GiB
images, and we measured throughput of 1 GiB/s:
https://bugzilla.redhat.com/show_bug.cgi?id=1591439#c24
I would like to understand the setup better:
- upload or download?
- disk format?
- disk storage?
- how is storage connected to host?
- how do you access the host (1g network? 10g?)
- image format?
- image storage?
If NFS, which version?
> Obviously with Python as everybody's favorite GUI these days, you can also copy
and transfer the VMs complete definition, but I am one of those old guys, who might even
prefer a real GUI to mouse clicks on a browser.
>
> The documentation on backup domains is terrible. What's missing behind the 404
link in oVirt becomes a very terse section in the RHV manuals, where you're basically
just told that after cloning the VM, you should then move its disks to the backup
domain...
backup domain is a partly cooked feature and it is not very useful.
There is no reason
to use it for moving VMs from one environment to another.
I already explained how to move vms using a data domain. Check here:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ULLFLFKBAW7...
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GFOK55O5N4S...
I'm not sure it is documented properly, please file a documentation
bug if we need to
add something to the documentation.
> What you are then supposed to do with the cloned VM, if it's ok to simplay throw
it away, because the definition is silently copied to the OVF_STORE on the backup... none
of that is explained or mentioned.
If you cloned a vm to data domain and then detach the data domain
there is nothing to cleanup in the source system.
> There is also no procedure for restoring a machine from a backup domain, when really
a cloning process that allows a target domain would be pretty much what I'd vote for.
We have this in 4.4, try to select a VM and click "Export".
Nir