通常用户在创建了虚拟机之后，可能会适当地修改flavor，比如CPU多配置一些核，内存扩大一些等，这样都会用到resize功能，但是往往修改了规格之后，有时候会发现虚拟机所在的宿主节点机也发生了改变，也就是发生了迁移，也就是说可以理解为resize是在migrate的同时，改变了虚拟机的flavor
但在具体实现的地方，有这么一段注释
def resize(self, context, instance, flavor_id=None, force_host=None,
**extra_instance_updates):
"""Resize (ie, migrate) a running instance.
If flavor_id is None, the process is considered a migration, keeping
the original flavor_id. If flavor_id is not None, the instance should
be migrated to a new host and resized to the new flavor_id.
"""
这里写的很清楚，传进去的可选参数flavor_id如果为空的话，那么虚拟机执行resize操作其实是和migrate操作是一样的效果，有兴趣可以看下函数实现，在nova/compute/api.py里；直接查看一下resize命令可以看到这两个参数居然都是必选的，这说明了API调用和novaclient封装的还是有一定区别的
nova help resize usage: nova resize [--poll] <server> <flavor>
但是否一定会修改host呢，如果是这样，那单节点岂不是不能进行resize操作了？所以答案显示然否定的
$ cat /etc/nova/nova.conf | grep allow_resize allow_resize_to_same_host = True
在nova的配置文件当中，加入这一行，就能兼容单节点和多节点的resize操作，但是要注意的是，修改了配置之后一定要重启nova服务，具体来说我没记错的话应该是nova-api和nova-compute这两个服务
我们对openstack这里做了一定修改，为什么设置成允许不更换节点呢，甚至优先考虑不更换，主要来自两个方面，一个是从容量分配的角度，调度算法已经被修改成虚拟机的创建优先调度到资源更多的节点上，以保证节点之间负载的均衡，另一个就是从性能方面考虑，假如本节点在资源最充足的情况下，为何还要调度迁移到其它节点去呢，直接不更换节点进行扩展flavor操作，都省了migrate这一个漫长的过程
下面虚拟机进行resize，这里就直接通过novaclient命令执行，而不用RESTful的http接口了
通过一个脚本，打印resize过程中status的变化
#!/bin/bash
uuid=$1
tmp=ACTIVE
echo "Start: "`nova show $uuid | awk '{if ($2 == key) print $4}' key=OS-EXT-SRV-ATTR:host`
nova resize $uuid 2
while true; do
status=`nova show $uuid | awk '{if ($2 == key) print $4}' key=status`
if test $status != $tmp; then
tmp=$status
echo $status
elif test $status = "ACTIVE"; then
echo $status
break
fi
sleep 2
done
echo "Stop: "`nova show $uuid | awk '{if ($2 == key) print $4}' key=OS-EXT-SRV-ATTR:host`
这里通过nova show得到status的输出状态，最终执行的结果为
Start: 10-180-0-47 RESIZE VERIFY_RESIZE ACTIVE ACTIVE Stop: 10-180-0-47
可以看到这里的过程，虚拟机状态只有两个，一个是RESIZE，另一个就是RESIZE之后的确认工作
