Onevm updateconf does not set network settings correctly

Community Support
1

Hi,

I just migrated from 4.14 to 5.0.2. Generally, the new onevm updateconf feature is very helpful, but in my case it does not seem to work as it should. If I leave “Add Network contextualization” checked, all network settings except MAC and IP (i.e. gateway, subnet-mask, DNS servers, etc.) are removed from the context file (more precise: their value is an empty string). I can only fix this by unchecking “Add Network contextualization” and filling in the values by hand, which I guess is not the way it’s meant to be.

Interestingly, the problem only seems to occur on old VMs that were created long ago (the VM I first encountered this problem with was created March 2014). I tested it with a VM that was created some weeks ago (with One 4.14), there updateconf works as it should. Also, newly created VMs are instantiated with correct network settings, so I think it’s not a problem with the vnet config.

Is there anything that an older OpenNebula version (4.x) did differently that could break the updateconf feature?

Greetings
Wilma

2

Hi

When the "“Add Network contextualization” is checked the values are generated (re-generated) from the Virtual Network Template. So for example, you can update the DNS server for a network just by go through a powe-on/power-off cycle.

So I’m not sure if those long lived VMs are connected to a VNET without the Context values?

3

Hi,

Maybe we can shed some light on the issue with some code. The context that was generated by 4.x (no idea which OpenNebula version instantiated the VM originally) looks like this:

CONTEXT = [ DISK_ID = "1", ETH0_DNS = "X.Y.32.40", ETH0_GATEWAY = "X.Y.198.1", ETH0_IP = "X.Y.198.59", ETH0_MAC = "02:00:ab:cd:ef:12", ETH0_MASK = "255.255.255.128", ETH0_NETWORK = "X.Y.198.0", NETWORK = "YES", SSH_PUBLIC_KEY = "ssh-rsa AAA...JZF user@machine", TARGET = "hdb" ]

The machine kept running through the upgrade of OpenNebula. If I shut this VM down and click on “Update Configuration”, immediately followed by a click on “Update”, the context looks like this:

CONTEXT = [ CONTEXT = "true", DISK_ID = "1", ETH0_CONTEXT_FORCE_IPV4 = "", ETH0_DNS = "", ETH0_GATEWAY = "", ETH0_GATEWAY6 = "", ETH0_IP = "X.Y.198.59", ETH0_IP6 = "", ETH0_IP6_ULA = "", ETH0_MAC = "02:00:ab:cd:ef:12", ETH0_MASK = "", ETH0_MTU = "", ETH0_NETWORK = "", ETH0_SEARCH_DOMAIN = "", ETH0_VLAN_ID = "1", ETH0_VROUTER_IP = "", ETH0_VROUTER_IP6 = "", ETH0_VROUTER_MANAGEMENT = "", IMAGE = "Context", NETWORK = "YES", SSH_PUBLIC_KEY = "ssh-rsa AAA...JZF user@machine", TARGET = "hdb" ]

And here is the VNET template:
VIRTUAL NETWORK TEMPLATE BRIDGE="ovs1" DESCRIPTION="..." DNS="X.Y.32.40" FILTER_MAC_SPOOFING="YES" GATEWAY="X.Y.198.1" NETWORK_ADDRESS="X.Y.198.0" NETWORK_MASK="255.255.255.128" PHYDEV="" SECURITY_GROUPS="0" VLAN_ID="1" VN_MAD="ovswitch"

Greetings
Wilma

4

Could you also paste the NIC attribute of the VM?

Thanks

5

Sure, at least what is generated after using updateconf:

NIC = [ BRIDGE = "ovs1", IP = "X.Y.198.59", IP6_LINK = "fe80::abcd", MAC = "02:00:ab:cd:ef:12", NETWORK = "public", NETWORK_ID = "0", NETWORK_UNAME = "oneadmin", NIC_ID = "0", VLAN = "YES", VLAN_ID = "1", VN_MAD = "ovswitch" ]

6

Hi,

This is probably a bug in the migrator from quite a few releases ago, when we introduced the AR’s. The code does not resolve Network values when the NIC does not have AR_ID. That can only happen for “very” old VMs probaly pre-4.6. (Note that a NIC needs always to have a NETWORK_ID and AR_ID, variable resolution is exiting in a sanity check)

I’m afraid that this will mess up context for these VMs (note that context regeneration now happens whenever a VM is booted).

The only solution is to patch the DB to include such values, maybe you can try with onedb fsck or do it manually.

Cheers

7

Hi,

I tried onedb fsck, the only thing it complains are those “IP6_LINK does not match” messages already mentioned in other threads (e.g. here). So this does not help.

Thanks for the hint with AR_ID, it was exactly the missing puzzle piece. I was able to detect all affected VMs with this SQL-command (on MySQL):
SELECT oid FROM vm_pool WHERE state <> 6 AND body LIKE '%<NIC>%' AND body NOT LIKE '%<AR_ID>%';

In my case, 30 VMs were affected. Manually adding the correct AR_ID was laborious, but bearable. I’m sure that this can be automated since all required data can be found in the database.

Greetings
Wilma