Bug #4430

Error allocating a new image. NAME is already taken

Added by Jan "Yenya" Kasprzak about 5 years ago. Updated almost 4 years ago.

Status:ClosedStart date:04/26/2016
Priority:NormalDue date:
Assignee:Juan Jose Montiel Cano% Done:

0%

Category:Sunstone
Target version:-
Resolution:worksforme Pull request:
Affected Versions:OpenNebula 4.14

Description

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, it is just still being uploaded. 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!


Related issues

Related to Bug #4266: Uploading big image via sunstone got error message New 12/23/2015

Associated revisions

Revision 834ed4e3
Added by Carlos Martín about 5 years ago

Bug #4430: Remove info calls after image upload

Revision c60e021d
Added by Carlos Martín about 5 years ago

Revert "Bug #4430: Remove info calls after image upload"

This reverts commit 834ed4e3fd8ab4981faeb3eadfdd0223d65f4764.

History

#1 Updated by Ruben S. Montero about 5 years ago

  • Category set to Sunstone
  • Target version set to Release 5.0

#2 Updated by Carlos Martín about 5 years ago

I can't reproduce this, and I don't see an obvious place where the call is being retried.
Is this something that happens consistently to you?

As a side note: I have removed those 5 sec interval info calls in master, they are not needed at all

#3 Updated by Carlos Martín about 5 years ago

  • Related to Bug #4266: Uploading big image via sunstone got error message added

#4 Updated by Carlos Martín about 5 years ago

  • Target version changed from Release 5.0 to Release 5.2

#5 Updated by Jan "Yenya" Kasprzak almost 5 years ago

A short update: this issue is still present in 5.0.2 - I have just verified it by uploading a Fedora 24 server ISO image.

#6 Updated by Carlos Martín almost 5 years ago

  • Status changed from Pending to New
  • Target version deleted (Release 5.2)

#7 Updated by Tino Vázquez over 4 years ago

  • Assignee set to Juan Jose Montiel Cano

#8 Updated by Tino Vázquez almost 4 years ago

  • Status changed from New to Closed
  • Resolution set to worksforme

We cannot reproduce the problem. Please if it also happens in 5.4.

Also available in: Atom PDF