I was able to reproduce this issue locally.
After some debugging here is what I found:
* vm used in test has got mac address fa:16:3e:e2:4e:06
* vm was migrated from allinone node to the compute node
* on allinone node there is also dhcp server for network used by this vm,
* after migration on allinone node, in br-int there was left OF rule:
and this rule caused problems as packets which has got dest mac fa:16:3e:e2:4e:06 were not pushed to br-tun and to the other node.
After removing this rule manually vm has got dhcp connectivity again.
Now I need to find out where such rule should be created and when it should be removed.
I was able to reproduce this issue locally.
After some debugging here is what I found:
* vm used in test has got mac address fa:16:3e:e2:4e:06
* vm was migrated from allinone node to the compute node
* on allinone node there is also dhcp server for network used by this vm,
* after migration on allinone node, in br-int there was left OF rule:
cookie= 0x90daec9e07fd1 af6, duration=1858.683s, table=73, n_packets=240, n_bytes=27852, priority= 100,reg6= 0x26,dl_ dst=fa: 16:3e:e2: 4e:06 actions= load:0x96- >NXM_NX_ REG5[], resubmit( ,81)
and this rule caused problems as packets which has got dest mac fa:16:3e:e2:4e:06 were not pushed to br-tun and to the other node.
After removing this rule manually vm has got dhcp connectivity again.
Now I need to find out where such rule should be created and when it should be removed.