[ovirt-users] Re: Do distinct export domains share a name space? Can't export a VM, because it already exists in an unattached export domain...

Thanks Nir, flr the detailed explanation. Can you tell me with export/import data domains, what happens to VMs with snapshots.

Recently it was mentioned that snapahots are not visible after such migration.

Best Regards, Strahil Nikolov На 10 август 2020 г. 0:00:36 GMT+03:00, Nir Soffer <nsoffer(a)redhat.com&gt; написа: >On Wed, Aug 5, 2020 at 7:00 PM <thomas(a)hoberg.net&gt; 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_Existing_Storage_Domains >https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/administration_guide/sect-importing_existing_storage_domains > >Nir >_______________________________________________ >Users mailing list -- users(a)ovirt.org >To unsubscribe send an email to users-leave(a)ovirt.org >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/users@ovirt.org/message/ULLFLFKBAW7T7B6OD63BMNZXJK6EU6AI/