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. (you will also see Shared, but that is not a usable option for end-users...)
    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 custom 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. tl;dr - use the raw format
    • qemu-img is a nice tool to convert virtual disks. It is available on both Linux and Windows.
  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.

...

Code Block
$ openstack image create --file <disk-file> --disk-format raw --container-format bare [--private|--community] --protected --progress "<Whatever you want to name the image>"


The GUI way

...

After logging in to the web interface, navigate to: Project → Compute → Images and click Create Image.

You will be presented with this form (the example has some example data filled in):

Image Added

  • Give the image a describing name, and alternatively a description.
  • Select your disk file, and give the corresponding format from the dropdown.
  • You can leave anything under Image Requirements untouched, unless you know there is a minimum recommended amount of Disk or RAM for the image you are uploading - then give some reasonable values here.
  • Under Image Sharing you select if you want the image to be Private, Shared of Community. These are explained above. Protected should always be set to Yes.
  • Do not bother with anything in the Metadata tab, unless you know you need something there.
  • Click Create Image and wait until the upload is completed =)