1:01 a.m.
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> написа:
>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_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/