Do distinct export domains share a name space? Can't export a VM, because it already exists in an unattached export domain...
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? 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. 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.
On Wed, Aug 5, 2020 at 7:00 PM <thomas@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_Existin... https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/htm... Nir
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@redhat.com> написа:
On Wed, Aug 5, 2020 at 7:00 PM <thomas@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
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,
easy and working alternative out of the box, or did I overlook something? 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_Existin... https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/htm...
Nir _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@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/ULLFLFKBAW7T7B...
On Mon, Aug 10, 2020 at 1:01 AM Strahil Nikolov <hunter86_bg@yahoo.com> wrote:
Thanks Nir, flr the detailed explanation. Can you tell me with export/import data domains, what happens to VMs with snapshots.
Snapshots are not affected by moving disks to different storage domains. It copies the entire chain from one domain to the other. If you want collapsed snapshots you need to use export VM (4.4+), clone VM, or make template.
Recently it was mentioned that snapahots are not visible after such migration.
Can you point to the thread about this?
Best Regards, Strahil Nikolov
На 10 август 2020 г. 0:00:36 GMT+03:00, Nir Soffer <nsoffer@redhat.com> написа:
On Wed, Aug 5, 2020 at 7:00 PM <thomas@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
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,
easy and working alternative out of the box, or did I overlook something? 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_Existin... https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/htm...
Nir _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@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/ULLFLFKBAW7T7B...
participants (3)
-
Nir Soffer -
Strahil Nikolov -
thomas＠hoberg.net