On 17/06/2025 20:02, Vicentini Fracarolli, Joao wrote:
Hello OpenStack Community, I'm part of the StarlingX Community and our starlingx-openstack distribution is currently delivering the 2024.1 (Caracal) release. We were exploring the openstack-client "server rebuild" feature [1], and we might have found a bug. So, I'm writing this email to explain our current issue and get feedback on this new Launchpad we are creating for the Nova component https://bugs.launchpad.net/nova/+bug/2114855 [2]. It happened in the following scenario:
* Create a VM with some small disk flavor and a small image. For example, using a flavor of 1 GB with the Cirros image (~ 21 MB of disk size). * Try to rebuild the VM using a new image. Example: the ubuntu-jammy qcow image.
When the steps above are executed with an image with a disk size greater than the flavor size, the Nova API returns an error and the VM is not rebuilt: /Flavor's disk is too small for requested image. Flavor disk is 1073741824 bytes, image is 1283063808 bytes. (HTTP 400) (Request-ID: req-7db974bb-15f3-425f-b97b-98b789b7e10f) / But when we use an image with a disk size smaller than the flavor disk size, but with a virtual size bigger than the flavor disk size, Nova will try to rebuild the VM and fail: the VM state will be ERROR. It looks like the Nova API is accepting such rebuild requests, but when Nova Compute checks for virtual size, it fails. Is that expected behavior?
yes this is expected behavior becasue nova cannot turst glance and has to check on the compute for security reasons. image are user uploadable and atribute like min_disk cant be relied on. by the way please be careful with raising issues like this publicly to the list. This could have been a security vulnerability if nova did not reject the image on the compute node before trying to use it to boot the vm. Due to https://security.openstack.org/ossa/OSSA-2024-001.html and https://security.openstack.org/ossa/OSSA-2024-002.html we hardened much of our image validation in multipel projects. if you ever find a case where the image fails as a rustult of a call to qemu/libvirt please reportat that as a private security bug instead so it can be properly assessed. This is currently begin enforced by verify_base_size which predates that work so it should not be a security issue in any modern release. https://github.com/openstack/nova/blob/64ca204c9cf497b0dcfff2d3a24b0dd795a57... there is work still ongoing to improve the level of security provided by glance https://review.opendev.org/q/topic:%22bp/glance-as-defender%22 to my knowledge that does not involve computing the virtual image size or storing it. while we could not fully trust any value stored in glance if a future enhancement provided a virtual size we could reject it earlier.
Shouldn't the Nova API reject the request with an explicit warning telling the user to resize the VM before trying to rebuild?
nova checks the metadata related to the image in the api but it does not have access to the image data until we get to the compute node. so if you set MIN_DISK metadata on the vm and we see that that is smaller then the flavor root disk we will reject the request. my guess is you have not properly set the min_disk value on the image, glance will not populate the for you.
Thank you very much [1] _https://docs.openstack.org/python-openstackclient/latest/cli/command-objects... [2]https://bugs.launchpad.net/nova/+bug/2114855 Bug #2114855 “VM rebuild starts even if image virtual size is gr...” : Bugs : OpenStack Compute (nova) <https://bugs.launchpad.net/nova/+bug/2114855> Description =========== Openstackclient + Nova API accept to rebuild server with virtual size greater than the specified flavor’s disk size. Steps to Reproduce ================== 1 - Create a server specifying a flavor with small disk size (example: 1 GB) and an image small enough to fit. openstack flavor create --ram 512 --disk 1 --vcpus 1 tiny openstack server create –flavor tiny –image cirros vm-test 2 - Try to rebuild the server using a larger image but that still fits. It’s v... bugs.launchpad.net