Hide Forgot
Description of problem: Building virtual interfaces for test cases based on dummy networks get lost in the engine after host reboot. Version-Release number of selected component (if applicable): Ovirt-engine 3.4.2 vdsm 4.14.9 How reproducible: 100% Steps to Reproduce: 1. activate dummy kernel module on hypervisor node 2. create hook /usr/libexec/vdsm/hooks/before_vdsm_start/network.sh on Hypervisor node. This ensures the interface is activated, always comes up with the same mac address and is active. #!/bin/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 3. Activate node in ovirt webadmin 4. Assing Network to dummy0 interface on node. Save config 5. Switch node to maintenance mode 6. reboot node 7. Activate node Actual results: Assignment Network/dummy is lost Expected results: assignment should still be active Additional info: engine-log attached
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.