Hide Forgot
Description of problem: When asking for a NIC to bridge on, the script shows some options that are unusable and would cause the installer to crash later on. Version-Release number of selected component (if applicable): package version: 1.1.5-1.el6ev How reproducible: Easily Steps to Reproduce: 1. Install kvm, libvirt, ovirt, vdsm, etc. 2. Use something like virsh or virt-manager to create virtual networks, bridges etc. 3. Run "hosted-engine --deploy", when asked to select NIC for bridge, you will be shown wierd options like "virbr0-nic" 4. If you'll select on of those options, e.g. "virbr0-nic", the installed will later on fail to execute the network configuration stage. Actual results: - Example installer output: [ ERROR ] Failed to execute stage 'Misc configuration': 'virbr1-nic' - Excerpt from installer log: 2014-08-20 11:14:08 INFO otopi.plugins.ovirt_hosted_engine_setup.network.bridge bridge._misc:196 Configuring the management bridge 2014-08-20 11:14:09 DEBUG otopi.plugins.ovirt_hosted_engine_setup.network.bridge bridge._misc:204 getVdsCapabilities for virbr1-nic: {... 2014-08-20 11:14:09 DEBUG otopi.context context._executeMethod:152 method exception Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/otopi/context.py", line 142, in _executeMethod method['method']() File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/ovirt-hosted-engine-setup/network/bridge.py", line 223, in _misc caps = nics_caps[selected] KeyError: 'virbr1-nic' 2014-08-20 11:14:09 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Misc configuration': 'virbr1-nic' 2014-08-20 11:14:09 DEBUG otopi.transaction transaction.abort:131 aborting ... Expected results: Unusable NICs probably shouldn't show up as option in the installer Additional info: Digging in /usr/share/ovirt-hosted-engine-setup/plugins/ovirt-hosted-engine-setup/network/bridge.py It seems the _customization and _misc methods use different sources to obtain the list of NICs, while _customization uses the 'ethtool' module, _misc obtains the list from VDSM. Probably should both use VDSM.
In order to get the same device list, we'll change the first part of the customization for using vdsm instead of ethtool for getting the devices list.
Isn't it a dirty environment? Host should not have any virtual bridges/interfaces on it before hosted-engine deployment and also only "yum install ovirt-hosted-engine-setup -y" should trigger installation of all dependent packages like libvirt/quemu-kvm-rhev/sanlock/mom/etc, all these components should not be installed manually.
(In reply to Nikolai Sednev from comment #2) > Isn't it a dirty environment? Host should not have any virtual > bridges/interfaces on it before hosted-engine deployment and also only "yum > install ovirt-hosted-engine-setup -y" should trigger installation of all > dependent packages like libvirt/quemu-kvm-rhev/sanlock/mom/etc, all these > components should not be installed manually. I agree we shouldn't support dirty environments, however we have several specific cases such as ovirt-live which is supposed to ignore external interfaces and rely on an internal one. Another rare case is where we have a special layout the installer does not support and the user creates it manually. In most other cases we should discourage noisy environments.
This bug was fixed and is slated to be in the upcoming version. As we are focusing our testing at this phase on severe bugs, this bug was closed without going through its verification step. If you think this bug should be verified by QE, please set its severity to high and move it back to ON_QA