Error allocating a new image. NAME is already taken

Community Support
1

When I upload a new CDROM image through Sunstone to the CEPH datastore, I get the following error after some time:

[ImageAllocate] Error allocating a new image. NAME is already taken by IMAGE 74.

The image 74 is that newly created image, it is in LOCKED state, and it eventually switches to the READY state. The oned.log says the following about the image 74:

Tue Apr 26 09:17:51 2016 [Z0][ReM][D]: Req:2384 UID:0 ImageAllocate invoked , "NAME="Win 2008r2 Ser...", 100
Tue Apr 26 09:17:52 2016 [Z0][ImM][I]: Copying /var/tmp/3166720000-WindowsServerStdEntDCWeb2008R2withSP164-bit-ENiso to repository for image 74
Tue Apr 26 09:17:52 2016 [Z0][ReM][D]: Req:2384 UID:0 ImageAllocate result SUCCESS, 74
Tue Apr 26 09:17:52 2016 [Z0][ReM][D]: Req:8400 UID:0 ImageInfo invoked , 74
Tue Apr 26 09:17:52 2016 [Z0][ReM][D]: Req:8400 UID:0 ImageInfo result SUCCESS, "<IMAGE><ID>74</ID><U..."
Tue Apr 26 09:17:57 2016 [Z0][ReM][D]: Req:9232 UID:0 ImageInfo invoked , 74
Tue Apr 26 09:17:57 2016 [Z0][ReM][D]: Req:9232 UID:0 ImageInfo result SUCCESS, "<IMAGE><ID>74</ID><U..."
[the ImageInfo lines repeat every five seconds, I am omitting them]
Tue Apr 26 09:18:51 2016 [Z0][ReM][D]: Req:8768 UID:0 ImageAllocate invoked , "NAME="Win 2008r2 Ser...", 100
Tue Apr 26 09:18:51 2016 [Z0][ReM][E]: Req:8768 UID:0 ImageAllocate result FAILURE [ImageAllocate] Error allocating a new image. NAME is already taken by IMAGE 74.
[...]
Tue Apr 26 09:21:23 2016 [Z0][ReM][D]: Req:272 UID:0 ImageInfo invoked , 74
Tue Apr 26 09:21:23 2016 [Z0][ReM][D]: Req:272 UID:0 ImageInfo result SUCCESS, "<IMAGE><ID>74</ID><U..."
Tue Apr 26 09:21:26 2016 [Z0][ImM][I]: Image (74) copied and ready to use.

It seems that image creation (upload from /var/tmp/ to CEPH) takes longer than one minute, and oned decides to restart the action after one minute. This of course fails, because the image has already been created. The image in question has about 3 GB.

What is the best solution for this problem? Increasing the timeout somewhere? Making oned know that the upload is still in progress (as opposed to be dead), and that the operation does not need to be restarted yet?

Thanks!

2

Hi,

Please open a bug ticket at http://dev.opennebula.org and we’ll try to reproduce and fix it.

3

Done: http://dev.opennebula.org/issues/4430

4

Hi there,

(After reading the whole bug ticket I decided to join the conversation.)

We have Open Nebula 5.4.1 on Ubuntu 16.04 and I just experienced the same issue: the image seams to get uploaded no problem, but in the end it goes into the “LOCKED” state.

One difference is that the images (I tried more than one) I’m uploading are much bigger: 30GB. They are those pre-built Ubuntu/CentOS images for Azure (I am testing the OpenNebula API for Azure…)

root@abcde:/var/log/one# oneimage show 47
IMAGE 47 INFORMATION
ID : 47
NAME : Ubuntu16.04Server - Azure
USER : oneadmin
GROUP : oneadmin
DATASTORE : default
TYPE : OS
REGISTER TIME : 02/15 14:46:48
PERSISTENT : Yes
SOURCE :
PATH : /var/tmp/32212255232-xenial-server-cloudimg-amd64-disk1vhd
FSTYPE : raw
SIZE : 30G
STATE : lock
RUNNING_VMS : 0

PERMISSIONS
OWNER : um-
GROUP : —
OTHER : —

IMAGE TEMPLATE
DEV_PREFIX="vd"
DRIVER=“raw”

VIRTUAL MACHINES

It’s been more than 01 hour since it got registered and has not switched to the READY status. Re-starting the OpenNebula service didn’t help either.

Regards,

Alex