Description of problem: [Text] - The text '...the host's certification' is wrong when trying to change the management's network ip. If trying to change the management's network(ovirtmgmt) address via the setup networks dialog, a error message will displayed --> " Error while executing action: orchid-vds1.qa.lab.tlv.redhat.com: Cannot setup Networks. The address of the network 'ovirtmgmt' cannot be modified without reinstalling the host, since this address was used to create the host's certification." It should be ' the host's certificate.' Version-Release number of selected component (if applicable): 4.1.0-0.0.master.20160529171307.git359707b.el7.centos How reproducible: 100 Steps to Reproduce: 1. Try to modify the address of the network 'ovirtmgmt' Actual results: Error while executing action: orchid-vds1.qa.lab.tlv.redhat.com: Cannot setup Networks. The address of the network 'ovirtmgmt' cannot be modified without reinstalling the host, since this address was used to create the host's certification. Expected results: Error while executing action: orchid-vds1.qa.lab.tlv.redhat.com: Cannot setup Networks. The address of the network 'ovirtmgmt' cannot be modified without reinstalling the host, since this address was used to create the host's certificate.
Dan, in the current version 4.1.0-0.4.master.20170104122005.git51b1bcf.el7.centos.noarch engine allows me to modify the ovirtmgmt's IP and it actually trying to change it...in the end i'm failing on timeout and communication error with the host. 2017-01-05 09:41:02,023+02 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (default task-12) [7ea936c6-4ae2-4008-9da7-add0382ba1d2] START, HostSetupNetworksVDSCommand(HostName = camel -vdsa.qa.lab.tlv.redhat.com, HostSetupNetworksVdsCommandParameters:{runAsync='true', hostId='77026010-7b46-41a1-9263-2ed8b905c6e4', vds='Host[camel-vdsa.qa.lab.tlv.redhat.com,77026010-7b46-41a1-9263-2ed8b905c6e4]' , rollbackOnFailure='true', connectivityTimeout='120', networks='[HostNetwork:{defaultRoute='true', bonding='false', networkName='ovirtmgmt', nicName='enp4s0', vlan='null', mtu='0', vmNetwork='true', stp='false', properties='[]', ipv4BootProtocol='STATIC_IP', ipv4Address='10.35.129.15', ipv4Netmask='255.255.255.0', ipv4Gateway='10.35.128.254', ipv6BootProtocol='AUTOCONF', ipv6Address='null', ipv6Prefix='null', ipv6Gateway= 'null'}]', removedNetworks='[]', bonds='[]', removedBonds='[]', clusterSwitchType='LEGACY'}), log id: 74257e06 2017-01-05 09:41:02,025+02 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (default task-12) [7ea936c6-4ae2-4008-9da7-add0382ba1d2] FINISH, HostSetupNetworksVDSCommand, log id: 74257e 06 2017-01-05 09:41:05,589+02 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-12) [7ea936c6-4ae2-4008-9da7-add0382ba1d2] Command 'PollVDSCommand(HostName = camel-vdsa.qa.lab.tlv.redhat. com, VdsIdVDSCommandParametersBase:{runAsync='true', hostId='77026010-7b46-41a1-9263-2ed8b905c6e4'})' execution failed: VDSGenericException: VDSNetworkException: Timeout during rpc call 2017-01-05 09:44:01,185+02 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-12) [7ea936c6-4ae2-4008-9da7-add0382ba1d2] Timeout waiting for VDSM response: Internal timeout occured 2017-01-05 09:44:02,316+02 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-12) [7ea936c6-4ae2-4008-9da7-add0382ba1d2] Command 'PollVDSCommand(HostName = camel-vdsa.qa.lab.tlv.redhat. com, VdsIdVDSCommandParametersBase:{runAsync='true', hostId='77026010-7b46-41a1-9263-2ed8b905c6e4'})' execution failed: VDSGenericException: VDSNetworkException: Vds timeout occured 2017-01-05 09:44:02,316+02 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-12) [7ea936c6-4ae2-4008-9da7-add0382ba1d2] Error: VDSGenericException: VDSNetworkException: Vds timeout occ ured 2017-01-05 09:44:02,316+02 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetAllVmStatsVDSCommand] (DefaultQuartzScheduler6) [] Command 'GetAllVmStatsVDSCommand(HostName = camel-vdsa.qa.lab.tlv.redhat.com, VdsId VDSCommandParametersBase:{runAsync='true', hostId='77026010-7b46-41a1-9263-2ed8b905c6e4'})' execution failed: VDSGenericException: VDSNetworkException: Vds timeout occured 2017-01-05 09:44:02,329+02 INFO [org.ovirt.engine.core.vdsbroker.monitoring.PollVmStatsRefresher] (DefaultQuartzScheduler6) [] Failed to fetch vms info for host 'camel-vdsa.qa.lab.tlv.redhat.com' - skipping VMs m onitoring. 2017-01-05 09:44:02,327+02 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (org.ovirt.thread.pool-6-thread-6) [] Host 'camel-vdsa.qa.lab.tlv.redhat.com' is not responding. 2017-01-05 09:44:02,316+02 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-12) [7ea936c6-4ae2-4008-9da7-add0382ba1d2] Exception: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkE xception: VDSGenericException: VDSNetworkException: Vds timeout occured at org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.proceedProxyReturnValue(BrokerCommandBase.java:188) [vdsbroker.jar:] I don't see the 'Cannot setup Networks' error any more. We should have been block it, but engine allow it and trying to modify the host's management network while its up. It starting a HostSetupNetworksVDSCommand, but it shouldn't, no?
Please see BZ 1340702. Looks like the message in the subject isn't relevant anymore.
This was intentional: https://gerrit.ovirt.org/#/c/58538/ """ After rethinking about this validation we came to conclusion that the old and the new validations block cases that may be permitted by the vdsm. So we decided, for now, to remove the engine level validation. In case of a real problem, the vdsm will perform a rollback. """ Let us drop this string from the code.
Per comment 3, we do not need this label any more. It does not show in ovirt-4.1, and it would be dropped from the code in 4.2.
The string dropped from the code. Verified on - ovirt-engine-4.2.0-0.0.master.20170531203202.git1bf6667.el7.centos.noarch
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.