update from 4.1.9 to 4.2.3 and OVN doubt
Hello, at beginning of 2017 I configured OVN in my oVirt 4.1.0 setup, with the previosulsy described notes, I think the ones here: http://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/ At that time OVN was not directly integrated in oVirt setup. Then I applied the updates in minor releases and coming at 4.1.9 level in late January this year. Now I plan to update to 4.2.3. I have doubts related to OVN setup. Will the new 4.2.3 OVN setup conflict with my current 4.1.x setup? WHat do I have to answer in setup related questions and prompt? In fact now, after enabling 4.2 repo and updating the setup itself, during the procedure (that I Canceled right now) I receive these questions: # engine-setup . . . [ INFO ] Stage: Environment packages setup [ INFO ] Stage: Programs detection [ INFO ] Stage: Environment setup [ INFO ] Stage: Environment customization --== PRODUCT OPTIONS ==-- Configure ovirt-provider-ovn (Yes, No) [Yes]: . . . --== OVIRT ENGINE CONFIGURATION ==-- Perform full vacuum on the engine database engine@localhost? This operation may take a while depending on this setup health and the configuration of the db vacuum process. See https://www.postgresql.org/docs/9.0/static/sql-vacuum.html (Yes, No) [No]: Yes oVirt OVN provider user[admin@internal]: what_to_put_here oVirt OVN provider password: . . . --== CONFIGURATION PREVIEW ==-- Default SAN wipe after delete : False Firewall manager : firewalld Update Firewall : True . . . Set up ovirt-provider-ovn : True . . . Configure VMConsole Proxy : True Please confirm installation settings (OK, Cancel) [OK]: Cancel Thanks for any hint. Gianluca
On Mon, May 21, 2018 at 3:34 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
Hello, at beginning of 2017 I configured OVN in my oVirt 4.1.0 setup, with the previosulsy described notes, I think the ones here: http://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/ At that time OVN was not directly integrated in oVirt setup. Then I applied the updates in minor releases and coming at 4.1.9 level in late January this year.
Now I plan to update to 4.2.3. I have doubts related to OVN setup. Will the new 4.2.3 OVN setup conflict with my current 4.1.x setup? WHat do I have to answer in setup related questions and prompt?
BTW: the version of ovirt-ovn-provider package installed during latest update to 4.1.9 has been Jan 15 09:14:50 Updated: ovirt-provider-ovn-1.0.9-0.el7.centos.noarch Today as pre-engine-setup phase it was updated to May 21 15:18:28 Updated: ovirt-provider-ovn-1.2.10-1.el7.centos.noarch I have seen this bugzilla in release notes of 4.2.1 https://bugzilla.redhat.com/show_bug.cgi?id=1529119 but I have not understood if it will apply to my setup and situation in final 4.2.3. Gianluca
Another information regarding my current environment: From engine database it results that my OVN provider name is "OVN" engine=# select id,name from providers; id | name --------------------------------------+------------------------ ceab03af-7220-4d42-8f5c-9b557f5d29af | ovirt-image-repository 84546a85-2958-4c1d-bbfe-afeb486ebda9 | OVN (2 rows) engine=# why it seems that in its default config it would name it "ovirt-provider-ovn"? Does this mean that it will be no conflict in name? But what about the current nortbridge and southbridge configs? Currently my central server is the engine (that is external to the infra) and it shows this: [root@ovmgr1 ~]# ovn-sbctl show Chassis "1dce5b7c-a9fc-4ddb-99b4-e2c9e0fa54c5" hostname: "ov200.mydomain" Encap geneve ip: "10.4.192.32" options: {csum="true"} Chassis "b8872ab5-4606-4a79-b77d-9d956a18d349" hostname: "ov301.mydomain" Encap geneve ip: "10.4.192.34" options: {csum="true"} Chassis "ddecf0da-4708-4f93-958b-6af365a5eeca" hostname: "ov300.mydomain" Encap geneve ip: "10.4.192.33" options: {csum="true"} [root@ovmgr1 ~]# and [root@ovmgr1 ~]# ovn-nbctl show switch 32367d8a-460f-4447-b35a-abe9ea5187e0 (ovn192) port affc5570-3e5a-439c-9fdf-d75d6810e3a3 addresses: ["00:1a:4a:17:01:73 dynamic"] port f639d541-2118-4c24-b478-b7a586eb170c addresses: ["00:1a:4a:17:01:75 dynamic"] switch 6110649a-db2b-4de7-8fbc-601095cfe510 (ovn192) switch 64c4c17f-cd67-4e29-939e-2b952495159f (ovn172) port 32c348d9-12e9-4bcf-a43f-69338c887cfc addresses: ["00:1a:4a:17:01:72 dynamic"] port 3c77c2ea-de00-43f9-a5c5-9b3ffea5ec69 addresses: ["00:1a:4a:17:01:74 dynamic"] switch 04501f6b-3977-4ba1-9ead-7096768d796d (ovn172) port 0a2a47bc-ea0d-4f1d-8f49-ec903e519983 addresses: ["00:1a:4a:17:01:65 dynamic"] port 8fc7bed4-7663-4903-922b-05e490c6a5a1 addresses: ["00:1a:4a:17:01:64 dynamic"] port f2b64f89-b719-484c-ac02-2a1ac8eaacdb addresses: ["00:1a:4a:17:01:59 dynamic"] port f7389c88-1ea1-47c2-92fd-6beffb2e2190 addresses: ["00:1a:4a:17:01:58 dynamic"] [root@ovmgr1 ~]# and on my hosts currently I have something like this (eg on ov200): [root@ov200 ~]# ovs-vsctl show ae0a1256-7250-46a2-a1b6-8f0ae6105c20 Bridge br-int fail_mode: secure Port br-int Interface br-int type: internal Port "ovn-ddecf0-0" Interface "ovn-ddecf0-0" type: geneve options: {csum="true", key=flow, remote_ip="10.4.192.33"} Port "ovn-b8872a-0" Interface "ovn-b8872a-0" type: geneve options: {csum="true", key=flow, remote_ip="10.4.192.34"} ovs_version: "2.7.3" [root@ov200 ~]#
Hi, Adding also Marcin here. I reproduced it as well and I can confirm that the external provider was called 'OVN' by default at 4.1 time but now engine-setup will create by default a new provider called 'ovirt-provider-ovn'. Both the two providers are now configured in the engine to be reached at https://<enginevm_ip>:9696 The engine can successfully talk with ovirt-provider-ovn while I get errors like 'Error while listing external networks: EngineException: (Failed with error Connection reset and code 5050)' when I try to query the old OVN provider. Logical networks previously attached to the old OVN provider are still there in the engine and they are still attached to the old OVN provider. Unfortunately I'm not able to start/restart VMs with interfaces on a logical network defined on the OVN provider. I manually recreated the missing networks on the new 'ovirt-provider-ovn' provider and I reattached my VMs there and at that point I was finally able to start again my VMs. On Mon, May 21, 2018 at 4:55 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
Another information regarding my current environment: From engine database it results that my OVN provider name is "OVN"
engine=# select id,name from providers; id | name --------------------------------------+------------------------ ceab03af-7220-4d42-8f5c-9b557f5d29af | ovirt-image-repository 84546a85-2958-4c1d-bbfe-afeb486ebda9 | OVN (2 rows)
engine=#
why it seems that in its default config it would name it "ovirt-provider-ovn"? Does this mean that it will be no conflict in name? But what about the current nortbridge and southbridge configs?
Currently my central server is the engine (that is external to the infra) and it shows this:
[root@ovmgr1 ~]# ovn-sbctl show Chassis "1dce5b7c-a9fc-4ddb-99b4-e2c9e0fa54c5" hostname: "ov200.mydomain" Encap geneve ip: "10.4.192.32" options: {csum="true"} Chassis "b8872ab5-4606-4a79-b77d-9d956a18d349" hostname: "ov301.mydomain" Encap geneve ip: "10.4.192.34" options: {csum="true"} Chassis "ddecf0da-4708-4f93-958b-6af365a5eeca" hostname: "ov300.mydomain" Encap geneve ip: "10.4.192.33" options: {csum="true"} [root@ovmgr1 ~]#
and
[root@ovmgr1 ~]# ovn-nbctl show switch 32367d8a-460f-4447-b35a-abe9ea5187e0 (ovn192) port affc5570-3e5a-439c-9fdf-d75d6810e3a3 addresses: ["00:1a:4a:17:01:73 dynamic"] port f639d541-2118-4c24-b478-b7a586eb170c addresses: ["00:1a:4a:17:01:75 dynamic"] switch 6110649a-db2b-4de7-8fbc-601095cfe510 (ovn192) switch 64c4c17f-cd67-4e29-939e-2b952495159f (ovn172) port 32c348d9-12e9-4bcf-a43f-69338c887cfc addresses: ["00:1a:4a:17:01:72 dynamic"] port 3c77c2ea-de00-43f9-a5c5-9b3ffea5ec69 addresses: ["00:1a:4a:17:01:74 dynamic"] switch 04501f6b-3977-4ba1-9ead-7096768d796d (ovn172) port 0a2a47bc-ea0d-4f1d-8f49-ec903e519983 addresses: ["00:1a:4a:17:01:65 dynamic"] port 8fc7bed4-7663-4903-922b-05e490c6a5a1 addresses: ["00:1a:4a:17:01:64 dynamic"] port f2b64f89-b719-484c-ac02-2a1ac8eaacdb addresses: ["00:1a:4a:17:01:59 dynamic"] port f7389c88-1ea1-47c2-92fd-6beffb2e2190 addresses: ["00:1a:4a:17:01:58 dynamic"] [root@ovmgr1 ~]#
and on my hosts currently I have something like this (eg on ov200):
[root@ov200 ~]# ovs-vsctl show ae0a1256-7250-46a2-a1b6-8f0ae6105c20 Bridge br-int fail_mode: secure Port br-int Interface br-int type: internal Port "ovn-ddecf0-0" Interface "ovn-ddecf0-0" type: geneve options: {csum="true", key=flow, remote_ip="10.4.192.33"} Port "ovn-b8872a-0" Interface "ovn-b8872a-0" type: geneve options: {csum="true", key=flow, remote_ip="10.4.192.34"} ovs_version: "2.7.3" [root@ov200 ~]#
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org
On Tue, May 22, 2018 at 5:27 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:
Hi, Adding also Marcin here. I reproduced it as well and I can confirm that the external provider was called 'OVN' by default at 4.1 time but now engine-setup will create by default a new provider called 'ovirt-provider-ovn'. Both the two providers are now configured in the engine to be reached at https://<enginevm_ip>:9696
The engine can successfully talk with ovirt-provider-ovn while I get errors like 'Error while listing external networks: EngineException: (Failed with error Connection reset and code 5050)' when I try to query the old OVN provider. Logical networks previously attached to the old OVN provider are still there in the engine and they are still attached to the old OVN provider. Unfortunately I'm not able to start/restart VMs with interfaces on a logical network defined on the OVN provider. I manually recreated the missing networks on the new 'ovirt-provider-ovn' provider and I reattached my VMs there and at that point I was finally able to start again my VMs.
Another strange behavior. I was't able to remove the old OVN provider since a few logical networks was still attached to that. So I removed all of them from the engine and then I manually removed the old OVN provider and only at this point all of my old logical networks manually reappeared in the engine as attached to the new 4.2 'ovirt-provider-ovn'.
On Mon, May 21, 2018 at 4:55 PM, Gianluca Cecchi < gianluca.cecchi@gmail.com> wrote:
Another information regarding my current environment: From engine database it results that my OVN provider name is "OVN"
engine=# select id,name from providers; id | name --------------------------------------+------------------------ ceab03af-7220-4d42-8f5c-9b557f5d29af | ovirt-image-repository 84546a85-2958-4c1d-bbfe-afeb486ebda9 | OVN (2 rows)
engine=#
why it seems that in its default config it would name it "ovirt-provider-ovn"? Does this mean that it will be no conflict in name? But what about the current nortbridge and southbridge configs?
Currently my central server is the engine (that is external to the infra) and it shows this:
[root@ovmgr1 ~]# ovn-sbctl show Chassis "1dce5b7c-a9fc-4ddb-99b4-e2c9e0fa54c5" hostname: "ov200.mydomain" Encap geneve ip: "10.4.192.32" options: {csum="true"} Chassis "b8872ab5-4606-4a79-b77d-9d956a18d349" hostname: "ov301.mydomain" Encap geneve ip: "10.4.192.34" options: {csum="true"} Chassis "ddecf0da-4708-4f93-958b-6af365a5eeca" hostname: "ov300.mydomain" Encap geneve ip: "10.4.192.33" options: {csum="true"} [root@ovmgr1 ~]#
and
[root@ovmgr1 ~]# ovn-nbctl show switch 32367d8a-460f-4447-b35a-abe9ea5187e0 (ovn192) port affc5570-3e5a-439c-9fdf-d75d6810e3a3 addresses: ["00:1a:4a:17:01:73 dynamic"] port f639d541-2118-4c24-b478-b7a586eb170c addresses: ["00:1a:4a:17:01:75 dynamic"] switch 6110649a-db2b-4de7-8fbc-601095cfe510 (ovn192) switch 64c4c17f-cd67-4e29-939e-2b952495159f (ovn172) port 32c348d9-12e9-4bcf-a43f-69338c887cfc addresses: ["00:1a:4a:17:01:72 dynamic"] port 3c77c2ea-de00-43f9-a5c5-9b3ffea5ec69 addresses: ["00:1a:4a:17:01:74 dynamic"] switch 04501f6b-3977-4ba1-9ead-7096768d796d (ovn172) port 0a2a47bc-ea0d-4f1d-8f49-ec903e519983 addresses: ["00:1a:4a:17:01:65 dynamic"] port 8fc7bed4-7663-4903-922b-05e490c6a5a1 addresses: ["00:1a:4a:17:01:64 dynamic"] port f2b64f89-b719-484c-ac02-2a1ac8eaacdb addresses: ["00:1a:4a:17:01:59 dynamic"] port f7389c88-1ea1-47c2-92fd-6beffb2e2190 addresses: ["00:1a:4a:17:01:58 dynamic"] [root@ovmgr1 ~]#
and on my hosts currently I have something like this (eg on ov200):
[root@ov200 ~]# ovs-vsctl show ae0a1256-7250-46a2-a1b6-8f0ae6105c20 Bridge br-int fail_mode: secure Port br-int Interface br-int type: internal Port "ovn-ddecf0-0" Interface "ovn-ddecf0-0" type: geneve options: {csum="true", key=flow, remote_ip="10.4.192.33"} Port "ovn-b8872a-0" Interface "ovn-b8872a-0" type: geneve options: {csum="true", key=flow, remote_ip="10.4.192.34"} ovs_version: "2.7.3" [root@ov200 ~]#
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org
On Tue, May 22, 2018 at 5:35 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:
On Tue, May 22, 2018 at 5:27 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:
Hi, Adding also Marcin here. I reproduced it as well and I can confirm that the external provider was called 'OVN' by default at 4.1 time but now engine-setup will create by default a new provider called 'ovirt-provider-ovn'. Both the two providers are now configured in the engine to be reached at https://<enginevm_ip>:9696
The engine can successfully talk with ovirt-provider-ovn while I get errors like 'Error while listing external networks: EngineException: (Failed with error Connection reset and code 5050)' when I try to query the old OVN provider. Logical networks previously attached to the old OVN provider are still there in the engine and they are still attached to the old OVN provider. Unfortunately I'm not able to start/restart VMs with interfaces on a logical network defined on the OVN provider. I manually recreated the missing networks on the new 'ovirt-provider-ovn' provider and I reattached my VMs there and at that point I was finally able to start again my VMs.
Another strange behavior. I was't able to remove the old OVN provider since a few logical networks was still attached to that. So I removed all of them from the engine and then I manually removed the old OVN provider and only at this point all of my old logical networks manually reappeared in the engine as attached to the new 4.2 'ovirt-provider-ovn'.
Thank you very much Simone for your tests! This is a test environment, but with about 40 VMs of a certain importance and I would like to preserve it in 4.2 So with your tests you are confirming that the engine-setup for updating engine completes without problems and impacts on current databases and then the update of the hosts doesn't go into exception, correct? I can manage to have a temporary downtime for the few VMs defined on ovn (mainly used as intracluster network) and re-setup them on the new provider in 4.2 Just a curiosity: does this mean that when the engine-setup should configure the Northbound and Southbound DBs (and not... bridge... as I wrote before ;-) it simply skips without aborting? This was one of my major concerns... Gianluca
On Tue, May 22, 2018 at 5:50 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Tue, May 22, 2018 at 5:35 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:
On Tue, May 22, 2018 at 5:27 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:
Hi, Adding also Marcin here. I reproduced it as well and I can confirm that the external provider was called 'OVN' by default at 4.1 time but now engine-setup will create by default a new provider called 'ovirt-provider-ovn'. Both the two providers are now configured in the engine to be reached at https://<enginevm_ip>:9696
The engine can successfully talk with ovirt-provider-ovn while I get errors like 'Error while listing external networks: EngineException: (Failed with error Connection reset and code 5050)' when I try to query the old OVN provider. Logical networks previously attached to the old OVN provider are still there in the engine and they are still attached to the old OVN provider. Unfortunately I'm not able to start/restart VMs with interfaces on a logical network defined on the OVN provider. I manually recreated the missing networks on the new 'ovirt-provider-ovn' provider and I reattached my VMs there and at that point I was finally able to start again my VMs.
Another strange behavior. I was't able to remove the old OVN provider since a few logical networks was still attached to that. So I removed all of them from the engine and then I manually removed the old OVN provider and only at this point all of my old logical networks manually reappeared in the engine as attached to the new 4.2 'ovirt-provider-ovn'.
Thank you very much Simone for your tests! This is a test environment, but with about 40 VMs of a certain importance and I would like to preserve it in 4.2 So with your tests you are confirming that the engine-setup for updating engine completes without problems and impacts on current databases and then the update of the hosts doesn't go into exception, correct?
I simply had to manually restart ovn related services on the host to reestablish correct TLS communication. No other issue on host side.
I can manage to have a temporary downtime for the few VMs defined on ovn (mainly used as intracluster network) and re-setup them on the new provider in 4.2
Just a curiosity: does this mean that when the engine-setup should configure the Northbound and Southbound DBs (and not... bridge... as I wrote before ;-) it simply skips without aborting? This was one of my major concerns...
Yes, no errors from engine-setup; all the OVN related services got reconfigured and their TLS cert got regenerated.
Gianluca
Hi Gianluca, The provider in version 4.1 was installed automatically, but it did not save the fact of being installed. Hence if you try to install it in 4.2, it will try to install itself again (and this time it will save the info of being installed). I'm planning to add a feature that will allow reusing an already existing provider during engine-setup. For now you can skip the provider installation, the existing one will be kept as it is. Thanks, Marcin On Mon, May 21, 2018 at 4:55 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
Another information regarding my current environment: From engine database it results that my OVN provider name is "OVN"
engine=# select id,name from providers; id | name --------------------------------------+------------------------ ceab03af-7220-4d42-8f5c-9b557f5d29af | ovirt-image-repository 84546a85-2958-4c1d-bbfe-afeb486ebda9 | OVN (2 rows)
engine=#
why it seems that in its default config it would name it "ovirt-provider-ovn"? Does this mean that it will be no conflict in name? But what about the current nortbridge and southbridge configs?
Currently my central server is the engine (that is external to the infra) and it shows this:
[root@ovmgr1 ~]# ovn-sbctl show Chassis "1dce5b7c-a9fc-4ddb-99b4-e2c9e0fa54c5" hostname: "ov200.mydomain" Encap geneve ip: "10.4.192.32" options: {csum="true"} Chassis "b8872ab5-4606-4a79-b77d-9d956a18d349" hostname: "ov301.mydomain" Encap geneve ip: "10.4.192.34" options: {csum="true"} Chassis "ddecf0da-4708-4f93-958b-6af365a5eeca" hostname: "ov300.mydomain" Encap geneve ip: "10.4.192.33" options: {csum="true"} [root@ovmgr1 ~]#
and
[root@ovmgr1 ~]# ovn-nbctl show switch 32367d8a-460f-4447-b35a-abe9ea5187e0 (ovn192) port affc5570-3e5a-439c-9fdf-d75d6810e3a3 addresses: ["00:1a:4a:17:01:73 dynamic"] port f639d541-2118-4c24-b478-b7a586eb170c addresses: ["00:1a:4a:17:01:75 dynamic"] switch 6110649a-db2b-4de7-8fbc-601095cfe510 (ovn192) switch 64c4c17f-cd67-4e29-939e-2b952495159f (ovn172) port 32c348d9-12e9-4bcf-a43f-69338c887cfc addresses: ["00:1a:4a:17:01:72 dynamic"] port 3c77c2ea-de00-43f9-a5c5-9b3ffea5ec69 addresses: ["00:1a:4a:17:01:74 dynamic"] switch 04501f6b-3977-4ba1-9ead-7096768d796d (ovn172) port 0a2a47bc-ea0d-4f1d-8f49-ec903e519983 addresses: ["00:1a:4a:17:01:65 dynamic"] port 8fc7bed4-7663-4903-922b-05e490c6a5a1 addresses: ["00:1a:4a:17:01:64 dynamic"] port f2b64f89-b719-484c-ac02-2a1ac8eaacdb addresses: ["00:1a:4a:17:01:59 dynamic"] port f7389c88-1ea1-47c2-92fd-6beffb2e2190 addresses: ["00:1a:4a:17:01:58 dynamic"] [root@ovmgr1 ~]#
and on my hosts currently I have something like this (eg on ov200):
[root@ov200 ~]# ovs-vsctl show ae0a1256-7250-46a2-a1b6-8f0ae6105c20 Bridge br-int fail_mode: secure Port br-int Interface br-int type: internal Port "ovn-ddecf0-0" Interface "ovn-ddecf0-0" type: geneve options: {csum="true", key=flow, remote_ip="10.4.192.33"} Port "ovn-b8872a-0" Interface "ovn-b8872a-0" type: geneve options: {csum="true", key=flow, remote_ip="10.4.192.34"} ovs_version: "2.7.3" [root@ov200 ~]#
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org
On Wed, May 23, 2018 at 10:04 AM, Marcin Mirecki <mmirecki@redhat.com> wrote:
Hi Gianluca,
The provider in version 4.1 was installed automatically, but it did not save the fact of being installed. Hence if you try to install it in 4.2, it will try to install itself again (and this time it will save the info of being installed).
I'm planning to add a feature that will allow reusing an already existing provider during engine-setup. For now you can skip the provider installation, the existing one will be kept as it is.
Thanks, Marcin
If the reinstall doesn't imply broken upgrade it is not a problem for me and then delete the old ovn setup and reconfigure the few vnics involved with OVN on the new environment. If I choose to install the new one, the two inputs required: oVirt OVN provider user[admin@internal]: oVirt OVN provider password: can be any settings or have to be related with the old setup? So you advise to keep the old one and skip OVN for now and I can continue to use in the mean time the OVN provider already setup in 4.1, correct? Then in a future 4.2.x release when I will run engine-setup again I can choose instead to install ovn provider, and it will keep anyway the already configured one without need to resetup OVN and vNICS, correct? In this case I will follow what you suggest. Gianluca
If the old setup is working, I would keep it, and manually update the provider and openvswitch (yum update ...). In the future 4.2 I hope the feature of re-using an existing provider will already be there. The setup is asking for user and password because we do not store these values across invocations of engine-setup. During a fresh install run we have it, as the user has to set it up, on update runs we don't. The provider needs this in order to authenticate users using ovirt-engine authentication. Ovirt authentication for the provider can be disabled, but this has to be done manually. On Wed, May 23, 2018 at 10:22 AM, Gianluca Cecchi <gianluca.cecchi@gmail.com
wrote:
On Wed, May 23, 2018 at 10:04 AM, Marcin Mirecki <mmirecki@redhat.com> wrote:
Hi Gianluca,
The provider in version 4.1 was installed automatically, but it did not save the fact of being installed. Hence if you try to install it in 4.2, it will try to install itself again (and this time it will save the info of being installed).
I'm planning to add a feature that will allow reusing an already existing provider during engine-setup. For now you can skip the provider installation, the existing one will be kept as it is.
Thanks, Marcin
If the reinstall doesn't imply broken upgrade it is not a problem for me and then delete the old ovn setup and reconfigure the few vnics involved with OVN on the new environment.
If I choose to install the new one, the two inputs required:
oVirt OVN provider user[admin@internal]: oVirt OVN provider password:
can be any settings or have to be related with the old setup?
So you advise to keep the old one and skip OVN for now and I can continue to use in the mean time the OVN provider already setup in 4.1, correct? Then in a future 4.2.x release when I will run engine-setup again I can choose instead to install ovn provider, and it will keep anyway the already configured one without need to resetup OVN and vNICS, correct? In this case I will follow what you suggest.
Gianluca
participants (3)
-
Gianluca Cecchi -
Marcin Mirecki -
Simone Tiraboschi