Image Upload from FireEdge Randomly Fails

Product Support Operations
1

Running OpenNebula CE 7.0.1 on Debian 12.

When uploading an image via FireEdge UI, FireEdge writes a temp file into /var/tmp/.

oned tries to copy it with datastore/fs/cp, but very often fails because the temp file no longer exists.

cp: Copying local image /var/tmp/ed7e44222f3dd29e901f9120da8bfbee …

cat: /var/tmp/ed7e44222f3dd29e901f9120da8bfbee: No such file or directory
Error copying image in datastore

This happens randomly — sometimes oned copies the file fast enough, sometimes not.
Looks like FireEdge deletes the temp file before oned finishes processing (race condition?).

/var/tmp has enough space and permissions:

2

Hello,

Some questions:

  • is the image bigger than 10gb? Check in the file /etc/one/fireedge/sunstone/sunstone-server.conf, the option max_upload_file_size
  • Do you have HA on the frontend? May there have been a change of leader while uploading the image?
  • Can you check if /var/tmp is a regular partition or is it mounted on memory as a tmpfs ?

Cheers

3

Hello.

My setup (very simple)

  • 1× frontend (also KVM node)

  • Previously tested also with 2 hosts → same error

  • Local datastore (fs / local), no shared storage

  • Image size ~500 MB (so well below max_upload_file_size)

  • No HA, so no leader change

  • /var/tmp is not tmpfs, it’s a normal directory on disk

  • Enough free space (100+ GB)

4

Do you have any update on this issue or further suggestions on how to debug or work around it?

Since we are currently running a POC and testing basic functionality like VM creation, random failures during image upload are a blocker for us and make it hard to evaluate the product reliably.

5

Hello,

Just a question, is Apparmor or Selinux running?
Can there be a systemd timer or a cron cleaning the directory?

Thanks!

6

Hi Bruno,

quick update from our side:
– SELinux is not installed
– AppArmor is enabled with default profiles, no DENIED events observed
– no custom cron jobs or OS-level cleanup tasks found; only systemd-tmpfiles-clean and the OpenNebula internal ssh-socks-cleaner timer are present

Is there a documented or recommended OS baseline for OpenNebula (Debian/Ubuntu defaults)?

We’d like to ensure our OS setup matches your supported assumptions rather than chasing random symptoms.

7

Hello,

OpenNebula recommends Ubuntu 24.04 LTS. If you have some experience with Ansible I would recommend you to use one-deploy for the installation:

Cheers!

8

Hello,
we are running the POC in our own company on dedicated physical machines where Debian 12 is installed. This setup is documented as supported, and it was also suggested during our direct communication with the OpenNebula sales team.

We also have no issue switching to Ubuntu, but in that case you need to clarify whether this would actually resolve the issues or not.

On this link, Debian is listed as a supported operating system.
Platform Notes |

However, in one of the images there, Debian is not mentioned — only CentOS, RHEL, and Ubuntu are shown.

Is Debian actually supported or not?

9

Bruno, are you still there? We are actually working on a POC and are running into such trivial problems. I finally managed to mount the system and images datastore, and now I’m trying to finally start the upload, and again, the same error.

Is the problem related to the OS or what? We need to know this if we are to purchase your product. Honestly, this whole situation seems a bit unprofessional now.

10

Hello,

Sorry for the late reply. Developers reported that issue is related with this bug, in which they are working in

As a workaround, the image can be added uploading via SCP the image to any of the SAFE_DIRS of the datastore and using the CLI or the web interface introducing the path.