Based on the currently available code ( commit 114109dbf4094ae6b6333d41c84bebf6f85c4e48 – 2012-09-13)
This is a deep dive into what happens (and where in the code) during a resize down (e.g., flavor 4 to flavor 2) with a Nova configuration that is backed by XenServer/XenAPI. Hopefully the methods used in Nova’s code will not change over time, and this guide will remain good starting point.
Steps 1-6a are identical to my previous entry " Deep dive: OpenStack Nova Resize Up with XenAPI/Xenserver". This deep dive will examine the divergence between resize up and resize down in Nova, as there are a few key differences.
6b) The instance resize progress gets an update. The VM is shutdown via XenAPI.
- ./nova/virt/xenapi/vmops.py
- def _migrate_disk_resizing_down
6c) The source VDI is copied on the hypervisor via XenAPI VDI.copy. Then, a different, new VDI is along with a VBD that it is plugged into the compute node. The partition and filesystem of the new disk are resized via _resize_part_and_fs, using e2fsck, tune2fs, parted, and tune2fs. The source VDI copy is also attached to nova-compute. Via _sparse_copy, which is configurable but by default true, nova-compute temporarily takes ownership of both devices (source read, dest write) and performs a block level copy, omitting zeroed blocks.
- ./nova/virt/xenapi/vm_utils.py
- def _resize_part_and_fs
- def _sparse_copy
- nova/utils.py
- def temporary_chown
6d) Progress is again updated. The devices that were attached are unplugged, and the VHDs are copied in the same fashion as outlined in steps 6a1i-6b2 from the deep dive on resizing up are used, aside from 6b2.