NIC reattach on sunstone breaks /etc/network/interfaces

Community Support
1

Hi there!

I’m running Ubuntu 14.04 from the marketplace and I have the network fully setup with one physical connection on the host called br0. On vm creation the network is fully functional and a quick ifconfig on the vm returns both lo and eth0. I can ping both the vm and ping out from it. However if I detach the NIC from the vm and then simply attach it again and reboot the vm, the vm’s eth0 iface is gone and won’t start [see attachment]. Turns out it’s because the vm’s /etc/network/interfaces file not only has the old ip specified in eth0 [which differs from the new one in the vm’s network panel in sunstone], but is also broken as the word eth0 doesn’t show up in the iface definition lines [see attachment]. Manually fixing the file works but only until vm reboot. I’ve tried all combinations of nic detach/reattach, vm reboot, and host reboot, with no success. This happens on new vms as well. I have an ubuntu 14.04 host and I’m on one 4.14.2.

Thanks in advance for your help!

2

Can you send us this information?

  • output of ip a in that VM
  • context.sh file. It should be in /var/lib/one/<vmid>/context.sh
  • output of onevm show -x <vmid>
3

Hi!

Thanks so much for your reply.

Absolutely: here is an ip a on a vm immediately after reboot so before manual correction of /etc/network/interfaces:

Screen Shot 2015-12-18 at 18.55.54.png806×224 17.7 KB

And here it is after:

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:00:c0:a8:01:6f brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.111/22 brd 192.168.3.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c0ff:fea8:16f/64 scope link 
       valid_lft forever preferred_lft forever```

Here is `context.sh` [brakets around pound sign added by me for correct formatting] :
```root@ubns01:~# cat /var/lib/one/vms/32/context.sh 
[#] Context variables generated by OpenNebula
DISK_ID='1'
ETH0_DNS='192.168.0.1 8.8.8.8'
ETH0_GATEWAY='192.168.0.1'
ETH0_IP='192.168.0.50'
ETH0_MAC='02:00:c0:a8:00:32'
ETH0_MASK='255.255.252.0'
ETH0_NETWORK='192.168.0.0'
NETWORK='YES'
SSH_PUBLIC_KEY=[...]```

And here is `onevm show -x 32` immediately after vm reboot [so no manual correction of interfaces file] : http://pastebin.com/QrkY2xAT

Thanks again for your help!


Nicolas
4

The problem is that OpenNebula does not regenerate the context script.

To find the correct interface we try to find one with the same mac address. In this case there is no interface with that specific mac address a malformed interface configuration is added. I’ve opened a ticket for the context packages to skip these cases:

While OpenNebula does not regenerate the context information I don’t recommend you to detach interfaces defined on VM instantiation.

5

Ok I see thank you very much for opening an issue!

I’ll try to avoid that but as for now we have three production vms that we had to migrate from 192.168.0.xxx to 192.168.1.xxx. Is there any way I can manually fix this for these vms?

Thanks again!

6

I think the best way to fix this is disabling contextualization in that machine and manually configuring interfaces. You can do this deleting the link SXXvmcontext from /etc/rc2.d or /etc/rc3.d, depending on your distribution.

7

Hi! I’m very sorry I didn’t reply back at that time. I deleted both files and it works now: the vm keeps the network config across reboots without it being overwritten by the context.

I saw by chance that coincidentally you just added this issue’s solution to the v5.0.0 milestones.

Thank you very much again for your help!

Nicolas