Bug 1120823

Created attachment 918799 [details]
engine-log

Extra info. Although the network assignment gets lost in the engine, it is still visible in the node configuration files:

root@node# cd /etc/sysconfig/network-scripts

root@node# cat ifcfg-VTrust
# Generated by VDSM version 4.14.9-0.fc20
DEVICE=VTrust
ONBOOT=yes
TYPE=Bridge
DELAY=0
DEFROUTE=no
NM_CONTROLLED=no
STP=no
HOTPLUG=no

root@node# cat ifcfg-dummy0
# Generated by VDSM version 4.14.9-0.fc20
DEVICE=dummy0
ONBOOT=yes
HWADDR=62:dc:0e:86:dd:47
BRIDGE=VTrust
NM_CONTROLLED=no
STP=no

Any chance to get vdsm and supervdsm logs?

Testcase coul dbe narrowed down to vdsmd restart. To reproduce the error I executed the following steps.

1. Install vdsm hook /usr/libexec/vdsm/hooks/before_vdsm_start/network.sh

ip link add dummy0 type dummy 2>/dev/null
/usr/sbin/ifconfig dummy0 hw ether 62:dc:0e:86:dd:47
/usr/sbin/ifconfig dummy0 up

2. Activate node

3. assign network VTrust (self choosen name) to dummy0

4. Put node to maintenance mode

5. Stop vdsmd 

systemctl stop vdsmd

6. reinstall kernel dummy module

rmmod dummy
modprobe dummy

-> dummy0 interface has some random MAC address

ifconfig dummy0
dummy0: flags=130<BROADCAST,NOARP>  mtu 1500
        ether 0e:87:24:5b:bc:49  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


7. start vdsmd

systemctl start vdsmd

-> dummy0 interface has well defined MAC address and is up

ifconfig dummy0
dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        inet6 fe80::60dc:eff:fe86:dd47  prefixlen 64  scopeid 0x20<link>
        ether 62:dc:0e:86:dd:47  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3  bytes 210 (210.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


8. activate host

assignment dummy0 -> VTrust is lost


I have attached the required logs.

Created attachment 919387 [details]
vdsm start log

Created attachment 919388 [details]
supervdsm log

vdsm log contains only the startup routine (step 7 and on).

supervdsm is complete log.

Could the problem be that nothing re-creates the dummy devices post boot?

You should do 
  ip link add dummy0 type dummy
before vdsm starts (possibly in the before_vdsm_start hook).

If not, could you report the output of `vdsClient -s 0 getVdsCaps`?

Shouldn't this question be answered by Comment 4?

Nevertheless I attached the requested output to this bug. While the getVdsCaps command was executed the engined had no network assignment. Screenshot attached too.

Created attachment 920192 [details]
vdscaps

Created attachment 920193 [details]
dummy interface webadmin

Yes, you were very specific in comment 4; minor dyslexia on my part part, sorry.

I do notice empty ports list on the bridge

                   'VTrust': {'addr': '',
                              'cfg': {'DEFROUTE': 'no',
                                      'DELAY': '0',
                                      'DEVICE': 'VTrust',
                                      'HOTPLUG': 'no',
                                      'NM_CONTROLLED': 'no',
                                      'ONBOOT': 'yes',
                                      'STP': 'no',
                                      'TYPE': 'Bridge'},
                              'gateway': '',
                              'ipv6addrs': ['fe80::60dc:eff:fe86:dd47/64'],
                              'ipv6gateway': '::',
                              'mtu': '1500',
                              'netmask': '',
                              'ports': [],
                              'stp': 'off'},

apparently because you do not run `ifup dummy0` in your hook. You can also add it to the bridge manually with `brctl addif VTrust dummy0`.

Does this solve the issue for you?

Thanks for that hint.

Replacing "iconfig dummy0 up" with "ifup dummy0" lets the network associations appear after node restart. Difference is that the second one starts the bridge.

So we come to the conclusion of it all.

What will change if we jump into the new 3.5 network configuration logic? Will  VDSM handle those associations itself or should I file a RFE?

I must admit that I do not understand what you would like vdsm to do in 3.5; dummies are not supported by Vdsm, they are just tolerated, and this is not going to change in 3.5.

online again.

Thanks for yout help and that clarification. I asked myself if a tighter integration would be useful. If "tolerated" dummy interfaces will still work in 3.5 I'm fine with that.

So closing this bug.