Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. As an unprivileged user there is two different access schemes for a new image: Private and Community.
    A private image is, as the name indicates, private to your project only. A community image will be visible and usuable for all cloud users, but they are not visible in the web interface or through the CLI unless you explicitly ask to list the community images. A community image is ideal for a scenario where a course responsible need a custome image to be available for all their students in their own projects.
  2. We only accept two disk formats: raw and qcow2, where we strongly encourage you to use the raw format. The raw format supports "copy-on-write" in our storage backend, which basically means that your VMs root disk will be a snapshot of the original image, which only contains the changes. This makes instance creation "instant", and saves a lot of storage space. This is not possible with qcow2, and with this format, a full copy of the image has to be made for each VM using it. This wastes space, and makes instance creation slow.
  3. A key difference between our publicliy available images and a image that you choose to upload is (or might be, depending on the image) that your image is not necessarily "cloud-ready". In this context "cloud-ready" means:,
    • cloud-init is installed
    • ssh-server / RDP-server is enabled, running, and configured correctly
  4. Your disk file should not exceed 40GB (it can be smaller, no problem), because that is the default root volume size in all our flavors.
  5. It is possible that your image has a device name hardcoded in /etc/fstab that is not compatible with our platform. If the device name must be hardcoded, it should be /dev/vda. Please try to use UUID instead (modern distros typically does this)

If your image is not "cloud-ready", that basically means that all of the usual "magic" won't work. Cloud-init is the service responsible for injecting SSH-keys, resizing disks, setting hostname, processing user-scripts etc. In many scenarios that's OK, i.e if your images has default credentials that you can use. Of course, you still have to ensure some way of doing network communication/interaction with the VMs.

...