Do distinct export domains share a name space? Can't export a VM, because it already exists in an unattached export domain...
6:57 p.m.
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.
midnight
New subject: Do distinct export domains share a name space? Can't export a VM, because it already exists in an unattached export domain...
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
1:01 a.m.
New subject: 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> написа:
>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/
1:53 a.m.
New subject: Do distinct export domains share a name space? Can't export a VM, because it already exists in an unattached export domain...
On Mon, Aug 10, 2020 at 1:01 AM Strahil Nikolov <hunter86_bg(a)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(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/
1566
days inactive
1570
days old
3 comments
3 participants
participants (3)
-
Nir Soffer -
Strahil Nikolov -
thomas＠hoberg.net