midnight
On Wed, Aug 5, 2020 at 7:00 PM <thomas(a)hoberg.net> wrote:
After OVA export/import was a) recommended against b) not working with the current 4.3 on
CentOS 7, I am trying to make sure I keep working copies of critical VMs before I test if
the OVA export now works properly, with the Redhat fix from 4.4. applied to 4.3.
Long story short, I have an export domain "export", primarily attached to a 3
node HCI gluster-cluster and another domain "exportMono", primarily attached to
a single node HCI gluster-cluster.
Yes I use an export domain for backup, because, ...well there is no easy and working
alternative out of the box, or did I overlook something?
But of course, I also use an export domain for shipping between farms, so evidently I
swap export domains like good old PDP-11 disk cartridges.... or at least I'd like to.
I started by exporting VM "tdc" from the 1nHCI to exportMono, reattached that
to 3nHCI for am import. Import worked everything fine, transfer succeed. So I detach
exportMono, which belongs to the 1nHCI cluster.
Next I do the OVA export on 1nHCI, but I need to get the working and reconfigured VM
"tdc" out of the way on 3nHCI, so I dump it into the "export" export
domain belonging to 3nHCI, because I understand I can't run two copies of the same VM
on a single cluster.
Turns out I can' export it, because even if the export domain is now a different one
and definitely doesn't contain "tdc" at all, oVirt complains that the volume
ID that belongs to "tdc" already exists in the export domain....
So what's the theory here behind export domains? And what's the state of their
support in oVirt 4.4?
Export domains are deprecated for several releases, but they were not removed
in 4.4, mainly to make it easier to upgrade to 4.4.
They are deprecated because we have better solutions, mainly export import data
domain (since 3.6), and also upload/download disks (since 4.0), and
export/import
OVA.
To move a VM to another environment using a data domain in 4.3:
- Create or attach a data storage domain of any type to use as an
"export" domain
- Move the VM disks to the data domain. This can be done while the VM
is running.
- Stop the exported VM.
- Detach the data domain from the system
- Attach the data domain to another system
- Import the VM from the data domain
- Start the imported VM
- If you want to continue using this data domain as an export domain,
move the VM disks to another domain. This can be done while the VM is running.
This minimizes the downtime to the time it takes to detach the domain
from one system
and attach to another system. If you don't care about downtime, you
can stop the VM
before the export and start it after copying the imported VM disks.
This is much simpler
and more reliable.
In the best case, when you have a data domain that you want to move to
another system,
no data copy is needed. In the worst case when you want to move VM
from one storage
on another storage on another system, you need to move the disks twice
- just like export
domain.
If you want to move the VM to another hypervisor, OVA export is not
helpful since OVA is
not a real standard and hypervisors do not support other hypervisor
OVAs without some
conversion tool such as virt-v2v. oVirt uses virt-v2v to import VMWare
OVA to oVirt. I don't
know if this tool supports converting oVirt OVA to other hypervisors.
To move VM disks out of the system in 4.3:
- Stop the VM, or create a snapshot.
- Create a template from the VM or the snapshot, selecting qcow2 format
- Start the VM if needed, or delete the snapshot.
- Download the template disks, from the UI or using the API/SDK if you
want a faster
download that can be scripted.
- Delete the template if not needed
Why create a template instead of cloning the VM? because cloning may create raw
preallocated disks (depending on the storage type and the original VM)
and downloading
a preallocated disk is not efficient and creates fully preallocated
images which are much
larger than needed.
To move the disk back to oVirt, upload the disk to oVirt and create a new VM.
This can be done from the UI or using the API/SDK.
The entire process can be scripted. In 4.4 backup_vm.py example does
all this without
creating snapshot or templates (see my previous mail about backup).
I understand that distinct farms can't share an export domain,
because they have no way of coordinating properly. Of course I tried to use one single NFS
mount for both farms but the second farm properly detected the presense of another and
required a distinct path.
But from the evidence before me, oVirt doesn't support or like the existance of more
than one export domain, either: Something that deserves a note or explanation.
Yes, export domains have many limitations.
I understand they are deprecated in 4.3 already, but since they are
also the only way to manage valuable VM images moving around, that currently works with
the GUI on oVirt 4.3 it would be nice to have these questions answered.
They are not the only way.
Did you read oVirt/RHV documentation?
https://ovirt.org/documentation/administration_guide/#sect-Importing_Exis...
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/...
Nir