resize does not resize ephemeral disks

[Matthew Booth]

Nova resize does not resize ephemeral disks. I have tested this with the default qcow2 backend, but I expect it to be true for all backends.

I have created 2 flavors:

| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 1 |
| disk | 1 |
| extra_specs | {} |
| id | test-1 |
| name | test-1 |
| os-flavor-access:is_public | True |
| ram | 256 |
| rxtx_factor | 1.0 |
| swap | 1 |
| vcpus | 1 |

and:

| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 2 |
| disk | 2 |
| extra_specs | {} |
| id | test-2 |
| name | test-2 |
| os-flavor-access:is_public | True |
| ram | 512 |
| rxtx_factor | 1.0 |
| swap | 2 |
| vcpus | 2 |

I boot an instance with flavor test-1 with:

$ nova boot --flavor test-1 --image cirros foo

It creates instance directory 3fab0565-2eb1-4fd9-933b-4e1d80b1b18c containing (amongst non-disk files) disk, disk.eph0, disk.swap, and disk.config. disk.config is not relevant here.

I check the sizes of each of these disks:

instances]$ for disk in disk disk.eph0 disk.swap; do qemu-img info 3fab0565-2eb1-4fd9-933b-4e1d80b1b18c/$disk; done

image: 3fab0565-2eb1-4fd9-933b-4e1d80b1b18c/disk
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 10M
cluster_size: 65536
backing file: /home/mbooth/data/nova/instances/_base/1ba6fbdbe52377ff7e075c3317a48205ac6c28c4
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: 3fab0565-2eb1-4fd9-933b-4e1d80b1b18c/disk.eph0
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 324K
cluster_size: 65536
backing file: /home/mbooth/data/nova/instances/_base/ephemeral_1_40d1d2c
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: 3fab0565-2eb1-4fd9-933b-4e1d80b1b18c/disk.swap
file format: qcow2
virtual size: 1.0M (1048576 bytes)
disk size: 196K
cluster_size: 65536
backing file: /home/mbooth/data/nova/instances/_base/swap_1
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

I resize foo with:

$ nova resize foo test-2 --poll

I check the sizes again:

instances]$ for disk in disk disk.eph0 disk.swap; do qemu-img info 3fab0565-2eb1-4fd9-933b-4e1d80b1b18c/$disk; done

image: 3fab0565-2eb1-4fd9-933b-4e1d80b1b18c/disk
file format: qcow2
virtual size: 2.0G (2147483648 bytes)
disk size: 26M
cluster_size: 65536
backing file: /home/mbooth/data/nova/instances/_base/1ba6fbdbe52377ff7e075c3317a48205ac6c28c4
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: 3fab0565-2eb1-4fd9-933b-4e1d80b1b18c/disk.eph0
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 384K
cluster_size: 65536
backing file: /home/mbooth/data/nova/instances/_base/ephemeral_1_40d1d2c
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: 3fab0565-2eb1-4fd9-933b-4e1d80b1b18c/disk.swap
file format: qcow2
virtual size: 2.0M (2097152 bytes)
disk size: 196K
cluster_size: 65536
backing file: /home/mbooth/data/nova/instances/_base/swap_2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Note that the root and swap disks have been resized, but the ephemeral disk has not. This is caused by 2 bugs.

Firstly, there is some code in finish_migration in the libvirt driver which purports to resize disks. This code is actually a no-op, because disk resizing has already been done by _create_image, which called cache() with the correct size, and therefore did the resizing. However, as noted in a comment, the no-op code would not have covered our ephemeral disk anyway, as it only loops over 'disk.local', which is the legacy disk naming.

Secondly, _create_image does not iterate over ephemeral disks at all when called by finish_migration, because finish_migration explicitly passes block_device_info=None.

[Diana Clarke (diana-clarke)]

Here are some additional notes that demonstrate the issue.

    https://notehub.org/o3mjz

I hope to add a tempest test for this case next week.

[Matt Riedemann (mriedem)]

This is probably a duplicate of bug 1558880.