通常用户在创建了虚拟机之后,可能会适当地修改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之后的确认工作