When create image from instance which is not volume backed, it depends on hypervisor's driver to correct the disk_format (and container_format) at uploading data to image. so there is no problem;
But for volume backed instance, creating image will take a volume snapshot in volume back-end. In this case, the image is simply a bucket of properties without any image data. https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2545
There is no image data to be uploaded, so there is no chance for hypervisor to correct disk_format. If the hypervisor driver(e.g. XenAPI) doesn't support the default hardcoded disk_format - qcow2, it will cause failures at image creating and booting instance from that image.
On the other side, as the real data is in the volume snapshot. There is no need to process data basing on the image's format. So I think a reasonable solution is to use a common disk_format supported by all hypervisors - e.g. 'raw'.
When create image from instance which is not volume backed, it depends on hypervisor's driver to correct the disk_format (and container_format) at uploading data to image. so there is no problem; /github. com/openstack/ nova/blob/ master/ nova/compute/ api.py# L2545
But for volume backed instance, creating image will take a volume snapshot in volume back-end. In this case, the image is simply a bucket of properties without any image data.
https:/
There is no image data to be uploaded, so there is no chance for hypervisor to correct disk_format. If the hypervisor driver(e.g. XenAPI) doesn't support the default hardcoded disk_format - qcow2, it will cause failures at image creating and booting instance from that image.
On the other side, as the real data is in the volume snapshot. There is no need to process data basing on the image's format. So I think a reasonable solution is to use a common disk_format supported by all hypervisors - e.g. 'raw'.