I noticed the issue in code. I didn't need to test for it, so there are no logs. You can reproduce the issue by assigning multiple fixed IPs, and also using ipv6. Currently multiple fixed_ips has to be done by direct manipulation of the fixed_ips table. Once you have created multiple fixed IPs, use the console to make a call to xenapi/vmops._get_network_info(). You'll see that the "ip6s" field in the returned dict will contain the ip6 address repeated multiple times. You can also perform the test by enabling ipv6, and assigning no fixed_ips (again requires direct manipulation of the table, though i guess this could be done through a console as well). When no fixed_ips exist for an instance, there will be no "ip6s" in the dict returned by _get_network_info() even if you had expected there to be.
I also just realized that inject_network_info() and reset_netowrk() can't be called from the os_api (or compute) because the parameters changed in xs_multi_nic. I fixed these issues.
I noticed the issue in code. I didn't need to test for it, so there are no logs. You can reproduce the issue by assigning multiple fixed IPs, and also using ipv6. Currently multiple fixed_ips has to be done by direct manipulation of the fixed_ips table. Once you have created multiple fixed IPs, use the console to make a call to xenapi/ vmops._ get_network_ info(). You'll see that the "ip6s" field in the returned dict will contain the ip6 address repeated multiple times. You can also perform the test by enabling ipv6, and assigning no fixed_ips (again requires direct manipulation of the table, though i guess this could be done through a console as well). When no fixed_ips exist for an instance, there will be no "ip6s" in the dict returned by _get_network_info() even if you had expected there to be.
I also just realized that inject_ network_ info() and reset_netowrk() can't be called from the os_api (or compute) because the parameters changed in xs_multi_nic. I fixed these issues.