公云网博客

openstack在创建实例的时候，可以对实例进行文件注入，注入的内容为：

key  ssh公钥

network 网络参数，目前仅支持debian/ ubuntu 的 /etc/network/interfaces格式。其余的系统，请使用 dhcp

admin_password  注入超级用户 root 的密码

metadata 注入元数据meta.js

具体可以参见：nova/virt/disk/api.py

注入的时候，有几种方式，包括loop, guestfs, nbd, mount等，其中 mount 不安全。缺省使用:

img_handlers=”loop,nbd,guestfs”

对于qcow2 格式的镜像，必须需要使用guestfs或  nbd配合 qemu-nbd注入。但是 guestfs 的速度较慢。遗憾的是 CentOS/RedHat 6.2 中，内核没有编译nbd模块, qemu也没有编译 qemu-nbd程序。

解决办法：

1、手工编译 nbd 和 qemu-nbd

http://www.cyberciti.biz/faq/rhel5-installing-kernel-source-code/

http://jamyy.dyndns.org/blog/2012/02/3582.html

2、向RedHat递交bug 报告

https://lists.launchpad.net/openstack/msg07392.html

https://bugzilla.redhat.com/show_bug.cgi?id=788485

nova-network在删除实例的时候，会解绑固定IP。有两种机制，超时和强制。采用超时解绑上用一个定时任务（fixed_ip_disassociate_timeout 配置）解绑。强制解绑使用另外一个选项force_dhcp_release，当实例删除的时候，调用dhcp_release外部命令，发送一个DHCPRELEASE 消息给 dnsmasq 服务器，dnsmasq服务器删除固定IP的匹配关系。

在 multi-host 环境下，force_dhcp_release 很重要。dhcp_release是dnsmasq的一部分，但是在 Fedora 和 CentOS 下，没有编译进 dnsmasq 包。另外 Fedora 的 openstack-nova 没有包含dhcp_release命令的 sudoers 规则.

The component nova-network disassociate fixed IP of VM when it deleted. There are two mechanisms by timeout and force. Disassociate by timeout is a periodical task (period can be set by flag –fixed_ip_disassociate_timeout). The force disassociate is optional (enabled by flag –force_dhcp_release) and involved when instance have been deleted. In fact this process use CLI tool dhcp_release to send DHCPRELEASE message to dnsmasq server for drop lease and change state of fixed ip in database. In multi-host scheme it is important. So, dhcp_release is part of dnsmasq and not included in builds in Fedora and CentOS. Also, in Fedora builds of openstack-nova does not exists sudoers rule for dhcp_release command.

配置的时候，有两种方式读取 catalog

在 openstack 下，重新启动compute，实例不会自动恢复，解决办法：

修改 /etc/nova.conf，添加两个选项：

start_guests_on_host_boot = True

resume_guests_state_on_host_boot =True

注意的是，如果使用了nova-volume，则自动启动还是有问题的。这时，需要自己写脚本，进行启动。

这两个选项在文档中没有说明，大家可以参见代码：

nova/compute/manager.py:
if ((expect_running and FLAGS.resume_guests_state_on_host_boot) or
FLAGS.start_guests_on_host_boot):
LOG.info(_(‘Rebooting instance after nova-compute restart.’),
locals(), instance=instance)
self.reboot_instance(context, instance[‘uuid’])
elif drv_state == power_state.RUNNING:
# Hyper-V and VMWareAPI drivers will raise an exception
try:
net_info = self._get_instance_nw_info(context, instance)
self.driver.ensure_filtering_rules_for_instance(instance,
self._legacy_nw_info(net_info))
except NotImplementedError:
LOG.warning(_(‘Hypervisor driver does not support ‘
‘firewall rules’))

云计算，如果是对外提供服务，那就肯定面临租户的问题。

在openstack的历史里，有不同的叫法。

tenant = project in nova

tenant = account in swift

看到一篇蒋清野的文章：

http://www.qyjohn.net/?p=1247

文章较长 ，对Eucalyptus, OpenNebula, OpenStack, OpenQRM, XenServer, Oracle VM, CloudStack, ConVirt进行了比较，结论是倾向选择Eucalyptus。

结论是Eucalyptus和ConVirt胜出，其主要观点是：

Eucalyptus的历史比OpenStack稍长，用户群比OpenStack要大，社区的活跃程度也比OpenStack要高。

Ubuntu 11.04也集成了OpenStack作为其UEC的基础构架之一，表明OpenStack已经得到了社区的重视和支持。

OpenStack不缺省地提供基于浏览器的用户界面。

但是，我的结论和观察，和上述情况完全相反，认为 openstack将在这场竞争中胜出，因为：

1、openstack 是完全开源、开放的，采用 apache 2.0许可证

开放源码，开放设计，开放开发和开放社区，是openstack的理念。目前有159家公司和2685多人加入了openstack社区的开发、研究，而且这个数目还在以很快的速度被刷新。

openstack的发展，由一个12人的委员会负责，其中四个细微为RackSpace所有。委员会的成员一方面是贡献代码，另外一方面是组织、评审、协调开发的过程，整个过程，所有人都可以参与，比如提出你的设想（blueprint），提出代码的修改并且递交review，提出bug或者问题，对现有问题进行回复。社区的活跃程度很高，响应速度也很快。我不知道蒋先生文中所说的48小时的响应，有什么证据？

2、openstack发展很快，从2010.10.21至今已经发布四个版本，并且在2012.4.5日将发布最新的essex版本。社区开始是约3个月发布一个版本，目前是半年发布一个版本。bug得到很快修正，功能得到很快发展，包括文中说到的没有“基于浏览器的用户界面”，也早就成为过去时.

3、ubuntu 选择openstack作为云的基础平台

http://bartongeorge.net/2011/01/11/mark-shuttleworth-on-uec-and-openstack/

http://www.theregister.co.uk/2011/01/12/ubuntu_goes_open_stack/

http://www.theregister.co.uk/2011/03/07/ubuntu_cloud_belt_tightening/

http://www.theregister.co.uk/2011/05/10/canonical_ubuntu_openstack/

由于Eucalyptus的部分开源和支持亚马逊的EC2 API，ubuntu在 2010.4 LTS版本中，将Eucalyptus作为云基础平台。但是2011.1.11，ubuntu的创始人mark shuttleworth就宣布，将转向openstack，并且在2012.4 LTS版本中，将openstack作为云基础平台。

原因主要是Eucalyptus的可扩展性不强和不完全开源。

目前主流的Linux操作系统，包括 Fedora, SUSE 等都将支持openstack。

4、openstack在大规模部署公有云时，在可扩展性上有优势，而且也可用于私有云，一些企业特性正在逐步完善中。

5、社区开发人员活跃，中国目前参与的开发人员有：

Hengqing Hu <hudayou@hotmail.com>
Peng Yong <ppyy@pubyun.com>
Yaguang Tang <heut2008@gmail.com>
Yun Mao <yunmao@gmail.com>
Yun Shen <Yun.Shen@hp.com>
Zhixue Wu <Zhixue.Wu@citrix.com>
Zhongyue Luo <lzyeval@gmail.com>

5、从新浪微博上，搜索openstack有10,641 条结果，搜索Eucalyptus有 2,322 条结果，可以看出关心程度相差很大。

本来想着Google  trends上比较的，但是由于Eucalyptus的另外一个意思是“桉树”，无法准确比较。但是google trends可以看出 openstack  的关注程度增长很快。

由此可以看出，Eucalyptus是成也开源、败也开源，成也ubuntu、败也ubuntu。目前 openstack 发展势头良好，随着 ubuntu 12.04 LTS 正式全面将Eucalyptus替换成openstack，openstack将超过Eucalyptus成为云平台基础的第一选择。

当rabbitmq 停掉以后，过两分钟左右，compute会自动退出，日志中出现：

2012-03-25 21:41:26 INFO nova.rpc.common [-] Reconnecting to AMQP server on 192.168.28.5:5672
2012-03-25 21:41:27 ERROR nova.rpc.common [-] AMQP server on 192.168.28.5:5672 is unreachable: [Errno 113] EHOSTUNREACH. Trying again in 7 seconds.
(nova.rpc.common): TRACE: Traceback (most recent call last):
(nova.rpc.common): TRACE: File “/usr/lib/python2.6/site-packages/nova/rpc/impl_kombu.py”, line 446, in reconnect
(nova.rpc.common): TRACE: self._connect()
(nova.rpc.common): TRACE: File “/usr/lib/python2.6/site-packages/nova/rpc/impl_kombu.py”, line 423, in _connect
(nova.rpc.common): TRACE: self.connection.connect()
(nova.rpc.common): TRACE: File “/usr/lib/python2.6/site-packages/kombu/connection.py”, line 118, in connect
(nova.rpc.common): TRACE: return self.connection
(nova.rpc.common): TRACE: File “/usr/lib/python2.6/site-packages/kombu/connection.py”, line 438, in connection
(nova.rpc.common): TRACE: self._connection = self._establish_connection()
(nova.rpc.common): TRACE: File “/usr/lib/python2.6/site-packages/kombu/connection.py”, line 404, in _establish_connection
(nova.rpc.common): TRACE: conn = self.transport.establish_connection()
(nova.rpc.common): TRACE: File “/usr/lib/python2.6/site-packages/kombu/transport/pyamqplib.py”, line 242, in establish_connection
(nova.rpc.common): TRACE: connect_timeout=conninfo.connect_timeout)
(nova.rpc.common): TRACE: File “/usr/lib/python2.6/site-packages/kombu/transport/pyamqplib.py”, line 51, in __init__
(nova.rpc.common): TRACE: super(Connection, self).__init__(*args, **kwargs)
(nova.rpc.common): TRACE: File “/usr/lib/python2.6/site-packages/amqplib/client_0_8/connection.py”, line 125, in __init__
(nova.rpc.common): TRACE: self.transport = create_transport(host, connect_timeout, ssl)
(nova.rpc.common): TRACE: File “/usr/lib/python2.6/site-packages/amqplib/client_0_8/transport.py”, line 220, in create_transport
(nova.rpc.common): TRACE: return TCPTransport(host, connect_timeout)
(nova.rpc.common): TRACE: File “/usr/lib/python2.6/site-packages/amqplib/client_0_8/transport.py”, line 58, in __init__
(nova.rpc.common): TRACE: self.sock.connect((host, port))
(nova.rpc.common): TRACE: File “/usr/lib/python2.6/site-packages/eventlet/greenio.py”, line 179, in connect
(nova.rpc.common): TRACE: socket_checkerr(fd)
(nova.rpc.common): TRACE: File “/usr/lib/python2.6/site-packages/eventlet/greenio.py”, line 43, in socket_checkerr
(nova.rpc.common): TRACE: raise socket.error(err, errno.errorcode[err])
(nova.rpc.common): TRACE: error: [Errno 113] EHOSTUNREACH
(nova.rpc.common): TRACE:

这个问题，是由于openstack中，对rabbitmq 如果失去连接，会进行尝试，缺省是尝试12次，每次间隔10秒，到时间还不能连接，就抛出错误，退出。

解决办法，在 nova.conf 加入下面的参数：

#防止 rabbitmq重启导致 compute 死掉
rabbit_max_retries=0

具体原因，可以参见代码：impl_kombu.py

self.max_retries = FLAGS.rabbit_max_retries

def reconnect(self):
“””Handles reconnecting and re-establishing queues.
Will retry up to self.max_retries number of times.
self.max_retries = 0 means to retry forever.
Sleep between tries, starting at self.interval_start
seconds, backing off self.interval_stepping number of seconds
each attempt.
“””

if self.max_retries and attempt == self.max_retries:
LOG.exception(_(‘Unable to connect to AMQP server on ‘
‘%(hostname)s:%(port)d after %(max_retries)d ‘
‘tries: %(err_str)s’) % log_info)
# NOTE(comstud): Copied from original code. There’s
# really no better recourse because if this was a queue we
# need to consume on, we have no way to consume anymore.
sys.exit(1)

参考文档：
http://keystone.openstack.org/configuration.html
http://keystone.openstack.org/api_curl_examples.html

1、重要概念：

Admin Token
所有服务共享的一个密钥，如果设置不同，哪些依赖keystone的服务将无法正常工作。

Tenants
做keystone里，Tenants 是一个高层次的组，表示一组用户。一个tenant 是一个小组，共同拥有 Nova里的虚拟机，或者Swift里的容器。一个tenant可以有一个或者多个用户，用户可以属于一个或者多个tenant，针对每个tenant，用户拥有一个角色(role)。
Tenants are the high level grouping within Keystone that represent groups of users. A tenant is the grouping that owns virtual machines within Nova, or containers within Swift. A tenant can have zero or more users, Users can be associated with more than one tenant, and each tenant – user pairing can have a role associated with it.

认证几个要素：tenants, users, roles

业务端口：5000
管理端口：35357
2、业务API 测试：

获取版本号：
curl http://0.0.0.0:5000/ | python -mjson.tool
curl http://0.0.0.0:5000/v2.0/ | python -mjson.tool

获取api扩展：
curl http://0.0.0.0:5000/v2.0/extensions | python -mjson.tool

用普通用户登录：
curl -X POST -d ‘{“auth”: {“passwordCredentials”:{“username”: “admin”, “password”: “nova”}}}’ -H “Content-type: application/json” http://0.0.0.0:5000/v2.0/tokens | python -mjson.tool

查看自己的租户：
curl -H “X-Auth-Token:614be856b02449439b116c0b28e94217” http://0.0.0.0:5000/v2.0/tenants | python -mjson.tool

3、管理API测试：

获取版本号：
curl http://0.0.0.0:35357/ | python -mjson.tool
curl http://0.0.0.0:35357/v2.0/ | python -mjson.tool

获取api扩展：
curl http://0.0.0.0:35357/v2.0/extensions | python -mjson.tool

用角色 admin 登录：

curl -X POST -d ‘{“auth”: {“tenantId”: “6a524dbe23dd4e4ab672cd163c85a27d”, “passwordCredentials”:{“username”: “admin”, “password”: “nova”}}}’ -H “Content-type: application/json” http://0.0.0.0:35357/v2.0/tokens | python -mjson.tool

校验 token 的有效，并返回token的信息：
curl -H “X-Auth-Token: 32efbc8c22af4ad6a8f03d051dc3413b” http://0.0.0.0:35357/v2.0/tokens/82c8d77cac0a4fdba83b2191185ddb39 |python -mjson.tool

使用 HEAD校验，如果返回码是 20X, 表示 token 有效：
curl -I -H “X-Auth-Token: 5a10b008add4435f8473d2b11d3ba8a8” http://0.0.0.0:35357/v2.0/tokens/5a10b008add4435f8473d2b11d3ba8a8

这个api不对：
curl -H “X-Auth-Token:5a10b008add4435f8473d2b11d3ba8a8” http://0.0.0.0:35357/v2.0/tokens/5a10b008add4435f8473d2b11d3ba8a8/endpoints

返回租户：
curl -H “X-Auth-Token:5a10b008add4435f8473d2b11d3ba8a8” http://0.0.0.0:35357/v2.0/tenants|python -mjson.tool

返回某个租户：
curl -H “X-Auth-Token:5a10b008add4435f8473d2b11d3ba8a8” http://0.0.0.0:35357/v2.0/tenants/6a524dbe23dd4e4ab672cd163c85a27d |python -mjson.tool

返回用户：
curl -H “X-Auth-Token:5a10b008add4435f8473d2b11d3ba8a8” http://0.0.0.0:35357/v2.0/users|python -mjson.tool

返回某个用户：
curl -H “X-Auth-Token:5a10b008add4435f8473d2b11d3ba8a8” http://0.0.0.0:35357/v2.0/users/3ff8fbca9794436c996d8c6e41427530|python -mjson.tool

返回某个租户上，用户授予的角色：
curl -H “X-Auth-Token:5a10b008add4435f8473d2b11d3ba8a8” http://0.0.0.0:35357/v2.0/tenants/6a524dbe23dd4e4ab672cd163c85a27d/users/3ff8fbca9794436c996d8c6e41427530/roles |python -mjson.tool

返回某个用户的角色：（出错，没有实现，参见 https://bugs.launchpad.net/keystone/+bug/933565)
curl -H “X-Auth-Token:5a10b008add4435f8473d2b11d3ba8a8” http://0.0.0.0:35357/v2.0/users/3ff8fbca9794436c996d8c6e41427530/roles