instance‘s root_gb is 0, but the actual root_gb size is not 0.

[Charlotte Han]

1. I have a flavor named 'disk0' that's disk size is 0.
[root@opencos114-222 ~(keystone_admin)]# nova flavor-list
+--------------------------------------+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+--------------------------------------+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| 1 | m1.tiny | 512 | 1 | 0 | | 1 | 1.0 | True |
| 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True |
| 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True |
| 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True |
| 41ef4850-14a6-424a-81b6-99ba0edbec52 | disk0 | 100 | 0 | 0 | | 1 | 1.0 | True |
| 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True |
+--------------------------------------+-----------+-----------+------+-----------+------+-------+-------------+-----------+

2. I use disk0 flavor to boot a instance and instance' uuid is 9fb1389d-5d1b-45ac-8a9d-437f69f88422.
[root@opencos114-222 ~(keystone_admin)]# nova boot --image 66d2336c-31d2-495a-833d-6470b3d46263 --flavor 41ef4850-14a6-424a-81b6-99ba0edbec52 --nic net-id=9b68affa-f2f1-4d74-99d0-5b3d712846dc hanrong
+--------------------------------------+-----------------------------------------------+
| Property | Value |
+--------------------------------------+-----------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | - |
| OS-EXT-SRV-ATTR:hypervisor_hostname | - |
| OS-EXT-SRV-ATTR:instance_name | instance-00000015 |
| OS-EXT-STS:power_state | 0 |
| OS-EXT-STS:task_state | scheduling |
| OS-EXT-STS:vm_state | building |
| OS-SRV-USG:launched_at | - |
| OS-SRV-USG:terminated_at | - |
| accessIPv4 | |
| accessIPv6 | |
| adminPass | Q5iUAxTW5r29 |
| config_drive | |
| created | 2015-03-28T08:38:38Z |
| flavor | disk0 (41ef4850-14a6-424a-81b6-99ba0edbec52) |
| hostId | |
| id | 9fb1389d-5d1b-45ac-8a9d-437f69f88422 |
| image | cirror (66d2336c-31d2-495a-833d-6470b3d46263) |
| key_name | - |
| metadata | {} |
| name | hanrong |
| os-extended-volumes:volumes_attached | [] |
| progress | 0 |
| security_groups | default |
| serial_type | file |
| status | BUILD |
| tenant_id | 94d1a1b3260648f4be6bc423fab73bfa |
| updated | 2015-03-28T08:38:38Z |
| user_id | 1f60084b664844aab2304eb0fc288fba |
+--------------------------------------+-----------------------------------------------+

3. I see the instance's root_gb is 0 in nova database.
[root@opencos114-222 ~(keystone_admin)]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 9905
Server version: 5.5.36-MariaDB-wsrep MariaDB Server, wsrep_25.9.r3961

Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> use nova
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [nova]> select uuid,root_gb from instances where uuid='9fb1389d-5d1b-45ac-8a9d-437f69f88422';
+--------------------------------------+---------+
| uuid | root_gb |
+--------------------------------------+---------+
| 9fb1389d-5d1b-45ac-8a9d-437f69f88422 | 0 |
+--------------------------------------+---------+
1 row in set (0.00 sec)

4. But this instance's actual root disk size is not 0.
[root@opencos114-98 instances]# cd 9fb1389d-5d1b-45ac-8a9d-437f69f88422/
[root@opencos114-98 9fb1389d-5d1b-45ac-8a9d-437f69f88422]# ll
total 992
-rw-rw---- 1 root root 16750 Mar 28 16:39 console.log
-rw-r--r-- 1 root root 1048576 Mar 28 16:39 disk
-rw-r--r-- 1 root root 79 Mar 28 16:38 disk.info
-rw-r--r-- 1 root root 1725 Mar 28 16:38 libvirt.xml
[root@opencos114-98 9fb1389d-5d1b-45ac-8a9d-437f69f88422]# qemu-img info disk
image: disk
file format: qcow2
virtual size: 39M (41126400 bytes)
disk size: 1.3M
cluster_size: 65536
backing file: /var/lib/nova/instances/_base/cff6eefd4b2262239fafae317589c4507325abe9
Format specific information:
    compat: 1.1
    lazy refcounts: false

5. Many disk statistics are resulting from instances' root_gb field. I think 0 is improper, image's virtual size would be more appropriate.

[Gary Kotton (garyk)]

Hi,
I do not think that this is a bug. When the flavor size is 0 then the driver will make use of the size of the image that is downloaded.
Thanks
Gary

[Sean Dague (sdague)]

This is the currently defined behavior of nova. 0 means be adaptive.

[Adrien Cunin (adri2000)]

With this behaviour nova can keep scheduling instances with a disk size = 0 flavor without realizing it's actually filling up the disk of the compute nodes.

That does look like a bug to me, and it could even lead to a denial of service, no?

[Charlotte Han (hanrong)]

@Adrien Cunin (adri2000), I agree with you.

I think instance's root_gb is virtual size of used image when this instance's flavor.root_gb is 0.

[Balazs Gibizer (balazs-gibizer)]

A couple of months back I added a clarification to the doc about disks == 0 case https://review.openstack.org/#/c/339034/
It might not an optimal behavior but it is a documented behavior of nova.

[Charlotte Han (hanrong)]

Thank you，I see。

But I have a use case:
Users may create some virtual machines for the processing of their business, these virtual machines use customized images which can meet their requirement. When users create virtual machines using these customized images in batches, they don't need to know the size of instance's root_gb, so they can use flavor with its disk size as 0.
In this case, the value of root_gb's filed in db table of instances is 0 for every virtual machine, but it's real value is not 0. This will lead to live migrate failure since live-migration's destination compute node's disk_available_least is always less than 0.
We often enable disk_filter to control compute nodes's disk space, but when the value of root_gb's filed in db table of instances is 0, this filter doesn't work.

So, I think the value of root_gb's filed in db table of instances should be equal to image's virtual size in this use case.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/398891

[OpenStack Infra (hudson-openstack)]

Change abandoned by Stephen Finucane (<email address hidden>) on branch: master
Review: https://review.openstack.org/398891