[HOW-TO] Share an OpenStack image between tenants

Today, I had to test an upgrade for software that comes in the form of an image. I wanted to do it in a test tenant, but the image was in the “prod” tenant. Of course, one could simply upload the image to another tenant, but there’s a better way – image sharing between tenants.

The concept is nothing new except that with OpenStack, there are a couple of quirks. It’s not so much sharing the image with another tenant, but adding the tenant to the image as a member.

So without further ado, let’s see how easy it is to accomplish this.

0) Set some environment variables to make our lives easier. “image_ID” is the image we want to share, “project_name” is the project (or tenant) we want to share the image with and “tenant_ID” is, well, the ID of the tenant that we want to have the image in.

export image_ID=1234-567-89012-34567-890123
export project_name=dev_tenant
export tenant_ID=a1b2c3d4e4

1) As mentioned before, we need to add the project ID as a member of the image:

openstack image add project $image_ID $project_name 

2) Sharing is not enough. We also need to accept the share from the target tenant:

OS_TENANT_ID=$tenant_ID glance member-update $image_ID $tenant_ID accepted

3) Last but not least, confirm the image was indeed shared (accepted):

OS_TENANT_ID=$tenant_ID openstack image show $image_ID

So, how about un-sharing? Easy as pie, it’s as simple as removing the project from the image:

openstack image remove project $image_ID $project_name 

[Quick fix] OpenStack Compute (nova) instance could not be found

Sometimes in the life of a cloud admin, we run across issues that seem quite daunting at first, but come out as trivial in the end. This was exactly the case when I had to migrate a few instances some while back.

Nova (openstack compute) reported all the instances in ERROR state. On a closer look with:

nova list --all-t --host $hypervisor

or with the openstack client:

openstack server list --all-projects --host $hypervisor

they were indeed down.

The logs showed a python traceroute ending with:

InstanceNotFound: Instance instance-00000084 could not be found.

The instance files were present on disk, the permissions looked fine, the directory structure was fine, SElinux looked good, qemu reported a healthy disk image when querying it; it’s as if nova was in the twilight zone.

Turns out the fix was trivial. By simply hard rebooting the instance or setting the state to active and then normally rebooting it, nova would magically find the instance on disk and happily power it on. Below, the 2 options:

nova reboot --hard $instance_id


nova reset-state --active $instance_id
nova reboot $instance_id

Such a simple fix for what first appeared to be such a daunting task.