Bug 1396316

your ifcfg-ovirtmgmt file seems to be manually-written. do you have vdsm-ovirtmgmt listed in `virsh -r net-list`?

Defining a network outside vdsm is not recomended, but if you do it, you should do it completely. (e.g. cf. Bug 1301879 comment 1)

Can you share your /var/log/vdsm/supervdsm.log?

[myoung@server ~]$ virsh -r net-list
 Name                 State      Autostart     Persistent
----------------------------------------------------------


it's empty. so i created file with that xml and created it via virsh

[myoung@server ~]$ cat file
<network>
  <name>vdsm-ovirtmgmt</name>
  <uuid>34127d8a-0f80-4888-839a-bbfcf12339dc</uuid>
  <forward mode='bridge'/>
  <bridge name='ovirtmgmt'/>
</network>

[myoung@server ~]$ virsh net-create file
Network vdsm-ovirtmgmt created from file

[myoung@server ~]$ virsh -r net-list
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 vdsm-ovirtmgmt       active     no            no


Then I click 'activate' via UI and this is what /var/log/vdsm/supervdsm.log shows during that event:

MainProcess|jsonrpc.Executor/6::DEBUG::2016-11-20 11:05:34,725::supervdsmServer::92::SuperVdsm.ServerCallback::(wrapper) call network_caps with () {}
MainProcess|jsonrpc.Executor/6::DEBUG::2016-11-20 11:05:34,732::commands::68::root::(execCmd) /usr/bin/taskset --cpu-list 0-3 /usr/sbin/tc qdisc show (cwd None)
MainProcess|jsonrpc.Executor/6::DEBUG::2016-11-20 11:05:34,737::commands::86::root::(execCmd) SUCCESS: <err> = ''; <rc> = 0
MainProcess|jsonrpc.Executor/6::DEBUG::2016-11-20 11:05:34,738::vsctl::57::root::(commit) Executing commands: /usr/bin/ovs-vsctl --oneline --format=json -- list Bridge -- list Port -- list Interface
MainProcess|jsonrpc.Executor/6::DEBUG::2016-11-20 11:05:34,738::commands::68::root::(execCmd) /usr/bin/taskset --cpu-list 0-3 /usr/bin/ovs-vsctl --oneline --format=json -- list Bridge -- list Port -- list Interface (cwd None)
MainProcess|jsonrpc.Executor/6::DEBUG::2016-11-20 11:05:34,745::commands::86::root::(execCmd) SUCCESS: <err> = ''; <rc> = 0
MainProcess|jsonrpc.Executor/6::DEBUG::2016-11-20 11:05:34,747::supervdsmServer::99::SuperVdsm.ServerCallback::(wrapper) return network_caps with {'bridges': {'ovirtmgmt': {'ipv6autoconf': True, 'addr': '192.168.2.125', 'cfg': {'PEERROUTES': 'yes', 'NAME': 'ovirtmgmt', 'DEFROUTE': 'yes', 'IPADDR': '192.168.2.125', 'PEERDNS': 'yes', 'ONBOOT': 'yes', 'NM_CONTROLLED': 'no', 'NETMASK': '255.255.255.0', 'BOOTPROTO': 'static', 'DEVICE': 'ovirtmgmt', 'TYPE': 'Bridge', 'GATEWAY': '192.168.2.1'}, 'ipv6addrs':
['2601:482:4300:5d:5e26:aff:fe01:d547/64'], 'gateway': '192.168.2.1', 'dhcpv4': False, 'netmask': '255.255.255.0', 'dhcpv6': True, 'stp': 'off', 'ipv4addrs': ['192.168.2.125/24'], 'mtu': '1500', 'ipv6gateway': 'fe80::12c3:7bff:fee1:d038', 'ports': ['em1
'], 'opts': {'multicast_last_member_count': '2', 'hash_elasticity': '4', 'multicast_query_response_interval': '1000', 'group_fwd_mask': '0x0', 'multicast_snooping': '1', 'multicast_startup_query_interval': '3125', 'hello_timer': '76', 'multicast_querier_interval': '25500', 'max_age': '2000', 'hash_max': '512', 'stp_state': '0', 'topology_change_detected': '0', 'priority': '32768', 'multicast_membership_interval': '26000', 'root_path_cost': '0', 'root_port': '0', 'multicast_querier': '0', 'multicast_st
artup_query_count': '2', 'nf_call_iptables': '0', 'topology_change': '0', 'hello_time': '200', 'root_id': '8000.5c260a01d547', 'bridge_id': '8000.5c260a01d547', 'topology_change_timer': '0', 'ageing_time': '30000', 'nf_call_ip6tables': '0', 'gc_timer':
'4991', 'nf_call_arptables': '0', 'group_addr': '1:80:c2:0:0:0', 'multicast_last_member_interval': '100', 'default_pvid': '1', 'multicast_query_interval': '12500', 'tcn_timer': '0', 'multicast_router': '1', 'vlan_filtering': '0', 'forward_delay': '1500'
}}}, 'bondings': {}, 'nameservers': ['192.168.2.1'], 'nics': {'em1': {'ipv6gateway': '::', 'ipv6autoconf': True, 'addr': '', 'cfg': {'PEERROUTES': 'yes', 'BRIDGE': 'ovirtmgmt', 'IPV6INIT': 'yes', 'NM_CONTROLLED': 'no', 'NAME': 'em1', 'IPV6_PEERDNS': 'ye
s', 'DEFROUTE': 'yes', 'UUID': 'a6beda1e-adf1-4c82-8c34-6d6d67ad5c16', 'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DEVICE': 'em1', 'BOOTPROTO': 'none', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no', 'TYPE': 'Ethernet', 'O
NBOOT': 'yes', 'IPV6_PEERROUTES': 'yes'}, 'ipv6addrs': [], 'mtu': '1500', 'dhcpv4': False, 'netmask': '', 'dhcpv6': False, 'ipv4addrs': [], 'hwaddr': '5c:26:0a:01:d5:47', 'speed': 1000, 'gateway': ''}}, 'supportsIPv6': True, 'vlans': {}, 'networks': {}}
MainProcess|jsonrpc.Executor/7::DEBUG::2016-11-20 11:05:35,768::supervdsmServer::92::SuperVdsm.ServerCallback::(wrapper) call getHardwareInfo with () {}
MainProcess|jsonrpc.Executor/7::DEBUG::2016-11-20 11:05:35,769::supervdsmServer::99::SuperVdsm.ServerCallback::(wrapper) return getHardwareInfo with {'systemProductName': 'Latitude E6510', 'systemUUID': '4C4C4544-004E-5610-8050-B9C04F314D31', 'systemSer
ialNumber': '9NVP1M1', 'systemVersion': '0001', 'systemManufacturer': 'Dell Inc.'}

You can close this. I ended up using the hosted-engine --deploy

I removed all my changes to em1 and ovirtmgmt (removing the latter) and doing 'engine-cleanup'

It failed because I had no idea how to set up the FQDN for the 2nd host, but it configured  the bridge.

My only thought: is it possible to have the networking stuff that's set up from hosted-engine be a part of 'engine-setup' ?

The docs here are pretty hard to understand (in general honestly) as I'm never sure if I'm looking at v3 or v4 docs, and the v4 docs seem to not take a 'from nowhere to somewhere' approach. I didn't even know hosted-engine was a thing and stumbled onto it.

(In reply to marcus young from comment #3)
> You can close this. I ended up using the hosted-engine --deploy

Closing this as not a bug as per comment #3

> I removed all my changes to em1 and ovirtmgmt (removing the latter) and
> doing 'engine-cleanup'
> 
> It failed because I had no idea how to set up the FQDN for the 2nd host, but
> it configured  the bridge.
> 
> My only thought: is it possible to have the networking stuff that's set up
> from hosted-engine be a part of 'engine-setup' ?
> 
> The docs here are pretty hard to understand (in general honestly) as I'm
> never sure if I'm looking at v3 or v4 docs, and the v4 docs seem to not take
> a 'from nowhere to somewhere' approach. I didn't even know hosted-engine was
> a thing and stumbled onto it.

We're working on the documentation, we know it's not in a good shape.

May I ask which documents you were using?

Originally when I configured ovirt v3 I ran into issues and used this guide: https://jebpages.com/2012/02/15/how-to-get-up-and-running-with-ovirt/

That got me working until recently when I made the swap from 3 to 4.
With 4 I did what I remembered, basically just what was in that guide.

When I finally resolved this by using hosted-engine i used this guide: https://www.ovirt.org/blog/2016/08/up-and-running-with-ovirt-4-0-and-gluster-storage/

I used this one because on the documentation tab of ovirt.org it's the only relevant one with the title 'Up and Running with oVirt 4.0 - by Jason Brooks'

My only issue with the guide is that it's not very descriptive of how to do the hosted-engine --deploy on *only* box i'm setting up. ie Host1.

My VM host is essentially an all-in-one for testing, so it's single node (192.168.2.125). It failed because it wouldn't allow me to install it to itself (192.168.2.125), I needed to run it against a second host, which I didn't have nor want. But it did configure the vdsm network correctly so after the script failed I was able to run 'engine-setup'

I still see a possible bug or area for improvement: either pulling out the part of hosted-engine that configures the network into its own setup script or allowing 'hosted-engine --deploy' to configure the host that it's running from. Does that make sense?