Virtual network hangs in status LOCK_CREATE after VN creation

Dear all,

I would appreciate any help on the following issue.
As soon as I create virtual network (VN) in configuration as below the status of VN is LOCK_CREATE with 0 leases:

NAME            ="priv"
DESCRIPTION     = "A private network for VMs"
VN_MAD          ="dummy"
BRIDGE          ="br0"

AR=[TYPE="IP4", IP="10.55.9.1", SIZE="254"]
AR=[TYPE="IP4", IP="10.55.10.1", SIZE="254"]
AR=[TYPE="IP4", IP="10.55.11.1", SIZE="254"]

NETWORK_ADDRESS = "10.55.8.0"
NETWORK_MASK    = "255.255.252.0"
DNS             = "8.8.8.8"
GATEWAY         = "10.55.8.1"

There are no errors in the oned.log.

If I do ‘onevnet recover <VN_ID> --success’, status is changed to READY, but if I do 'onevnet delete <VN_ID> the status hangs in LOCK_DELETE. It seems like the problem with driver operations.

OpenNebula version is 6.4.0 CE on AlmaLinux 8.7 x64 (FN and CNs).

I was not able to find any related issue in the Known Issues.

Can you post the output of onevnet show -j <vnet_id> ?

Hi @knawnd,
I’ve double check that the feature is working in CE version for dummy driver.

Please, can you check the output in /var/log/one/oned.log at the time the VN is created?

Here it is:

[oneadmin@cloud ~]$ onevnet show -j 3
{
  "VNET": {
    "ID": "3",
    "UID": "0",
    "GID": "0",
    "UNAME": "oneadmin",
    "GNAME": "oneadmin",
    "NAME": "Private Network",
    "PERMISSIONS": {
      "OWNER_U": "1",
      "OWNER_M": "1",
      "OWNER_A": "0",
      "GROUP_U": "0",
      "GROUP_M": "0",
      "GROUP_A": "0",
      "OTHER_U": "0",
      "OTHER_M": "0",
      "OTHER_A": "0"
    },
    "CLUSTERS": {
      "ID": "0"
    },
    "BRIDGE": "br0",
    "BRIDGE_TYPE": "linux",
    "STATE": "2",
    "PREV_STATE": "0",
    "PARENT_NETWORK_ID": {
    },
    "VN_MAD": "dummy",
    "PHYDEV": {
    },
    "VLAN_ID": {
    },
    "OUTER_VLAN_ID": {
    },
    "VLAN_ID_AUTOMATIC": "0",
    "OUTER_VLAN_ID_AUTOMATIC": "0",
    "USED_LEASES": "0",
    "VROUTERS": {
    },
    "TEMPLATE": {
      "AR": [
        {
          "IP": "10.55.9.1",
          "SIZE": "100",
          "TYPE": "IP4"
        },
        {
          "IP": "10.55.10.1",
          "SIZE": "10",
          "TYPE": "IP4"
        }
      ],
      "BRIDGE": "br0",
      "BRIDGE_TYPE": "linux",
      "DESCRIPTION": "A private network for VM inter-communication",
      "DNS": "8.8.8.8",
      "GATEWAY": "10.55.8.1",
      "NETWORK_ADDRESS": "10.55.8.0",
      "NETWORK_MASK": "255.255.252.0",
      "PHYDEV": "",
      "SECURITY_GROUPS": "0",
      "VN_MAD": "dummy"
    },
    "AR_POOL": {
    }
  }
}

I see no errors in oned.log file related with a vnet creation.

It seems around VNET creation there is the following error message:

[Z0][IPM][E]: Unable to find IPAM Manager driver

In the oned.conf the corresponding to IPAM driver section is commented:

#IPAM_MAD = [
#    EXECUTABLE = "one_ipam",
#    ARGUMENTS  = "-t 1 -i dummy,aws,equinix,vultr"
#]

IPAM driver related files are in place:

[root@cloud ~]# ll /var/lib/one/remotes/ipam/
total 0
drwxr-x---. 2 oneadmin oneadmin 131 Nov 21 13:26 aws
drwxr-x---. 2 oneadmin oneadmin 131 Nov 21 13:26 dummy
drwxr-x---. 2 oneadmin oneadmin 131 Nov 21 13:26 equinix
drwxr-x---. 2 oneadmin oneadmin 131 Nov 21 13:26 vultr

[root@cloud ~]# ll /var/lib/one/remotes/ipam/dummy/
total 28
-rwxr-x---. 1 oneadmin oneadmin 3886 May 10  2022 allocate_address
-rwxr-x---. 1 oneadmin oneadmin 3788 May 10  2022 free_address
-rwxr-x---. 1 oneadmin oneadmin 4269 May 10  2022 get_address
-rwxr-x---. 1 oneadmin oneadmin 4686 May 10  2022 register_address_range
-rwxr-x---. 1 oneadmin oneadmin 2303 May 10  2022 unregister_address_range

The reason of the problem was in that part (quoted above). It needs to be uncommented.

1 Like