Created attachment 793927 [details] ovirt-engine-setup Description of problem: AIO: engine-setup doesn't pass hostname validation step because of the following error: [ ERROR ] Host name is not valid: The following addreses: 192.168.1.1 can't be mapped to non loopback devices on this host Version-Release number of selected component (if applicable): 3.3 rpms from 4th Sep How reproducible: 100% Steps to Reproduce: 1. Configure LACP bond 2. Add vlan interface on top of the bond interface 3. install AIO and run engine-setup Actual results: engine-setup [ INFO ] Stage: Initializing [ INFO ] Stage: Environment setup Configuration files: ['/etc/ovirt-engine-setup.conf.d/10-packaging-aio.conf', '/etc/ovirt-engine-setup.conf.d/10-packaging.conf'] Log file: /var/log/ovirt-engine/setup/ovirt-engine-setup-20130904212926.log Version: otopi-1.1.0 (otopi-1.1.0-1.el6) [ INFO ] Hardware supports virtualization [ INFO ] Stage: Environment packages setup [ INFO ] Stage: Programs detection [ INFO ] Stage: Environment setup [ INFO ] Stage: Environment customization Configure VDSM on this host? (Yes, No) [No]: Yes Local storage domain path [/var/lib/images]: /storage/images Local storage domain name [local_storage]: --== PACKAGES ==-- [ INFO ] Checking for product updates... [ INFO ] No product updates found --== NETWORK CONFIGURATION ==-- Host fully qualified DNS name of this server [somedom.example.com]: [ ERROR ] Host name is not valid: The following addreses: 192.168.100.7 can't be mapped to non loopback devices on this host Host fully qualified DNS name of this server [somedom.example.com]: Expected results: go to the next step Additional info: OS: CentOS 6.4 x86_64 latest updates available extra repo: EPEL, Ovirt 3.3 beta Network config: 2 x eth in LACP bond and VLAN interface on top of bond interface DNS: forward and reverse DNS is working for the specified hostname
Just want to add that if I start with a plain eth0 config , the install works fine and then if I do the bond and the vlan configs from admin portal everything works as expected. So I guess this might behave as intended and if that's the case this is not a bug. Cheers Liviu
Thanks! Was a problem in re.
closing as this should be in 3.3 (doing so in bulk, so may be incorrect)