On Tue, May 22, 2018 at 5:50 PM, Gianluca Cecchi <gianluca.cec...@gmail.com> wrote:
> On Tue, May 22, 2018 at 5:35 PM, Simone Tiraboschi <stira...@redhat.com> > wrote: > >> >> >> On Tue, May 22, 2018 at 5:27 PM, Simone Tiraboschi <stira...@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 >
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org
