zuloostereo.blogg.se

#VIMR ERROR FULL#

Will not be shown, you would have to be root to see it all.) (Not all processes could be identified, non-owned process info It is not running in this lxc exec juju-f050fc-0 - netstat -apen | grep 17070 # Check if the service for the agent account is running. # In this case, juju_controller_instance_id = lxc list | grep "$" # First, check the name for the LXC with the Juju controller # Check if Juju is running on the Juju controller The command may get stalled if the service is not running in the Juju juju status Is it red/unavailable? Check if the service is running on port 17070, inside the Juju controller container that runs inside the VCA container otherwise restore it. Check the connection to the OSM Juju config agent account. To solve that, the containers and data created through Juju should be removed.

#VIMR ERROR FULL#

"cannot load cookies: file locked for too long" where charms are not loadedĭepending on the remainder of the error message, this most likely means that a condition on the server hosting OSM is not allowing the charm to be loaded.įor instance, the following error indicates that the VCA container is full and cannot host new containers for Juju: "Cannot load charms due to "ERROR cannot load cookies: file locked for too long giving up: cannot acquire lock: open /root/.local/share/juju/cookies/: no space left on device". Then, if you see an error, you should debug the VNF charm or ask the people providing that VNF package. To confirm, connect to VCA container and check "juju status". If the IP address is present in the management interface, then you are probably hitting a SO-VCA timeout, caused because the VNF configuration via Juju charms takes too long.

Then make sure that, at instantiation time, you specify a mapping between the management network in th NS and the VIM network name that you pre-provisioned at the VIM.

You can see, for instance, the instructions in the case of Openstack ( (Release_TWO) ).

Pre-provision a management network in the VIM, with DHCP enabled.

In all the cases, the recommendation is the following: The way how management IP addresses are assigned to the VNFs change from one VIM to another. The reason is typically a wrong configuration of the VIM.

If no IP address is present in the management interface of each VNF, then you are hitting a SO-RO timeout issue. Lxc exec RO -env OPENMANO_TENANT=osm openmano instance-scenario-list -vvv |grep ip # to get verbose information on a specific scenario in the RO Lxc exec RO -env OPENMANO_TENANT=osm openmano instance-scenario-list # to identify the running scenarios in the RO First check in the RO that there is an IP address in the management interface of each VNF of the NS. However, I am seeing that the VMs and networks were created at the VIM.Ī. After checking the logs, it seems to be a timeout issue. After trying to instantiate, I got the message that the instantiation failed without much information about the reason. "Instantiation failed", but VMs and networks were successfully created

8 Deployment fails with the message Error creating image at VIM 'xxxx': Cannot create image without location.

7 OSM RO service fails to start with a message "DATABASE wrong version".

6 Deployment fails with the error message "VIM Exception vimconnUnexpectedResponse Unauthorized: The request you have made requieres authentication.

5 Deployment fails with the error message "Not possible to get_networks_list from VIM: AuthorizationFailure: Authorization Failed: The resource could not be found.

4 SO connection error: not possible to contact OPENMANO-SERVER (openmanod).

3 "Instantiation failed" and VMs and network were not created at VIM.

2 "cannot load cookies: file locked for too long" where charms are not loaded.

1 "Instantiation failed", but VMs and networks were successfully created.