Due to a previous bug that was never caught and the fact that we can now pass ephemeral and block devices through the API, it is possible to ask nova to create an arbitrarily large ephemeral block device - which nova will happily do (and by default make it raw).
The bug was introduced in commit 0ef7e15e225efcce3e02098cb1d57f9f40181f82 as before that commit the ephemeral device size will be defaulted to whatever was in the instance_type - due to a bug this defaulting was not done anymore (see compute.api.API._update_block_device_mapping).
Steps to reproduce:
ndipanov@localhost devstack]$ nova flavor-show 1
+----------------------------+---------+
| Property | Value |
+----------------------------+---------+
| name | m1.tiny |
| ram | 512 |
| OS-FLV-DISABLED:disabled | False |
| vcpus | 1 |
| extra_specs | {} |
| swap | |
| os-flavor-access:is_public | True |
| rxtx_factor | 1.0 |
| OS-FLV-EXT-DATA:ephemeral | 0 | <--- Ephemeral is 0
| disk | 1 |
| id | 1 |
+----------------------------+---------+
[ndipanov@localhost devstack]$ nova --debug boot --image 308f190c-d2f7-44fe-9b6d-7a28e2e2aa64 --flavor 1 --block-device source=blank,dest=local,size=2,device=vdb testvme2 #using the not yet merged novaclient patch https://review.openstack.org/#/c/38815/. The request dict is as follows: '{"server": {"name": "testvme2", "imageRef": "308f190c-d2f7-44fe-9b6d-7a28e2e2aa64", "block_device_mapping_v2": [{"source_type": "image", "delete_on_termination": true, "boot_index": 0, "uuid": "308f190c-d2f7-44fe-9b6d-7a28e2e2aa64", "destination_type": "local"}, {"source_type": "blank", "delete_on_termination": true, "device_name": "vdb", "volume_size": "2", "destination_type": "local"}], "flavorRef": "1", "max_count": 1, "min_count": 1}}'
[ndipanov@localhost devstack]$ nova list
+--------------------------------------+----------+--------+------------+-------------+------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+----------+--------+------------+-------------+------------------+
| 6c8a571c-3c1b-4fef-800e-0cecea927566 | testvme2 | ACTIVE | None | Running | private=10.0.0.2 |
+--------------------------------------+----------+--------+------------+-------------+------------------+
[ndipanov@localhost devstack]$ cd /opt/stack/data/nova/instances/_base/
[ndipanov@localhost _base]$ ls -lah
total 130M
drwxrwxr-x. 2 ndipanov libvirtd 4.0K Aug 30 10:59 .
drwxr-xr-x. 5 ndipanov root 4.0K Aug 30 10:59 ..
-rw-rw-r--. 1 ndipanov libvirtd 4.8M Aug 30 10:59 65706cf4-0f63-4cf6-a8ee-a1dc447a6380
-rw-rw-r--. 1 qemu qemu 24M Aug 30 10:59 8bf383ae7171db9b882fc6e33eebf619896d67b7
-rw-r--r--. 1 qemu qemu 2.0G Aug 30 10:59 ephemeral_2_default
-rw-rw-r--. 1 ndipanov libvirtd 3.6M Aug 30 10:59 fe478037-cd36-4517-b886-fd6e14d7462e
We can see that the raw image was happily created by nova. completely disregarding the limitation.
I have attached a proposed patch.
This bug only affects current trunk as of the commit mentioned above.
not totally sure this needs to be a security bug since there hasn't been a release with this code in. I'm ok with the patch. I'm a little split on whether local disks should be limited via root + ephemeral or just ephemeral.
For example if the flavor type is 100G root and 100G ephemeral it might be nice to allow users to use that 200G total for both the root and ephemeral.