All, I recently tried to used the OVA export/import functionality. It seems I misunderstood the intentions. I expected OVA export/import to be reciprocal functionalities. I expected what we export as OVA to be importable as OVA in ovirt. What I have found is the following: * It seems OVA export does export an OVA, though the format is not spec compliant * We use 'disk/' in the HostResource xml field instead of '/disk/' for example in the ovf. * It seems OVA import is intended specifically for VMWare OVA's? * I thought I read about export domains being deprecated, and incorrectly assumed the recently added OVA export/import was to make things better for one off import/export. Can anyone clarify the following: * Is OVA import really just VMWare OVA's? * Are we really not spec compliant with the OVA/OVF format as my example above shows? OR do I misunderstand something? * After spending my time yesterday, I recall now that the deprecation of export domain is in favor of detaching and re-attaching ANY data domain. * What is the purpose of our OVA export if we ourselves indeed cannot import our own OVA? Or can you tell me how we import our own if I'm wrong. Please feel free to overshare details :), as any context will help prevent more confusion on my part. ~Kyle
On Wed, Jun 13, 2018 at 4:04 PM, RabidCicada <rabidcicada@gmail.com> wrote:
All, I recently tried to used the OVA export/import functionality. It seems I misunderstood the intentions. I expected OVA export/import to be reciprocal functionalities. I expected what we export as OVA to be importable as OVA in ovirt.
What I have found is the following:
* It seems OVA export does export an OVA, though the format is not spec compliant * We use 'disk/' in the HostResource xml field instead of '/disk/' for example in the ovf. * It seems OVA import is intended specifically for VMWare OVA's? * I thought I read about export domains being deprecated, and incorrectly assumed the recently added OVA export/import was to make things better for one off import/export.
Can anyone clarify the following: * Is OVA import really just VMWare OVA's?
No, you can provide OVAs that were generated by oVirt as an input as well. See examples [1] and [2] for doing this via the python-sdk. Doing that from the webadmin is trivial is exactly like importing OVA that was generated by VMware. [1] https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/import_vm... [2] https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_ov...
* Are we really not spec compliant with the OVA/OVF format as my example above shows? OR do I misunderstand something?
Well, we now use the same code for parsing OVFs that were generated by oVirt and ones that were generated by VMware. So that's an evidence for being compliant with the specification to some degree. Indeed, there may be things that we don't use when reading the OVF, like the field you mentioned, and therefore there may be some gaps here and there. Is this the only gap you found so far? if so then I would say we are in a really good place since fixing that should be trivial, see [3]. You are more than welcome to send a patch! [3] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/ut...
* After spending my time yesterday, I recall now that the deprecation of export domain is in favor of detaching and re-attaching ANY data domain.
Depending what you're looking for. If you want to *move* your entities (VMs/templates) from one deployment to another then sure, detach the domain (that will cause those entities to be deleted from the source environment), attach the domain to the new deployment and register the entities you want. That is relatively quick operation since no copy is needed. Export domains/OVAs are targeted for different scenario - when you want to *copy* you entities from one deployment to another. You export them somewhere and than import them from that place.
* What is the purpose of our OVA export if we ourselves indeed cannot import our own OVA? Or can you tell me how we import our own if I'm wrong.
Already answered.
Please feel free to overshare details :), as any context will help prevent more confusion on my part.
~Kyle _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community- guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/ message/MYWHJF4ZJS4VSJ2RWBSYDPPOWTI6VWW5/
Thanks for the quick reply, I am using 4.2.3 and Ovirt cannot import it's own generated OVA. That is why my whole investigation started. Is it known to work for anyone else? Based on your statement it seems like it should be capable of importing it's own; But my install, perhaps JUST my install and no-one elses :), cannot do so. Can anyone verify import of ovirt generated OVA's works on ovirt 4.2.3? ~Kyle On Wed, Jun 13, 2018 at 9:54 AM, Arik Hadas <ahadas@redhat.com> wrote:
On Wed, Jun 13, 2018 at 4:04 PM, RabidCicada <rabidcicada@gmail.com> wrote:
All, I recently tried to used the OVA export/import functionality. It seems I misunderstood the intentions. I expected OVA export/import to be reciprocal functionalities. I expected what we export as OVA to be importable as OVA in ovirt.
What I have found is the following:
* It seems OVA export does export an OVA, though the format is not spec compliant * We use 'disk/' in the HostResource xml field instead of '/disk/' for example in the ovf. * It seems OVA import is intended specifically for VMWare OVA's? * I thought I read about export domains being deprecated, and incorrectly assumed the recently added OVA export/import was to make things better for one off import/export.
Can anyone clarify the following: * Is OVA import really just VMWare OVA's?
No, you can provide OVAs that were generated by oVirt as an input as well. See examples [1] and [2] for doing this via the python-sdk. Doing that from the webadmin is trivial is exactly like importing OVA that was generated by VMware.
[1] https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/import_vm... [2] https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_ov...
* Are we really not spec compliant with the OVA/OVF format as my example above shows? OR do I misunderstand something?
Well, we now use the same code for parsing OVFs that were generated by oVirt and ones that were generated by VMware. So that's an evidence for being compliant with the specification to some degree.
Indeed, there may be things that we don't use when reading the OVF, like the field you mentioned, and therefore there may be some gaps here and there.
Is this the only gap you found so far? if so then I would say we are in a really good place since fixing that should be trivial, see [3]. You are more than welcome to send a patch!
[3] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/ut...
* After spending my time yesterday, I recall now that the deprecation of export domain is in favor of detaching and re-attaching ANY data domain.
Depending what you're looking for. If you want to *move* your entities (VMs/templates) from one deployment to another then sure, detach the domain (that will cause those entities to be deleted from the source environment), attach the domain to the new deployment and register the entities you want. That is relatively quick operation since no copy is needed.
Export domains/OVAs are targeted for different scenario - when you want to *copy* you entities from one deployment to another. You export them somewhere and than import them from that place.
* What is the purpose of our OVA export if we ourselves indeed cannot import our own OVA? Or can you tell me how we import our own if I'm wrong.
Already answered.
Please feel free to overshare details :), as any context will help prevent more confusion on my part.
~Kyle _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/MYWHJF4ZJS4VSJ...
I am using the Web GUI. Not the python sdk. On Wed, Jun 13, 2018 at 9:58 AM, RabidCicada <rabidcicada@gmail.com> wrote:
Thanks for the quick reply,
I am using 4.2.3 and Ovirt cannot import it's own generated OVA. That is why my whole investigation started. Is it known to work for anyone else? Based on your statement it seems like it should be capable of importing it's own; But my install, perhaps JUST my install and no-one elses :), cannot do so. Can anyone verify import of ovirt generated OVA's works on ovirt 4.2.3?
~Kyle
On Wed, Jun 13, 2018 at 9:54 AM, Arik Hadas <ahadas@redhat.com> wrote:
On Wed, Jun 13, 2018 at 4:04 PM, RabidCicada <rabidcicada@gmail.com> wrote:
All, I recently tried to used the OVA export/import functionality. It seems I misunderstood the intentions. I expected OVA export/import to be reciprocal functionalities. I expected what we export as OVA to be importable as OVA in ovirt.
What I have found is the following:
* It seems OVA export does export an OVA, though the format is not spec compliant * We use 'disk/' in the HostResource xml field instead of '/disk/' for example in the ovf. * It seems OVA import is intended specifically for VMWare OVA's? * I thought I read about export domains being deprecated, and incorrectly assumed the recently added OVA export/import was to make things better for one off import/export.
Can anyone clarify the following: * Is OVA import really just VMWare OVA's?
No, you can provide OVAs that were generated by oVirt as an input as well. See examples [1] and [2] for doing this via the python-sdk. Doing that from the webadmin is trivial is exactly like importing OVA that was generated by VMware.
[1] https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/import_vm... [2] https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_ov...
* Are we really not spec compliant with the OVA/OVF format as my example above shows? OR do I misunderstand something?
Well, we now use the same code for parsing OVFs that were generated by oVirt and ones that were generated by VMware. So that's an evidence for being compliant with the specification to some degree.
Indeed, there may be things that we don't use when reading the OVF, like the field you mentioned, and therefore there may be some gaps here and there.
Is this the only gap you found so far? if so then I would say we are in a really good place since fixing that should be trivial, see [3]. You are more than welcome to send a patch!
[3] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/ut...
* After spending my time yesterday, I recall now that the deprecation of export domain is in favor of detaching and re-attaching ANY data domain.
Depending what you're looking for. If you want to *move* your entities (VMs/templates) from one deployment to another then sure, detach the domain (that will cause those entities to be deleted from the source environment), attach the domain to the new deployment and register the entities you want. That is relatively quick operation since no copy is needed.
Export domains/OVAs are targeted for different scenario - when you want to *copy* you entities from one deployment to another. You export them somewhere and than import them from that place.
* What is the purpose of our OVA export if we ourselves indeed cannot import our own OVA? Or can you tell me how we import our own if I'm wrong.
Already answered.
Please feel free to overshare details :), as any context will help prevent more confusion on my part.
~Kyle _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/MYWHJF4ZJS4VSJ...
On Wed, Jun 13, 2018 at 4:58 PM, RabidCicada <rabidcicada@gmail.com> wrote:
Thanks for the quick reply,
I am using 4.2.3 and Ovirt cannot import it's own generated OVA. That is why my whole investigation started. Is it known to work for anyone else? Based on your statement it seems like it should be capable of importing it's own; But my install, perhaps JUST my install and no-one elses :), cannot do so. Can anyone verify import of ovirt generated OVA's works on ovirt 4.2.3?
I would suggest to file a bug and attach the engine and ansible logs so we can investigate why it fails for you. It generally works in 4.2.3 but there were some fixes we've made in this area - you may have encountered some of those issues or discovered a new one :)
~Kyle
On Wed, Jun 13, 2018 at 9:54 AM, Arik Hadas <ahadas@redhat.com> wrote:
On Wed, Jun 13, 2018 at 4:04 PM, RabidCicada <rabidcicada@gmail.com>
All, I recently tried to used the OVA export/import functionality. It seems I misunderstood the intentions. I expected OVA export/import to be reciprocal functionalities. I expected what we export as OVA to be importable as OVA in ovirt.
What I have found is the following:
* It seems OVA export does export an OVA, though the format is not spec compliant * We use 'disk/' in the HostResource xml field instead of '/disk/' for example in the ovf. * It seems OVA import is intended specifically for VMWare OVA's? * I thought I read about export domains being deprecated, and incorrectly assumed the recently added OVA export/import was to make things better for one off import/export.
Can anyone clarify the following: * Is OVA import really just VMWare OVA's?
No, you can provide OVAs that were generated by oVirt as an input as well. See examples [1] and [2] for doing this via the python-sdk. Doing that from the webadmin is trivial is exactly like importing OVA that was generated by VMware.
[1] https://github.com/oVirt/ovirt-engine-sdk/blob/master/ sdk/examples/import_vm_from_ova.py [2] https://github.com/oVirt/ovirt-engine-sdk/blob/master/ sdk/examples/upload_ova_as_vm.py
* Are we really not spec compliant with the OVA/OVF format as my example above shows? OR do I misunderstand something?
Well, we now use the same code for parsing OVFs that were generated by oVirt and ones that were generated by VMware. So that's an evidence for being compliant with the specification to some degree.
Indeed, there may be things that we don't use when reading the OVF, like
wrote: the
field you mentioned, and therefore there may be some gaps here and there.
Is this the only gap you found so far? if so then I would say we are in a really good place since fixing that should be trivial, see [3]. You are more than welcome to send a patch!
[3] https://github.com/oVirt/ovirt-engine/blob/master/ backend/manager/modules/utils/src/main/java/org/ovirt/ engine/core/utils/ovf/OvfOvaWriter.java#L179
* After spending my time yesterday, I recall now that the deprecation of export domain is in favor of detaching and re-attaching ANY data domain.
Depending what you're looking for. If you want to *move* your entities (VMs/templates) from one deployment to another then sure, detach the domain (that will cause those entities to be deleted from the source environment), attach the domain to the new deployment and register the entities you want. That is relatively quick operation since no copy is needed.
Export domains/OVAs are targeted for different scenario - when you want to *copy* you entities from one deployment to another. You export them somewhere and than import them from that place.
* What is the purpose of our OVA export if we ourselves indeed cannot import our own OVA? Or can you tell me how we import our own if I'm wrong.
Already answered.
Please feel free to overshare details :), as any context will help prevent more confusion on my part.
~Kyle _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/
MYWHJF4ZJS4VSJ2RWBSYDPPOWTI6VWW5/
Arik, I've opened a bug here with all my information: https://bugzilla.redhat.com/show_bug.cgi?id=1590948 ~Kyle On Wed, Jun 13, 2018 at 10:04 AM, Arik Hadas <ahadas@redhat.com> wrote:
On Wed, Jun 13, 2018 at 4:58 PM, RabidCicada <rabidcicada@gmail.com> wrote:
Thanks for the quick reply,
I am using 4.2.3 and Ovirt cannot import it's own generated OVA. That is why my whole investigation started. Is it known to work for anyone else? Based on your statement it seems like it should be capable of importing it's own; But my install, perhaps JUST my install and no-one elses :), cannot do so. Can anyone verify import of ovirt generated OVA's works on ovirt 4.2.3?
I would suggest to file a bug and attach the engine and ansible logs so we can investigate why it fails for you. It generally works in 4.2.3 but there were some fixes we've made in this area - you may have encountered some of those issues or discovered a new one :)
~Kyle
On Wed, Jun 13, 2018 at 9:54 AM, Arik Hadas <ahadas@redhat.com> wrote:
On Wed, Jun 13, 2018 at 4:04 PM, RabidCicada <rabidcicada@gmail.com> wrote:
All, I recently tried to used the OVA export/import functionality. It seems I misunderstood the intentions. I expected OVA export/import to be reciprocal functionalities. I expected what we export as OVA to be importable as OVA in ovirt.
What I have found is the following:
* It seems OVA export does export an OVA, though the format is not spec compliant * We use 'disk/' in the HostResource xml field instead of '/disk/' for example in the ovf. * It seems OVA import is intended specifically for VMWare OVA's? * I thought I read about export domains being deprecated, and incorrectly assumed the recently added OVA export/import was to make things better for one off import/export.
Can anyone clarify the following: * Is OVA import really just VMWare OVA's?
No, you can provide OVAs that were generated by oVirt as an input as well. See examples [1] and [2] for doing this via the python-sdk. Doing that from the webadmin is trivial is exactly like importing OVA that was generated by VMware.
[1]
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/import_vm... [2]
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_ov...
* Are we really not spec compliant with the OVA/OVF format as my example above shows? OR do I misunderstand something?
Well, we now use the same code for parsing OVFs that were generated by oVirt and ones that were generated by VMware. So that's an evidence for being compliant with the specification to some degree.
Indeed, there may be things that we don't use when reading the OVF, like the field you mentioned, and therefore there may be some gaps here and there.
Is this the only gap you found so far? if so then I would say we are in a really good place since fixing that should be trivial, see [3]. You are more than welcome to send a patch!
[3]
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/ut...
* After spending my time yesterday, I recall now that the deprecation of export domain is in favor of detaching and re-attaching ANY data domain.
Depending what you're looking for. If you want to *move* your entities (VMs/templates) from one deployment to another then sure, detach the domain (that will cause those entities to be deleted from the source environment), attach the domain to the new deployment and register the entities you want. That is relatively quick operation since no copy is needed.
Export domains/OVAs are targeted for different scenario - when you want to *copy* you entities from one deployment to another. You export them somewhere and than import them from that place.
* What is the purpose of our OVA export if we ourselves indeed cannot import our own OVA? Or can you tell me how we import our own if I'm wrong.
Already answered.
Please feel free to overshare details :), as any context will help prevent more confusion on my part.
~Kyle _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MYWHJF4ZJS4VSJ...
On Wed, Jun 13, 2018 at 8:36 PM, RabidCicada <rabidcicada@gmail.com> wrote:
Arik, I've opened a bug here with all my information: https://bugzilla.redhat.com/show_bug.cgi?id=1590948
Thanks
~Kyle
On Wed, Jun 13, 2018 at 10:04 AM, Arik Hadas <ahadas@redhat.com> wrote:
On Wed, Jun 13, 2018 at 4:58 PM, RabidCicada <rabidcicada@gmail.com>
Thanks for the quick reply,
I am using 4.2.3 and Ovirt cannot import it's own generated OVA. That is why my whole investigation started. Is it known to work for anyone else? Based on your statement it seems like it should be capable of importing it's own; But my install, perhaps JUST my install and no-one elses :), cannot do so. Can anyone verify import of ovirt generated OVA's works on ovirt 4.2.3?
I would suggest to file a bug and attach the engine and ansible logs so we can investigate why it fails for you. It generally works in 4.2.3 but there were some fixes we've made in this area - you may have encountered some of those issues or discovered a new one :)
~Kyle
On Wed, Jun 13, 2018 at 9:54 AM, Arik Hadas <ahadas@redhat.com> wrote:
On Wed, Jun 13, 2018 at 4:04 PM, RabidCicada <rabidcicada@gmail.com> wrote:
All, I recently tried to used the OVA export/import functionality. It seems I misunderstood the intentions. I expected OVA export/import
to
be reciprocal functionalities. I expected what we export as OVA to be importable as OVA in ovirt.
What I have found is the following:
* It seems OVA export does export an OVA, though the format is not spec compliant * We use 'disk/' in the HostResource xml field instead of '/disk/' for example in the ovf. * It seems OVA import is intended specifically for VMWare OVA's? * I thought I read about export domains being deprecated, and incorrectly assumed the recently added OVA export/import was to make things better for one off import/export.
Can anyone clarify the following: * Is OVA import really just VMWare OVA's?
No, you can provide OVAs that were generated by oVirt as an input as well. See examples [1] and [2] for doing this via the python-sdk. Doing that from the webadmin is trivial is exactly like importing OVA that was generated by VMware.
[1]
https://github.com/oVirt/ovirt-engine-sdk/blob/master/ sdk/examples/import_vm_from_ova.py [2]
https://github.com/oVirt/ovirt-engine-sdk/blob/master/ sdk/examples/upload_ova_as_vm.py
* Are we really not spec compliant with the OVA/OVF format as my example above shows? OR do I misunderstand something?
Well, we now use the same code for parsing OVFs that were generated by oVirt and ones that were generated by VMware. So that's an evidence for being compliant with the specification to some degree.
Indeed, there may be things that we don't use when reading the OVF,
wrote: like
the field you mentioned, and therefore there may be some gaps here and there.
Is this the only gap you found so far? if so then I would say we are in a really good place since fixing that should be trivial, see [3]. You are more than welcome to send a patch!
[3]
https://github.com/oVirt/ovirt-engine/blob/master/ backend/manager/modules/utils/src/main/java/org/ovirt/ engine/core/utils/ovf/OvfOvaWriter.java#L179
* After spending my time yesterday, I recall now that the deprecation of export domain is in favor of detaching and re-attaching ANY data domain.
Depending what you're looking for. If you want to *move* your entities (VMs/templates) from one deployment to another then sure, detach the domain (that will cause those entities to be deleted from the source environment), attach the domain to the new deployment and register the entities you want. That is relatively quick operation since no copy is needed.
Export domains/OVAs are targeted for different scenario - when you want to *copy* you entities from one deployment to another. You export them somewhere and than import them from that place.
* What is the purpose of our OVA export if we ourselves indeed cannot import our own OVA? Or can you tell me how we import our own if I'm wrong.
Already answered.
Please feel free to overshare details :), as any context will help prevent more confusion on my part.
~Kyle _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/
MYWHJF4ZJS4VSJ2RWBSYDPPOWTI6VWW5/
All, It turns out the problem was enabling ssh/firewall rules on the expected ssh port for ovirt-engine. Error reporting in 4.2.4 is better and will fail earlier in the process according to the devs. If you experience symptoms similar to mine try making sure no firewall rules or sshd configurations are preventing ansible from talking to 'localhost' on the expected port. I have an install where we try to lock down the node after hosted-engine --deploy and we change the default ssh port. Most engine things had functioned properly until this so I was unaware that it had caused a problem. You can set OVEHOSTED_NETWORK/sshdPort in your answers file for hosted-engine --deploy to correctly set the port to an exotic port from the getgo. Thanks for the help devs, and I'm glad we have better error messages, or at least earlier failing, coming in 4.2.4. ~Kyle On Wed, Jun 13, 2018 at 6:01 PM, Arik Hadas <ahadas@redhat.com> wrote:
On Wed, Jun 13, 2018 at 8:36 PM, RabidCicada <rabidcicada@gmail.com> wrote:
Arik, I've opened a bug here with all my information: https://bugzilla.redhat.com/show_bug.cgi?id=1590948
Thanks
~Kyle
On Wed, Jun 13, 2018 at 10:04 AM, Arik Hadas <ahadas@redhat.com> wrote:
On Wed, Jun 13, 2018 at 4:58 PM, RabidCicada <rabidcicada@gmail.com> wrote:
Thanks for the quick reply,
I am using 4.2.3 and Ovirt cannot import it's own generated OVA. That is why my whole investigation started. Is it known to work for anyone else? Based on your statement it seems like it should be capable of importing it's own; But my install, perhaps JUST my install and no-one elses :), cannot do so. Can anyone verify import of ovirt generated OVA's works on ovirt 4.2.3?
I would suggest to file a bug and attach the engine and ansible logs so we can investigate why it fails for you. It generally works in 4.2.3 but there were some fixes we've made in this area - you may have encountered some of those issues or discovered a new one :)
~Kyle
On Wed, Jun 13, 2018 at 9:54 AM, Arik Hadas <ahadas@redhat.com> wrote:
On Wed, Jun 13, 2018 at 4:04 PM, RabidCicada <rabidcicada@gmail.com> wrote:
All, I recently tried to used the OVA export/import functionality. It seems I misunderstood the intentions. I expected OVA export/import to be reciprocal functionalities. I expected what we export as OVA to be importable as OVA in ovirt.
What I have found is the following:
* It seems OVA export does export an OVA, though the format is not spec compliant * We use 'disk/' in the HostResource xml field instead of '/disk/' for example in the ovf. * It seems OVA import is intended specifically for VMWare OVA's? * I thought I read about export domains being deprecated, and incorrectly assumed the recently added OVA export/import was to make things better for one off import/export.
Can anyone clarify the following: * Is OVA import really just VMWare OVA's?
No, you can provide OVAs that were generated by oVirt as an input as well. See examples [1] and [2] for doing this via the python-sdk. Doing that from the webadmin is trivial is exactly like importing OVA that was generated by VMware.
[1]
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/import_vm... [2]
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_ov...
* Are we really not spec compliant with the OVA/OVF format as my example above shows? OR do I misunderstand something?
Well, we now use the same code for parsing OVFs that were generated by oVirt and ones that were generated by VMware. So that's an evidence for being compliant with the specification to some degree.
Indeed, there may be things that we don't use when reading the OVF, like the field you mentioned, and therefore there may be some gaps here and there.
Is this the only gap you found so far? if so then I would say we are in a really good place since fixing that should be trivial, see [3]. You are more than welcome to send a patch!
[3]
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/ut...
* After spending my time yesterday, I recall now that the deprecation of export domain is in favor of detaching and re-attaching ANY data domain.
Depending what you're looking for. If you want to *move* your entities (VMs/templates) from one deployment to another then sure, detach the domain (that will cause those entities to be deleted from the source environment), attach the domain to the new deployment and register the entities you want. That is relatively quick operation since no copy is needed.
Export domains/OVAs are targeted for different scenario - when you want to *copy* you entities from one deployment to another. You export them somewhere and than import them from that place.
* What is the purpose of our OVA export if we ourselves indeed cannot import our own OVA? Or can you tell me how we import our own if I'm wrong.
Already answered.
Please feel free to overshare details :), as any context will help prevent more confusion on my part.
~Kyle _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MYWHJF4ZJS4VSJ...
On Wed, Jun 13, 2018, 4:05 PM RabidCicada <rabidcicada@gmail.com> wrote:
All, I recently tried to used the OVA export/import functionality. It seems I misunderstood the intentions. I expected OVA export/import to be reciprocal functionalities. I expected what we export as OVA to be importable as OVA in ovirt.
What I have found is the following:
* It seems OVA export does export an OVA, though the format is not spec compliant
Which spec? * We use 'disk/' in the HostResource xml field instead of '/disk/'
for example in the ovf.
Who's 'we'? * It seems OVA import is intended specifically for VMWare OVA's?
That's a common case, but we can look at other OVAs. The problem is that the spec is quite loose. Y. * I thought I read about export domains being deprecated, and
incorrectly assumed the recently added OVA export/import was to make things better for one off import/export.
Can anyone clarify the following: * Is OVA import really just VMWare OVA's? * Are we really not spec compliant with the OVA/OVF format as my example above shows? OR do I misunderstand something? * After spending my time yesterday, I recall now that the deprecation of export domain is in favor of detaching and re-attaching ANY data domain. * What is the purpose of our OVA export if we ourselves indeed cannot import our own OVA? Or can you tell me how we import our own if I'm wrong.
Please feel free to overshare details :), as any context will help prevent more confusion on my part.
~Kyle _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/MYWHJF4ZJS4VSJ...
participants (3)
-
Arik Hadas -
RabidCicada -
Yaniv Kaul