SGE 运行在 OpenStack 上的 HOST_NOT_RESOLVABLE 问题

4月份在介绍《安装 Sun Grid Engine》的时候曾经提过我们希望能在云计算平台上快速创建多个高配置虚拟机并自动接入到我们的 SGE (Sun Grid Engine) 集群,这样能迅速满足整个实验室计算高峰需求。

我们现在已经把 OpenStack 整合到了高性能集群生产环境,每台物理服务器上配置成一个 OpenStack Compute 计算节点(nova-compute),每个 Compute 节点上运行一个虚拟机,每个虚拟机配置成一个 SGE 运算节点(sge_execd)。为啥不直接在物理服务器上配置成 SGE 运算节点?因为运行在虚拟机上更方便、更灵活,可以随时迅速关闭、重装、更换、启动系统。这也是云计算、虚拟机的巨大优势,不用去机房捣腾硬件、不用刻盘重装系统,省时省力。

在 OpenStack 的一个实例上(Ubuntu)安装完 SGE 执行结点(hostname 是 grid62),手动启动守护进程(sge_execd)的时候报错:

$ ssh root@grid62

# /etc/init.d/gridengine-exec restart
 * Restarting Sun Grid Engine Execution Daemon sge_execd
error: communication error for "grid62.novalocal/execd/1" running on port 6445: "can't bind socket"
error: commlib error: can't bind socket (no additional information available)

到主控节点(hostname 是 grid00)上查看日志发现原因 grid62.novalocal 这个域名不能解析:

$ ssh root@grid00

# cat /var/spool/gridengine/qmaster/messages | grep grid62
...
08/26/2012 12:14:15|listen|grid00|E|commlib error: can't resolve host name (can't resolve rdata hostname "grid62.novalocal")
08/26/2012 12:14:16|listen|grid00|E|commlib error: local host name error (remote rdata host name "grid62.novalocal" is not equal to local resolved host name "(HOST_NOT_RESOLVABLE)")

进一步调查发现 grid62.novalocal 这个名字我们的 Puppet 服务器在 OpenStack 启动虚拟机实例后注射到虚拟机 /etc/hosts 里面的(我们的 SGE 节点由 Puppet 管理),Puppet 得到这个 grid62.novalocal 名字而不是 grid62.vpsee.com 这样真实的域名和 OpenStack 自己的 DNS 管理有关,这个问题从 Puppet 或 OpenStack dnsmasq 方面入手都可以解决,不过最简单的方法是从虚拟机实例入手。

解决办法是在 grid62 这个虚拟机实例的 /etc/hosts 文件里加上 grid62 一行,然后 kill 掉现有的 sge_execd 进程并重新启动 gridengine-exec (sge_execd):

# vi /etc/hosts
127.0.0.1	localhost.localdomain	localhost
192.168.2.62	grid62.vpsee.com	grid62

# killall sge_execd

# /etc/init.d/gridengine-exec start

试玩 Rackspace 的 OpenStack 私有云系统

8月15日 Rackspace 发布了一套基于 OpenStack/KVM/Chef/Ubuntu 的私有云系统(代码名 Alamo),可以免费在自己的服务器上安装和建立自己的私有云(最多可以支持20个计算节点),简单的说 Alamo 就是 Rackspace 版的 OpenStack,OpenStack 生态链正在形成,有点像当年的 Linux(比如,Redhat 版的 Linux),明年 Redhat 将发布自己的 Redhat 版 OpenStack,版本大战还在后面。Alamo 可以免费使用,Rackspace 也为该系统提供付费技术支持,据称该系统也是 Rackspace 目前用于自己数据中心的云系统,稳定性有保障。有了这套傻瓜云计算系统,大家再不用自己痛苦的手动安装 OpenStack 或使用 DevStack 自动安装 OpenStack 了,任何人都可以快速的发布自己的私有云。

今天在 VMware ESXi 上试玩了一下这套系统,安装过程非常简单顺利,在 VMware ESXi 5.1 上安装这套系统有几点需要注意:

  • 因为 Alamo 使用了 KVM,所以确定 VMware ESXi 虚拟机上可以运行 KVM,如果直接在物理服务器上安装这一步就省了,不过要确定 CPU 支持虚拟化;
  • 到 Rackspace 官网注册后会收到下载链接,需要在24小时内下载 alamo-v1.0.0.iso,否则下载链接会失效;
  • 按照 Installing Rackspace Private Cloud – VMWare ESXi 教程在 VMware ESXi 上安装需要注意两个参数 vcpu.hotadd = FALSE, hypervisor.cpuid.v0 = FALSE. 可以 ssh 到 VMware ESXi 服务器后直接修改 vmx 配置文件(同样,在物理服务器上忽略这一步骤):
    $ ssh root@esxi.vpsee.com
    
    # vi /vmfs/volumes/localstore/alamo00/alamo00.vmx
    ...
    vcpu.hotadd = FALSE
    hypervisor.cpuid.v0 = FALSE
    ...
    

安装完成后界面如下(咋看上去还以为是 XenServer 呢):

rackspace openstack

用浏览器打开 IP 地址后出现 OpenStack Dashboard 的标准界面:
rackspace openstack dashboard

调整 KVM 虚拟硬盘大小

在 OpenNebula 上创建 KVM 虚拟机如果没有事先规划好虚拟机硬盘,运行一段时间后可能过小的硬盘会成为麻烦,需要能自由的增加虚拟机硬盘容积,有两个办法:一是可以在 OpenNebula 上动态加入第二块硬盘解决第一块硬盘过小的问题;二是直接在第一块硬盘上扩大容积。第一种办法好办,直接用 virsh attach-disk 就可以。如果和调整 Xen 虚拟硬盘大小一样,不想加第二块硬盘,只想在第一块硬盘上扩大容积呢?这里只讨论虚拟机文件形式的硬盘,LVM 形式的 “硬盘” 更容易一些,可以用 lvextend + fsck 调整硬盘大小。

最简单的办法是使用 GParted,挂载 gparted-live iso 文件后启动图形化界面操作分区,很容易:

# kvm -m 512 -hda disk.0 -cdrom /root/gparted-live-0.12.1-5.iso -boot d -vnc :1

这里主要介绍不用 GParted 的办法,分区用 fdisk 就可以了,没有必要也不适合在服务器上使用图形化工具。扩大硬盘镜像:

# qemu-img resize disk.0 +100GB

找一个空闲的 loop 设备并挂上硬盘镜像:

# losetup -f
/dev/loop0

# losetup /dev/loop0 disk.0

用 fdisk 把以前的分区都删除,然后重新创建分区,如果有 swap 区依然要用类型 82 标注,boot 区要标明 bootable,要非常小心:

# fdisk /dev/loop0

挂载硬盘里面的 LVM 分区、强制校验文件系统并扩大文件系统:

# kpartx -av /dev/loop0 
# e2fsck -f /dev/mapper/loop0p1 
# resize2fs -f /dev/mapper/loop0p1 

用 mount 测试一下扩大后的文件系统是否能正常 mount:

# mount /dev/mapper/loop0p1 /mnt
# ls /mnt

卸载和清理:

# umount /mnt
# kpartx -dv /dev/loop0 
# losetup -d /dev/loop0

把上面的步骤弄个小脚本,只对 http://cloud-images.ubuntu.com/ 下载的镜像有效,如果是自己做的镜像需要调整 fdisk 分区时候的指令。注意这里 fdisk 分区的时候 d 是删除分区 n 是创建分区 p 是主分区 1 是第1个 2是第2个 w 是保存,具体看 fdisk 帮助:

#!/bin/bash

DISK=$1
SIZE=$2

qemu-img resize $DISK $SIZE

losetup /dev/loop0 $DISK
fdisk /dev/loop0 <<EOF
d
n
p
1
2

w
EOF

kpartx -av /dev/loop0
e2fsck -f /dev/mapper/loop0p1
resize2fs -f /dev/mapper/loop0p1
kpartx -dv /dev/loop0

losetup -d /dev/loop0

强制删除 OpenStack Nova (Essex) 实例

上周在新版的 OpenStack (Essex) 上测了瞬间启动1000个 m1.tiny (512mb RAM) 实例的情况,主要看看 OpenStack 能否在短时间内正确处理大量创建实例请求以及各个节点、资源分配等情况。结果留下了大量状态为 ERROR 或 BUILD 的僵尸实例,这个结果和上个版本 Diablo 测试的情况差不多,没有明显改进,进一步调查发现主要原因在 RabbitMQ 服务,中途有很多连接都 timeout 了。这些僵尸实例没有运行或者创建不成功,只是在 nova 数据库里有纪录而已,直接用 nova delete 命令无法删除,那么如何强制删除呢?

# nova list
+--------------------------------------+--------+--------+-------------------+
|                  ID                  |  Name  | Status |      Networks     |
+--------------------------------------+--------+--------+-------------------+
| 6fc5696c-ed65-4e99-8fce-87dfc3cf36d9 |  c23   | BUILD  | private=10.0.0.23 |
| 98f5f421-581f-43d2-b1c7-f27cf5b61f02 |  c30   | BUILD  | private=10.0.0.30 |
| b768ebeb-4d73-4c31-8ec5-6bb2e90d4303 |  c63   | ERROR  | private=10.0.0.63 |
| b79e213b-055c-414f-a9f1-f230ed9aaae1 |  c95   | ERROR  | private=10.0.0.95 |
| efc6e9c7-4ef8-4350-9451-83bcfcafe101 |  c12   | ACTIVE | private=10.0.0.12 |
+--------------------------------------+--------+--------+-------------------+

先清理 instances 目录,看看对应的哪些 instance 是僵尸实例,有的话 rm -rf 删除即可:

# ls /var/lib/nova/instances/
_base  instance-00000023  instance-00000030

# rm -rf /var/lib/nova/instances/instance-00000023

然后清理 nova 数据库,可以登陆数据库后手动删除纪录,不过这是常见操作,最好还是保存成一个脚本方便以后使用:

# vi deletevm.sh
#!/bin/bash
mysql -uroot << EOF
use nova;
DELETE a FROM nova.security_group_instance_association 
 AS a INNER JOIN nova.instances AS b
 ON a.instance_id=b.id where b.uuid='$1';
DELETE FROM nova.instance_info_caches WHERE instance_id='$1';
DELETE FROM nova.instances WHERE uuid='$1';
EOF

# chmod +x deletevm.sh

8月15日更新,才过了不到一个月,OpenStack 又更改了数据库表结构和字段,上面的脚本改为:

#!/bin/bash
mysql -uroot << EOF
use nova;
DELETE FROM nova.security_group_instance_association where instance_uuid='$1';
DELETE FROM nova.instance_info_caches WHERE instance_uuid='$1';
DELETE FROM nova.instances WHERE uuid='$1';
EOF

运行脚本,比如删除 ID 为 6fc5696c-ed65-4e99-8fce-87dfc3cf36d9 的实例:

# ./deletevm.sh 6fc5696c-ed65-4e99-8fce-87dfc3cf36d9

# nova list
+--------------------------------------+--------+--------+-------------------+
|                  ID                  |  Name  | Status |      Networks     |
+--------------------------------------+--------+--------+-------------------+
| 98f5f421-581f-43d2-b1c7-f27cf5b61f02 |  c30   | BUILD  | private=10.0.0.30 |
| b768ebeb-4d73-4c31-8ec5-6bb2e90d4303 |  c63   | ERROR  | private=10.0.0.63 |
| b79e213b-055c-414f-a9f1-f230ed9aaae1 |  c95   | ERROR  | private=10.0.0.95 |
| efc6e9c7-4ef8-4350-9451-83bcfcafe101 |  c12   | ACTIVE | private=10.0.0.12 |
+--------------------------------------+--------+--------+-------------------+

旧版本的 OpenStack (Diablo) 可以参考:如何删除 OpenStack Nova 僵尸实例

迁移 VMware ESXi 上的 Windows 虚拟机到 KVM

我们发现 VMware vShpere 私有云成本太高,比如我们实验室随便一台服务器就有 512GB 内存,按照 VMware vSphere Standard(标准版)的授权我们需要 512/32=16 个授权,每个授权1293.5美元(又涨价了),1台服务器就需要约2万美元(16个授权),这个授权只是版权价格(LICENSE PRICE),还不包括每年的 1 YEAR SUPPORT & SUBSCRIPTION(419.9美元),这是在抢钱不~,今年初我们买了3个授权来评估和测试,但是按照这个授权方案只能用在2台服务器上(1台 24GB 内存,1台 64GB 内存),VMware 的产品实在不适合我们,我们打算把 VMware ESXi 上现有的一些虚拟机迁移到 OpenNebula/KVM 上。

最先迁移的是一台 Windows Server 2008 R2 虚拟机,这台虚拟机跑在 VMware ESXi 上专门用来运行 VMware vCenter Server(vCenter Server 只能安装在64位的 Windows 系统上),有些现成迁移工具比如 virt-v2v 等,不过个人还是喜欢自己动手,那些工具有时候不太好用。下面的步骤应该对其他的 Windows 版本也有效。

首先用 vShpere Client 登陆到 VMware ESXi 5.0 上打开防火墙设置,允许 ESXi 上的 ssh server 和 ssh client 可用,否则不能 ssh 登陆到 ESXi 也不能从 ESXi 上 scp 镜像到 KVM 服务器,设置具体在 Configuration > Software > Security Profile > Firewall > Properties … > SSH Client 里:

vmware esxi 5.0 enable ssh client

然后 ssh 登陆 VMware ESXi 5.0 服务器(172.16.39.100)后,scp 所需要的镜像文件(后缀名为 .vmdk)到 KVM 服务器(172.16.39.101)上

$ ssh root@172.16.39.100
Password: 
The time and date of this login have been sent to the system logs.

VMware offers supported, powerful system administration tools.  Please
see www.vmware.com/go/sysadmintools for details.

The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.

~ # scp /vmfs/volumes/localstore/vcenter/vcenter-flat.vmdk root@172.16.39.101:/root

把 VMware 的 vmdk 格式转化成 KVM 的格式,因为从 v0.12 开始 qemu-kvm 已经支持 VMware 的硬盘格式 v6 和 v7,所以这一步其实是可以省略的,换句话说 kvm 可以直接启动 vmdk 格式的虚拟机。

$ ssh root@172.16.39.101
# qemu-img convert vcenter-flat.vmdk vcenter.img

最后用 virsh create vcenter.xml 的时候记得 vcenter.xml 文件里面关于硬盘的部分是如下设置,还有记得打开 vnc 设置(别忘了 Windows 是图形界面的):

# vi vcenter.xml
...
 <disk type='file' device='disk'/>
      <driver name='qemu' type='raw'/>
      <source file='/root/vcenter.img'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    </disk>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
...
    <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
...

# virsh create vcenter.xml

Troubleshooting

如果启动 Windows 后用 vnc 客户端连接 KVM 服务器,Windows 启动过程中可能出现蓝屏 Stop 0x0000007B 错误,这是因为硬盘控制器驱动变了:

windows blue screen

解决办法是在迁移前下载 MergeIDE.zip 后解压,双击运行 MergeIDE.bat 文件,然后关闭 Windows 重新按照上面的步骤走一遍。

OneStack:Ubuntu 12.04 上一键自动部署 OpenStack

前几天 OneStack 项目 的作者 Kayven 在 vpsee.com 上留言谈到了 OneStack,一个国人的 OpenStack 一键安装工具,在 vpsee 的忽悠下 Kayven 终于同意写一篇 OneStack 的介绍性文章,如果大家对手动安装配置 OpenStack 有恐惧的话可以试试这个 OneStack 一键安装工具,类似的项目还有 DevStack.

大家如有问题欢迎参与讨论或联系原作者 Kayven (Hily.Hoo@gmail.com). 以下内容来自 Kayven:

在发表了 OneStack: Ubuntu 12.04 (“Precise”) 一键安装部署云计算平台 OpenStack Essex 这篇文章、公布了 OneStack 这个项目后,受到一些人的关注和邀请,诚惶诚恐,非常感谢大家的支持,下面将对这个项目进行更详细的介绍。

OneStack 的引入

为什么需要 OpenStack?作为众多云计算项目的一个,OpenStack 很火。

一是因为 OpenStack自身的优势、Apache2.0 授权的开源性以及兼容性、灵活性和可扩展性等优点;
二是众多企业和组织的参与开发,尤其是世界领军企业的加入,推动了 OpenStack 的高速成长。

为什么需要 OneStack?类似项目有 DevStack,但是使用 DevStack 有如下问题:

部署过错的可定制性和灵活性不是太好,自己只能选择安装哪些服务,如果中间遇到问题或者自己想调整就比较麻烦;
使用 screen 管理运行 OpenStack,重启服务器需要用 screen 进入,很多人以为有些服务会停止或者希望不使用 screen,于是自己 kill 服务并自己手动开启,容易出各种问题(OpenStack 由很多独立组件和服务组成,注意不要遗漏);
没有提供重启、重置、清空数据库等有用功能,还稍显复杂;
而且,使用 DevStack 后还是不清楚整个部署过程是怎样的,自己不能安装官方安装文档来实验和尝试;
由于组件独立分散,安装过程过于繁琐,可以抽象成通用的项目供大家方便使用;
官方提供了一个比较完善的入门文档,但是,按照这几十页的步骤下来需要做很多无用功,容易漏错而引起很多莫名和头疼的问题;
本项目希望不只是提供实验环境,更可以实际部署使用,可以自己修改配置,按需增加组件和功能,实现一键部署,可扩展、可添加任意计算节点。

为什么需要一键自动部署工具?

很多人首先希望尝试一下 OpenStack,做做实验,弄清楚具体怎么实践。官方文档的一大堆步骤会让人忘而生畏;同时又不想部署好后都不知道到底怎么做的,像 DevStack 这样封装比较难看懂,也就难自己修改。OneStack 能够很好的自动部署,同时又能灵活的实验,对于大部分尝试者是个很好的途径。

为什么使用 Ubuntu 12.04?

OpenStack 官方指定的操作系统是 Ubuntu,当然也可以使用其他的,比如 CentOS,不过安装过程有可能会不同。OpenStack 目前主要是以 Ubuntu 版本 Linux 系统为基础写成的,而且很多测试和文档都是在 Ubuntu 下完成的,所以在 Ubuntu 下部署将会有很多便利。另外,Ubuntu 12.04不仅是LTS(长期支持版本),还可以得到五年的支持,对于开发者是个不错的平台。

OneStack 的项目结构

  • oneStack.sh(一键部署 all-in-one 的 OneStack,最主要文件);
  • addComputeNode.sh(增加计算节点);
  • delStack.sh(只卸载nova、glance、keystone等);
  • delAll.sh(卸载所有安装的组件和工具);
  • resetStack.sh(清空数据库,镜像、网络和实例等);
  • addClient.sh(添加客户端,nova管理等);
  • setup_base.sh(安装基本系统);
  • setup_test.sh(添加镜像和实例);
  • HAStack 目录(OneStack 的高可用性,希望更多人可以提出自己的解决方案)。

OneStack 的安装部署

可以一键自动部署 all-in-one 的 OneStack 实验环境,也可以分步骤部署(下次再讨论分步骤部署)。
一键自动部署最简单,只需要文件 oneStack.sh 把所有服务安装到一个机器。

# wget http://onestack.googlecode.com/files/oneStack.sh && \
chmod +x oneStack.sh && ./oneStack.sh

如果需要更多功能,需要 chechout 整个 svn;当然,安装同样只需要 oneStack.sh
1、安装 Ubuntu Precise (12.04);
2、下载 OneStack 脚本:

# svn checkout http://onestack.googlecode.com/svn/trunk/ onestack-read-only

3、运行 OneStack:

# cd onestack-read-only/ && ./oneStack.sh

注意:其实上面的安装还是需要更改网络配置的(其余可以不改,这个是需要改成你自己的)因为,为了简单,在上面的工具里,所有前期工作都加到了文件 oneStack.sh,比如:

  • root 用户密码设置(刚安装的 Ubuntu 默认不启用这个 root 用户);
  • apt 源的配置,可以设置为国内的 163、ustc 的源等;
  • 网络配置,控制节点是需要外网 ip 的,你需要更改oneStack.sh里面的一些配置:/etc/network/interfaces 里面双网卡的 ip、网关等,在脚本靠前的位置,请查找 interfaces. 参数设置:外网 ip 地址等,这些也都在脚本开头一个块里面。自行检查下面 network/interfaces 的两个网卡设置:
    ## 2、自行检查下面 network/interfaces的两个网卡设置
    + OUT_IP=192.168.139.50 
    + OUT_IP_PRE=192.168.139
    ...
    
  • 选择虚拟机技术,裸机使用 kvm,虚拟机使用 qemu 即可
    ## 选择虚拟技术,裸机使用 kvm,虚拟机里面使用 qemu
    VIRT_TYPE=”qemu”
  • 数据库的安装和配置,为了自动化部署,参数设置里面设置好帐号和密码,后面就不需要交互;## 配置 /etc/nova/nova.conf,这里与控制节点的配置相同!比如ip是控制节点的ip
    MYSQL_PASSWD=${MYSQL_PASSWD:-“cloud1234”}
    NOVA_DB_USERNAME=${NOVA_DB_USERNAME:-“novadbadmin”}
    NOVA_DB_PASSWD=${NOVA_DB_PASSWD:-“cloud1234”}
  • 系统会安装 Ubuntu 12.04 的镜像,并启动一个实例。这个过程中镜像自动从 Ubuntu 官网下载,可以查找 cloud-images 更换地址或者镜像 precise-server-cloudimg-amd64-disk1.img,也可以注释掉这个步骤,直接使用 dashboard 在 web 添加镜像启动实例。这个镜像有700多 MB,对于网速不好的用户,可能需要较长时间,因此可以先下载好镜像,然后把这里的地址改成本地即可。

总结一下需要设置的参数:

  • 设置 root 密码这一步可以删掉,使用 root 执行即可;
  • 可选,如果不需要跳过本步骤
    系统语言设置,可以参考oneStack.sh locale部分,不在此介绍
    设置apt源 /etc/apt/sources.list
  • 设置网络
    /etc/network/interfaces
    可以参考oneStack.sh locale部分
  • 配置参数,除了网络ip,其它可以不变
    ## 数据库
    MYSQL_PASSWD=${MYSQL_PASSWD:-“cloud1234″}
    ## 自行检查下面network/interfaces的两个网卡设置与此处一致
    OUT_IP=”192.168.139.50″
    ## 选择虚拟技术,裸机使用kvm,虚拟机里面使用qemu
    VIRT_TYPE=”qemu”
    ## token, 登录dashboard密码
    ADMIN_TOKEN=”admin”
  • 然后执行./oneStack.sh安装即可。

OneStack 的展望

1、加入高可用性 OpenStack 的部署
详见构建 OpenStack 的高可用性(HA,High Availability)对高可用性OpenStack的讨论。对照 CAP 理论,OpenStack 的分布式对象存储系统 Swift 满足了可用性和分区容忍性,没有保证一致性(可选的),只是实现了最终一致性。对于 Swift 的研究和学习网上很多,我不做介绍。但是,在整个 OpenStack 架构中,要满足高可用性需要进行很多工作来保证。主要是通过分离、冗余技术实现,也就是 nova-api、nova-network、glance 等可以分别在多节点上工作,RabbitMQ 可以工作在主备模式,MySQL 可以使用冗余的高可用集群。这些组合可能有很多问题,有些也需要加入到 OpenStack 项目。

2、加入对 Ubuntu 以外的操作系统(如 CentOS)的支持
个人精力有限,所以没有对 CentOS 等其它版本进行支持,也没有对 Ubuntu11 等版本进行测试。但是大家应该只需要把 OneStack 稍加改动就可以用到这些版本的操作系统。因此,如果有人有改好的,可以拿出来分享,别人也也可以顺便帮你改善和讨论。

3、希望更多的有时间的同行参与
正如上面所说,个人精力有限,业余所做,肯定有诸多不足,而且对其它版本没有添加支持,更主要的,希望对高可用性(HA)这个很关键的要求实现自动化部署,因此希望多提出意见建议、多分享自己的经验和成果,造福别人也提高自己。

在 KVM 上访问 FreeBSD 虚拟机终端

在移植旧的物理服务器到虚拟机的时候还剩一些非 Linux 系统没有移,主要是 FreeBSD 和 Solaris 系统,还有几台 OpenBSD 的,这些系统大部分运行在很古老的机器上,有的甚至比我的 FreeBSD on IBM TP600E 还老,需要问一下管理员这些机器在干嘛,是否能合并到虚拟机,管理员刚好这周请假去了 WWDC 现场。

提到今年的 WWDC,看完发布会视频又要扯一下了,比较激动的是那个 2880×1800 屏幕的 MacBook Pro,码农实在太需要关怀了,任何每天看电脑8小时以上的人都需要好显示器,Life is short,对自己好点,Get a Mac:)

做了 FreeBSD for KVM 的镜像以后需要能在 KVM 上像访问 Linux 虚拟机终端那样访问 FreeBSD 的虚拟机终端,步骤和在 Linux 上差不多。

在 FreeBSD Guest 上配置

登陆 FreeBSD 后添加和编辑 loader.conf 文件:

# vi /boot/loader.conf
console="comconsole"

在 /etc/ttys 最后加上 ttyd0 一行:

# vi /etc/ttys
...
# Serial terminals
#ttyu0   "/usr/libexec/getty std.9600"   dialup   off secure
ttyu0   "/usr/libexec/getty std.9600"   vt100   on secure
...

重启 FreeBSD:

# reboot

确定 virsh edit 有下面这几行:

# virsh edit freebsd
...
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
...

必要时重启 libvirtd:

# /etc/init.d/libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]

freebsd console on kvm

在 KVM 上访问 Linux 虚拟机终端

用 OpenNebula 制作 Ubuntu 镜像后可以用这个镜像当作模版来创建 OpenNebula 虚拟机,发现一个问题是,这个 KVM 虚拟机(guest)无法在母机(host)上用 virsh console 登陆和显示终端,这是因为那个模板没有引入 console 需要的参数,而且虚拟机里面也没有做相关的设置。解决办法分两步,首先登陆到虚拟机修改一些配置;然后在运行这个虚拟机的 KVM 节点(host)上修改虚拟机的 xml 配置文件。以下介绍虚拟机是 Ubuntu 和 CentOS 的两种配置情况,FreeBSD 配置情况可以参考:在 KVM 上访问 FreeBSD 虚拟机终端

在 Ubuntu Guest 上配置

登陆 ubuntu 虚拟机增加 ttyS0.conf 文件及其内容:

$ sudo vi /etc/init/ttyS0.conf
# ttyS0 - getty
#
# This service maintains a getty on ttyS0 from the point the system is
# started until it is shut down again.
start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]
respawn
exec /sbin/getty -L 38400 ttyS0 vt102

如果不只是希望 Linux login 后看到终端,也希望看到 Linux 的启动过程的话需要在 /etc/default/grub 加入 GRUB_CMDLINE_LINUX 一行,记得运行 update-grub2 自动配置 grub:

$ sudo vi /etc/default/grub
...
GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0"
...

$ sudo update-grub2

在 CentOS Guest 上配置

在 /etc/securetty 文件末尾追加 ttyS0 一行:

# echo “ttyS0″ >> /etc/securetty

在 /etc/grub.conf 文件里的 kernel 一行增加 console=ttyS0:

# vi /etc/grub.conf
...
title CentOS (2.6.32-220.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-220.el6.x86_64 ro root=/dev/mapper/VolGroup-lv_roo
ot rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarr
cyrheb-sun16 rhgb crashkernel=auto quiet rd_LVM_LV=VolGroup/lv_root  KEYBOARDTYPP
E=pc KEYTABLE=us rd_NO_DM console=ttyS0
        initrd /initramfs-2.6.32-220.el6.x86_64.img
...

在 /etc/inittab 中增加 ttyS0 一行:

# vi /etc/inittab
...
S0:12345:respawn:/sbin/agetty ttyS0 115200

在 KVM Host 上配置

登陆 KVM 母机(host)用 virsh edit 修改虚拟机的 KVM 启动配置文件,在 device 下面加上 serial 一栏:

# virsh list
Id Name State
----------------------------------
49 one-28 running

# virsh edit one-28
...
<device>
...
    <serial type='pty'>
        <target port='0'/>
    </serial>
    <console type='pty'>
        <target type='serial' port='0'/>
    </console>
...
</devices>

修改后重启 libvirtd,并手动关闭和启动虚拟机:

# /etc/init.d/libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]

# virsh shutdown one-28
# virsh start one-28

在 CentOS 6.2 上安装和配置 Foreman

服务器(物理机器和虚拟机)多了以后需要工具来管理,经常登陆系统后不知是在虚拟机上还是在物理机上?如果在虚拟机上这个虚拟机运行在哪个服务器节点(host)上?如果在物理机上运行在什么配置的物理机上?运行在 Dell 刀片服务器上还是 IBM 超级计算机上,SUN 服务器上还是普通 PC 上?这个系统 IP 是多少?域名是啥?有几个网卡?分别走的哪个交换机?有没有连到 SAN 存储等等?无数问题,我们需要一个统一查看和管理所有机器(物理机和虚拟机)的这么一套工具。Foreman 就是这么一个集成了 Puppet 的统一机器生命周期管理工具。

Foreman 功能很强大,可以解决硬件或虚拟机上线到运行 Puppet 之间的一切问题,比如安装操作系统、配置网络、配置 DNS、Puppet 客户端安装认证等等,完成必要的上线工作后,Foreman 就把剩下的工作交给了 Puppet,Puppet 完成剩下的服务器和服务配置工作,这样就完美的完成了从服务器上线到服务上线的全过程,而且是自动的。这里主要介绍用 Foreman 获取(配合 Puppet Facts)和查看服务器信息。

加入 foreman 官方源后安装软件包:

# cat > /etc/yum.repos.d/foreman.repo << EOF
[foreman]
name=Foreman Repo
baseurl=http://yum.theforeman.org/stable
gpgcheck=0
enabled=1
EOF

# yum install foreman

拷贝 foreman 里面的 report 例子到 puppet 下,并更改 $foreman_url 指向这台安装 foreman 的服务器:

# cp /usr/share/foreman/extras/puppet/foreman/templates/foreman-report.rb.erb \
/usr/lib/ruby/site_ruby/1.8/puppet/reports/foreman.rb

# vi /usr/lib/ruby/site_ruby/1.8/puppet/reports/foreman.rb
...
$foreman_url='http://foreman.vpsee.com:3000/'
...

配置 puppetmaster 服务端,编辑 puppet.conf 配置文件:

# vi /etc/puppet/puppet.conf
[main]
...
    reports=log, foreman
...

# /etc/init.d/puppetmaster restart

配置 puppet 客户端,编辑 puppet.conf 配置文件,确保 report 是 true:

# vi /etc/puppet/puppet.conf
...
report = true
...

初始化 foreman 数据库(这里 foreman 默认使用 sqlite,简单、不用任何配置,如果想用 mysql 的话可以参考官方帮助文件):

# cd /usr/share/foreman
# RAILS_ENV=production rake db:migrate

启动 foreman:

# /etc/init.d/foreman start

我们把 foreman 和 puppetmaster 安装在同一个机器上,每次运行这个脚本都会导入新的 facts:

# cd /usr/share/foreman
# rake puppet:import:hosts_and_facts RAILS_ENV=production
(in /usr/share/foreman)
Importing from /var/lib/puppet/yaml/facts
Importing monitor.vpsee.com
Importing dev.vpsee.com
Importing intranet.vpsee.com
Importing datasrv.vpsee.com
Importing rocket.vpsee.com
Importing grid.vpsee.com
Importing proxy.vpsee.com
Importing mail.vpsee.com

导入成功后打开浏览器访问 http://foreman.vpsee.com:3000 就可以看到 foreman 界面了:
foreman

修改 OpenNebula 虚拟机实例的内存大小

OpenNebula 创建虚拟机(实例)以后将不能直接更改虚拟机的配置参数,如 CPU、内存等。如果创建虚拟机以后发现内存给的太大,想改小怎么办呢?如何给 OpenNebula 上的虚拟机修改内存呢?(注:OpenNebula 没有直接操作的命令,需要到节点上用 virsh setmem 动态修改。)让人不可思议的是,OpenNebula 推荐的方法是删除原有虚拟机以后重新创建一个配置合适的虚拟机,一些云计算平台认为虚拟机(计算资源)应该像自来水一样打开就用,不用就关闭。个人觉得云计算应该至少能随时改变计算资源(配置),而不是删除+创建。

比如下面这个 id 为28的虚拟机实例用了 2GB 内存,想修改到 1GB:

# onevm list
ID USER     GROUP    NAME         STAT CPU     MEM        HOSTNAME        TIME
...
14 root     oneadmin queue        runn   3      1G         cloud06 40 20:38:50
18 root     oneadmin grid03       runn 144     24G         cloud18 39 00:47:01
19 root     oneadmin grid02       runn 143     32G         cloud21 39 00:26:26
28 root     oneadmin monitor      runn   9      2G         cloud03 05 22:04:14
...

首先找到这个28号虚拟机实例所在的 OpenNebula 计算节点(node),从上面的 HOSTNAME 看出 monitor 运行在 cloud03 这个节点上,我们 ssh 到这个节点操作发现这台 OpenNebula ID 为28的虚拟机实例在这个节点上名字为 one-28:

# ssh root@cloud03

# virsh list
 Id Name                 State
----------------------------------
 39 one-20               running
 42 one-25               running
 45 one-28               running

可以动态修改 one-28 的内存参数为 1GB,但是这种办法重启后就会丢失配置重回到 2GB:

# virsh setmem one-28 1048576

所以最好关闭 one-28 后再修改 one-28 配置文件,改动 memory 部分为 1048576(1GB),修改完毕后启动虚拟机:

# virsh shutdown one-28

# virsh edit one-28
...
1048576
...

# virsh start one-28

修改完后 onevm list 会发现 one-28 内存大小依然是 2GB,没有变,这是因为这部分纪录在 OpenNebula 的数据库里,需要修改数据库,先 select 一下发现 OpenNebula 把 VM 的 XML 配置文件写在数据库里,这容易办,用 SQL 语句的 update 操作更新一下数据库:

# sqlite3 /var/lib/one/one.db

sqlite> select * from vm_pool where oid='28';
28|monitor|...2097152...|0|0|1337014904|3|3|1|0|0

sqlite> update vm_pool set body="...1048576..." where oid="28";

然后 onevm list 就会得到正确的、修改过内存的虚拟机实例了:

# onevm list
ID USER     GROUP    NAME         STAT CPU     MEM        HOSTNAME        TIME
...
14 root     oneadmin queue        runn   3      1G         cloud06 40 23:44:51
18 root     oneadmin grid03       runn 144     24G         cloud18 39 03:47:01
19 root     oneadmin grid02       runn 143     32G         cloud21 39 03:32:27
28 root     oneadmin monitor      runn   9   1024M         cloud03 05 01:10:15
...