标签：openstack ceph

一、 从开始到现在遇到的各种问题 

    1.1、单网卡下搭建openstack出错 

    1.2、云平台上虚机搭建MDS系统遇到的问题 2

        1.2.1、内部网路和外部网络的联通问题 3

        1.2.2、windows虚机下对于3D的支持问题 5

        1.2.3、对于windows的兼容问题 5

    1.3、扩展节点的部分问题 5

        1.3.1.、扩展节点出错 5

        1.3.2、删除扩展节点信息 7

    1.4、虚机建成后分区以及访问速度问题 7

    1.4.1、分区问题 7

    1.4.2、访问速度问题 10

    1.5、在迁移云主机测试出错以及原因 10

    1.6、物理机硬件异常引起的openstack系统的出错 11

    1.7、选择的flavor不当产生的问题 11

二、 日常工作汇集 11

    2.1、迁移总汇 11

        2.1.1、在虚机的环境下的云主机迁移 11

    2.2、物理机环境下的云主机迁移 13

        2.2.1、物理机在系统关闭防火墙后出现异常 13

        2.2.2、把原来集群的云主机冷迁移到新创建的集群一 15

        2.2.3、把原来集群的云主机冷迁移到新创建的集群二 16

    2.3、Ceph测试前升级系统内核 17

        2.3.1、升级内核出现的问题一 17

        2.3.2、升级内核出现的问题二 20

        2.3.3、正确的方式升级内核 22

    2.4、升级完内核后搭建ceph集群 23

        2.4.1、配置主机名 23

        2.4.2、配置hosts文件 23

        2.4.3、配置本地YUM源 24

        2.4.4、在deploy节点升级并安装部署工具 25

        2.4.5、ntp服务 25

        2.4.6、创建用户 25

        2.4.7、无密码访问 26

        2.4.8、防火墙和selinux 28

        2.4.9、部署 30

    2.5、LVM分区格式下扩展系统根分区 36

三、 注意事项 39

    3.1、挂载目录是需要注意的事项 39

四、 命令汇总 40

    4.1、openstack命令汇总 40

    4.2、硬件相关命令 41

    4.3、虚拟化相关的命令 41

五、 实验 42

    5.1、迁移实验 42

        1）暂停云主机 42

        2）ssh登录YUN-12主机 42

        3）ssh登录YUN-11主机修改数据库 42

        4）结果验证 42

六、 问题 46

一、从开始到现在遇到的各种问题

1.1、单网卡下搭建openstack出错

刚开始把openstack的YUM源下载到本地搭建了本地的YUM服务器，搭建openstack环境是在vmware虚拟机下搭建的，用了一块网卡，结果在安装环境的时候老是报错，后来有添加了一块网卡，在packstack-answer文件中在进行配置后就解决了这个报错问题。

1.2、云平台上虚机搭建MDS系统遇到的问题

（主要是MDS测试系统）

在云平台上为客户创建数台虚拟机，客户在搭建测试系统后发现服务连接有问题，端口连接不上。

1.2.1、内部网路和外部网络的联通问题

例如下面所示情况：

虚拟机搭建的BPM服务器 10.0.0网段的IE无法正常查看工作流状态。另外一台mds应用要通过ip+port加载IP位192.168.050虚机上的bpm应用 ，加载不上。

问题说明：

一般情况下，在虚机有两个网络，一个是内部的网络，一个是外部访问的浮动IP，在部署MDS集群系统的时候，都是填写内部的地址，以及内部配置的监听端口也是外部的地址，比如在本MDS系统中就是10.0.0的地址，但是开启端口，例如本系统就是192.168.0的网络。

在外部可以使用下面的命令来测试相应的端口是否可以访问

python -m SimpleHTTPServer 端口

curl 地址端口

下面举两个实际遇到问题后的解决例子：

一个是weblogic的配置文件

如下所示

  <server>

    <name>MDSServer3</name>

    <listen-port>9010</listen-port>

    <cluster>MDSCluster</cluster>

    <listen-address></listen-address>

    <jta-migratable-target>

      <user-preferred-server>MDSServer3</user-preferred-server>

      <cluster>MDSCluster</cluster>

    </jta-migratable-target>

  </server>

  <server>

    <name>MDSAppServer1</name>

    <ssl>

      <enabled>false</enabled>

    </ssl>

    <machine xsi:nil="true"></machine>

    <listen-port>8010</listen-port>

    <cluster>MDSCluster</cluster>

    <listen-address>10.10.0.39</listen-address>

    <jta-migratable-target>

      <user-preferred-server>MDSAppServer1</user-preferred-server>

      <cluster>MDSCluster</cluster>

    </jta-migratable-target>

  </server>

  <server>

    <name>MDSAppServer2</name>

    <ssl>

      <enabled>false</enabled>

    </ssl>

    <machine xsi:nil="true"></machine>

    <listen-port>9010</listen-port>

    <cluster>MDSCluster</cluster>

    <listen-address>10.10.0.40</listen-address>

    <jta-migratable-target>

      <user-preferred-server>MDSAppServer2</user-preferred-server>

      <cluster>MDSCluster</cluster>

    </jta-migratable-target>

  </server>

  <cluster>

    <name>MDSCluster</name>

    <cluster-address>192.168.0.52:7010,192.168.0.52:8010,192.168.0.52:9010,192.168.0.55:8010,192.168.0.56:8010</cluster-address>

    <multicast-address>239.192.0.0</multicast-address>

  </cluster>

在上面所举的例子中标记为红色的配置的是内部地址，第一个没有配置地址，说明是让系统自己选定。标记为蓝色的是外部访问的地址，在外部需要在浏览器中填写这些地址去访问虚机内部的服务。

虽然原理是这样的，但是在开篇提到的问题还是无法通过这种方法解决。

另一个例子也可以这样描述：

虚拟机搭建的FTP不支持营销接口上传文件。

下面是vsftpd.conf的部分修改配置

#解决小网ftp不能启用被动模式

port_enable=YES

connect_from_port_20=YES

pasv_enable=YES

pasv_min_port=10020

pasv_max_port=10040

pasv_address=192.168.0.55

#10.10.0.39

上面的绝大部分是添加的内容，除了最后一条加了注释让其失效，这个也是典型的访问地址为外部地址的案例。

1.2.2、windows虚机下对于3D的支持问题

虚拟机搭建的3D工作站IE无法正常查看：

新建的win7镜像做成的虚机，在安装Unit Web Player工具之后，还是无法在浏览器中显示MDS系统中的3D工作站，但是在物理机下完全没有问题。

1.2.3、对于windows的兼容问题

在openstack中的win2008虚机中安装vmware workstation虚拟机，win2008系统出现蓝屏。

迁移过后的windows虚机会遇到各种各样的问题

1.3、扩展节点的部分问题

1.3.1.、扩展节点出错

出错信息：

192.168.0.11_keystone.pp:                         [ ERROR ]         

Applying Puppet manifests                         [ ERROR ]

ERROR : Error appeared during Puppet run: 192.168.0.11_keystone.pp

Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[admin]: Could not evaluate: Execution of '/usr/bin/keystone --os-auth-url http://127.0.0.1:35357/v2.0/ token-get' returned 1: The request you have made requires authentication. (HTTP 401)

You will find full trace in log /var/tmp/packstack/20150209-133712-oZcG_v/manifests/192.168.0.11_keystone.pp.log

Please check log file /var/tmp/packstack/20150209-133712-oZcG_v/openstack-setup.log for more information

原因：

在dashboard修改登录秘密没有在配置文件修改

解决办法：

vi packstack-answers-20150130-201639.txt

CONFIG_KEYSTONE_ADMIN_PW=hndlyptl

一般情况下不在answer文件中修改云平台登录密码的话都会出现一大串的英文单词拼凑密码

对于修改登录密码也有另外的状况，例如以下所示

三个计算节点YUN-13、YUN-14和YUN-15不通

排错

# vi /etc/openstack-dashboard/local_settings

#DEBUG = False

DEBUG = True

TEMPLATE_DEBUG = DEBUG

[root@YUN-11 ~]# nova --debug list

DEBUG (shell:783) You must provide a username via either --os-username or env[OS_USERNAME]

Traceback (most recent call last):

  File "/usr/lib/python2.6/site-packages/novaclient/shell.py", line 780, in main

    OpenStackComputeShell().main(map(strutils.safe_decode, sys.argv[1:]))

  File "/usr/lib/python2.6/site-packages/novaclient/shell.py", line 610, in main

    raise exc.CommandError(_("You must provide a username "

CommandError: You must provide a username via either --os-username or env[OS_USERNAME]

ERROR: You must provide a username via either --os-username or env[OS_USERNAME]

解决办法:

在dashboard中，点击【项目】-【compute】-【访问&安全】-【下载openstack RC文件】

把下载的文件上传到YUN-11的~/目录下

修改下载的文件

[root@YUN-11 ~]# vi admin-openrc.sh

修改登录密码

export OS_PASSWORD=hndlypt

新建一个文件，把上边文件的内容复制到该文件

[root@YUN-11 ~]# vi openrc

# source openrc

之后就可以了

1.3.2、删除扩展节点信息

问题描述：

现有一台物理机，这台物理机在云平台中是一个计算节点，某一天这台要把这台物理机撤掉，但是在撤掉这台物理机后在云平台的dashboard中还可以看到这台物理机的信息，如何删除这些信息呢？

删除这些信息需要在数据库中删除

首先查看物理机的主机名对应的信息

#mysql> select id,service_id,host_ip from compute_nodes;

依照对应信息删除

#mysql> delete from compute_nodes where id=4;

#mysql> delete from services where host='YUN-14';

1.4、虚机建成后分区以及访问速度问题

1.4.1、分区问题

在虚机建好后会发现缺少swap分区，而且给定的空间都没有分配，我一般会把分配的磁盘空间挂到/home分区下。

我们一般会创建swap分区和分配空间到/home

进入虚机查看一般会是这种分区情况

[root@host-10-10-0-2 ~]# fdisk -l

Disk /dev/vda: 214.7 GB, 214748364800 bytes

255 heads, 63 sectors/track, 26108 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x0008ffc5

   Device Boot      Start         End      Blocks   Id  System

/dev/vda1   *           1        1306    10484736   83  Linux

[root@host-10-10-0-2 ~]# df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/vda1             9.9G  2.2G  7.2G  23% /

tmpfs                 7.8G     0  7.8G   0% /dev/shm

--------------

新增交换分区

--------------

如果16G内存，分配16G交换分区

#fdisk /dev/vda

主要命令

d 删除分区

n 新增主分区、扩展分区、逻辑分区

p 显示分区

t 转换分区格式

w 保存分区表

Command(m for help):n

增加主分区，因为扩展分区不能作为交换分区

分区大小除了开始结束范围，还可以用 +16G这种方式表示。

Command(m for help):t

82表示交换分区id

Command(m for help):w

保存退出

#partprobe

更改分区表马上生效

如果系统没有此命令，重启计算机。

#mkswap /dev/vda2

将/dev/vda2分区格式化为交换分区

#swapon /dev/vda2

挂载交换分区

#swapoff /dev/vda2

卸载交换分区

[root@host-10-10-0-2 ~]# free

             total       used       free     shared    buffers     cached

Mem:      16332544     256196   16076348          0       6440      42460

-/+ buffers/cache:     207296   16125248

Swap:     33556428          0   33556428

查看交换分区设置成功

#vi /etc/fstab

修改分区表自动挂载swap分区

新增一行

/dev/vda2 swap swap defaults 0 0

---------------

新增home分区

---------------

#fdisk /dev/vda

新增扩展分区，新增逻辑分区

#mkfs.ext4 /dev/vda5

格式化分区

#vi /etc/fstab

修改分区表

新增

/dev/vda5            /home             ext4    defaults        0 2

最后一个2是pass选项

pass选项

0 不会被fsck utility检查

1 root用户应该有最高优先权

2 如果你想被check就选择2

重启系统

#reboot

1.4.2、访问速度问题

通过工具把外部的工具上传到虚机中以及在虚机中访问服务等一些操作，发现这些操作比较慢，后来通过上网收集解决方法和实验最终解决。

因为采用GRE网络，你需要把MTU设置为1400，默认的是1500，文档可参考

https://ask.openstack.org/en/question/6140/quantum-neutron-gre-slow-performance/

【在控制节点】

编辑 /etc/neutron/dhcp_agent.ini

dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf

创建一个 /etc/neutron/dnsmasq-neutron.conf

dhcp-option-force=26,1400

重启服务

service neutron-dhcp-agent restart

在控制节点以及各个云主机上

ethtool -K eth2 tso off

ethtool -K eth2 gro off

在各云主机上注意网卡的不同，各云主机网卡为eth0或者eth1抑或是其他，视情况而定

1.5、在迁移云主机测试出错以及原因

提示信息：

error: unable to connect to server at '192.168.0.11:16509': No route to host

#virsh

virsh # connect qemu+tcp://192.168.0.11/system

error: Failed to connect to the hypervisor

error: unable to connect to server at '192.168.0.11:16509': No route to host

排错：

定位出错是因为防火情策略的问题

修改之前的防火墙配置，如迁移总汇里边所配置的那样。

1.6、物理机硬件异常引起的openstack系统的出错

机器异常（YUN19服务器电源开关下面的指示灯亮红灯）

发现YUN19无法进入openstack dash界面，PING不通。

物理机器没任何反应，重启发现PING不通外边网络，没有IP地址

重启网路服务，发现可以PING通外网

解决办法：

进入dash，出错，页面提示“错误，刷新，请联系管理员”

在YUN19节点检查openstack服务

发现neutron服务是关闭状态

然后执行 service neutron-server restart

再次进入dash，正常

1.7、选择的flavor不当产生的问题

YUN-11的集群上创建实例失败

dash提示如下所示：

错误： 创建实例 "test-22" 失败: 请稍后再试 [错误: No valid host was found. Exceeded max scheduling attempts 3 for instance ef6101b9-8b17-46b1-83f2-29201d0fa17a].

原因：

实例选择的flavor太小

二、日常工作汇集

2.1、迁移总汇

2.1.1、在虚机的环境下的云主机迁移

在vmware workstation创建多台linux虚机，在这几台虚机中搭建openstack环境，然后做云主机的迁移实验。

例如下面的实验：

操作主机

主机IP  主机名    角色

192.168.0.11    YUN-11            控制节点

192.168.0.12    YUN-12            扩展节点

下面以控制节点为例，但是每台涉及迁移的主机都要做操作

1）各节点之间nova账号无密码访问

1.1）在各个需要相互无密码访问节点上做以下操作

# usermod -s /bin/bash nova

# su nova

$ cd

$ ssh-keygen

$ touch .ssh/authorized_keys

1.2）、把其他节点的公钥拷贝过来，追加到本地的认证文件中

以控制节点为例

$ scp root@192.168.0.12:/var/lib/nova/.ssh/id_rsa.pub .

$ cat id_rsa.pub >> .ssh/authorized_keys

$ scp root@192.168.0.126:/var/lib/nova/.ssh/id_rsa.pub .

$ cat id_rsa.pub >> .ssh/authorized_keys

之后两个扩展节点就能够利用nova用户无密码访问控制节点了

依照这种方法在其他节点做类似操作，最终就会实现各节点之间nova用户的无密码访问

2）【可选，确认即可】网上文档上做了修改，但是本集群按默认配置

如果希望可以在Dashboard里设置root的密码

inject_password=true

修改虚拟机配置，不需要迁移

allow_resize_to_same_host=true

（可选）

迁移和修改配置，不需要手工确认,1表示1秒的时间让你确认，如果没确认就继续

resize_confirm_window=1

重启服务

service openstack-nova-compute restart

3）热迁移（block-migration）

3.1）所有的节点上修改nova.conf

live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_UNSAFE

开启热迁移功能

3.2）【确认即可，此处也按系统默认配置】

然后需要配置versh免密码连接，修改/etc/libvirt/libvirtd.conf

去掉注释

listen_tls = 0

listen_tcp = 1

去掉注释并修改值

auth_tcp = “none” # 注意这里必须设为none，否则需要认证。

测试下：

 virsh --connect qemu+tcp://192.168.0.12/system list

如果不需要输入用户名和密码就能够列出所有的虚拟机，则表示配置成功。

重启所有计算节点nova-compute libvirt-bin服务

此时就可以使用novaclient命令进行迁移，比如要把vm1从测试机迁移到YUN-12,则

nova live-migration --block-migrate vm1 YUN-12

注意选项--block-migrate是必要的，否则默认以共享存储的方式迁移，另外需要在控制节点做/etc/hosts文件主机名和IP的解析

4）测试迁移

测试之前关闭两台虚机系统的防火墙

在虚机的环境下测试迁移和物理机下不同在于，以上步骤在虚机下就可以完成迁移了，整个云平台也没有问题，但是在物理机下还需要做额外的配置，物理机系统中防火墙不能关闭。

另外一点就是在虚机环境中云平台在做云主机增加资源的操作和物理环境也有不同，虚机环境下增加和减除资源都可以做到，而在物理机环境下只能做到增加云主机资源。

2.2、物理机环境下的云主机迁移

2.2.1、物理机在系统关闭防火墙后出现异常

在物理机平台上的openstack云平台，在控制节点关闭系统防火墙后，计算节点上都无法创建云主机，这时候就需要打开防火墙，重启物理机，转而选择在防火墙配置文件中添加策略的方式。

另外selinux也需要关闭，修改/etc/sysconfig/selinux

SELINUX=enforcing

to

SELINUX=disable

在虚机环要下面的配置就可以了，编境下修改防火墙只需辑/etc/sysconfig/iptables

添加

-A INPUT -p tcp -m multiport --port 16509 -m comment --comment "libvirt" -j ACCEPT

-A INPUT -p tcp -m multiport --port 49152:49216 -m comment --comment "migraton" -j ACCEPT

但是在物理机环境下需要做下面的配置，在防火墙配置文件中做修改

修改之前的状态

YUN-11防火墙

-A INPUT -s 192.168.0.11/32 -p tcp -m multiport --dports 5900:5999,16509 -m comment --comment "001 nova compute incoming nova_compute" -j ACCEPT

-A INPUT -s 192.168.0.11/32 -p tcp -m multiport --dports 16509,49152:49215 -m comment --comment "001 nova qemu migration incoming nova_qemu_migration_192.168.0.11_192.168.0.11" -j ACCEPT

YUN-12防火墙

-A INPUT -s 192.168.0.11/32 -p tcp -m multiport --dports 5900:5999,16509 -m comment --comment "001 nova compute incoming nova_compute" -j ACCEPT

-A INPUT -s 192.168.0.12/32 -p tcp -m multiport --dports 16509,49152:49215 -m comment --comment "001 nova qemu migration incoming nova_qemu_migration_192.168.0.12_192.168.0.12" -j ACCEPT

做修改

YUN-11防火墙配置需要添加

-A INPUT -s 192.168.0.12/32 -p tcp -m multiport --dports 16509,49152:49215 -m comment --comment "001 nova qemu migration incoming nova_qemu_migration_192.168.0.11_192.168.0.12" -j ACCEPT

YUN-12防火墙配置需要添加

-A INPUT -s 192.168.0.11/32 -p tcp -m multiport --dports 16509,49152:49215 -m comment --comment "001 nova qemu migration incoming nova_qemu_migration_192.168.0.12_192.168.0.11" -j ACCEPT

依照上面的实例，如果有其他的物理机的话则需根据实际情况添加策略。

2.2.2、把原来集群的云主机冷迁移到新创建的集群一

查看镜像信息

[root@YUN-11 51222f9c-5074-440d-92c6-fccaeadc8032_resize(keystone_admin)]# qemu-img info disk

image: disk

file format: qcow2

virtual size: 1.0G (1073741824 bytes)

disk size: 868K

cluster_size: 65536

backing file: /var/lib/nova/instances/_base/87ae9a3ca6476837c0cb656bd99ee1dcca238134

[root@YUN-11 51222f9c-5074-440d-92c6-fccaeadc8032(keystone_admin)]# ll

total 1508

-rw-rw----. 1 root root   16618 Apr 23 10:01 console.log

-rw-r--r--. 1 root root 1572864 Apr 23 14:08 disk

-rw-r--r--. 1 nova nova      79 Apr 23 10:01 disk.info

-rw-r--r--. 1 nova nova    1634 Apr 23 10:01 libvirt.xml

[root@YUN-11 51222f9c-5074-440d-92c6-fccaeadc8032(keystone_admin)]# chmod o+r console.log

[root@YUN-11 51222f9c-5074-440d-92c6-fccaeadc8032(keystone_admin)]# ll

total 1508

-rw-rw-r--. 1 root root   16618 Apr 23 10:01 console.log

-rw-r--r--. 1 root root 1572864 Apr 23 14:08 disk

-rw-r--r--. 1 nova nova      79 Apr 23 10:01 disk.info

-rw-r--r--. 1 nova nova    1634 Apr 23 10:01 libvirt.xml

# su nova

[nova@YUN-11 instances(keystone_admin)]$ cp -r 51222f9c-5074-440d-92c6-fccaeadc8032 51222f9c-5074-440d-92c6-fccaeadc8032_resize

[nova@YUN-11 instances(keystone_admin)]$ cd 51222f9c-5074-440d-92c6-fccaeadc8032_resize

[nova@YUN-11 51222f9c-5074-440d-92c6-fccaeadc8032_resize(keystone_admin)]$ ls -la

total 900

drwxr-xr-x. 2 nova nova    4096 Apr 23 16:35 .

drwxr-xr-x. 8 nova nova    4096 Apr 23 16:35 ..

-rw-r--r--. 1 nova nova   16618 Apr 23 16:35 console.log

-rw-r--r--. 1 nova nova 1572864 Apr 23 16:35 disk

-rw-r--r--. 1 nova nova      79 Apr 23 16:35 disk.info

-rw-r--r--. 1 nova nova    1634 Apr 23 16:35 libvirt.xml

这个过程最后的结果貌似没有记录，，有待以后测试

2.2.3、把原来集群的云主机冷迁移到新创建的集群二

另一种冷迁移方式类似于vmware workstation中虚拟机的迁移一样

实例处理：

实例选择linux的系统，在系统中

创建目录、编辑文件，迁移后查看创建的目录和修改的文档是否正常

迁移之前关闭要迁移的实例

查看实例所在目录下的文档信息

[root@YUN-17 2dccde39-31a4-48d5-8f62-0f963ffec481_copy]# ll

total 6896

-rw-r-----. 1 root root       1 Apr 30 10:18 console.log

-rw-r--r--. 1 root root 7536640 Apr 30 10:18 disk

-rw-r--r--. 1 root root      79 Apr 30 10:18 disk.info

-rw-r--r--. 1 root root    1635 Apr 30 10:18 libvirt.xml

[root@YUN-17 2dccde39-31a4-48d5-8f62-0f963ffec481_copy]# qemu-img convert -O qcow disk disk4

把镜像disk4拷贝到YUN-11上（YUN-11是YUN-17所在集群的控制节点）

添加镜像

[root@YUN-11 ~(keystone_admin)]# glance add name=test-26 is_public=true container_format=bare disk_format=raw < /root/disk4

Added new image with ID: 3573cf89-7697-48cd-b07c-51344f416156

在dash中从test-26镜像启动一个云主机

启动成功，之后进入该系统的控制台，发现主机中的目录和文件保存完整

如果出现在绑定浮动IP后云主机PING不通的现象，如下面所示：

从镜像test-27启动的实例在绑定浮动ip后，发现外部的机器PING不通

解决办法：

进入实例发现网卡是eth1，但是网卡配置文件时ifcfg-eth0，配置文件中没有MAC和IP的信息，只是BOOTPROTO=dhcp

对比正常的实例

正常的实例网卡是eth0,网卡配置文件是ifcfg-eth0，配置文件也中没有MAC和IP的信息，只是BOOTPROTO=dhcp

另外发现使用cirros镜像的实例所做的迁移，没有出现这样的情况，在绑定浮动IP后，外部机器可以PING通

所做处理

在test-27实例上，修改网卡配置文件

mv ifcfg-eth0 ifcfg-eth1

修改文件参数

vi ifcfg-eth1

DEVICE=eth0

to

DEVICE=eth1

保存修改后重启网络

发现外部机器可以ping通该实例

2.3、Ceph测试前升级系统内核

2.3.1、升级内核出现的问题一

升级内核步骤如下

查看现在系统的内核参数

[root@YUN-15 ~]# uname -r

2.6.32-431.el6.x86_64

上传内核源码包linux-3.19.3.tar.xz

解压

# tar -Jxvf linux-3.19.3.tar.xz -C /usr/src

安装需要的组件

# yum install -y gcc

# yum install -y ncurses ncurses-devel

# yum install -y bc

调整参数

# make menuconfig

编译安装

# make

# make modules_install install

异常：

sh ./arch/x86/boot/install.sh 3.19.3 arch/x86/boot/bzImage \

System.map "/boot"

ERROR: modinfo: could not find module ipt_MASQUERADE

ERROR: modinfo: could not find module iptable_nat

ERROR: modinfo: could not find module crc_t10dif

ERROR: modinfo: could not find module scsi_tgt

修改启动项

# vi /boot/grub/grub.conf

default=1

to

default=0

# reboot

在升级内核之前就已经存在openstack环境

系统启动之后出现的状况：

实例启动失败

恢复状态失败

[root@YUN-11 ~(keystone_admin)]# nova reset-state test

[root@YUN-11 ~(keystone_admin)]# nova stop test

[root@YUN-11 ~(keystone_admin)]# nova start test

ERROR: Instance 93efe724-7288-4269-92d7-0346a00a724a in vm_state error. Cannot start while the instance is in this state. (HTTP 409) (Request-ID: req-d080c99c-e18a-4013-b677-d0ac98bf4575)

创建实例失败

[root@YUN-11 ~]# nova boot --image test-mini --flavor 1 test-1 --availability-zone nova:YUN-15 --nic net-id=e49ae481-4

ERROR: You must provide a username via either --os-username or env[OS_USERNAME]

在dashboard中查看“管理员”---“主机集合”，可以看到YUN-15的服务为停止状态

在YUN-15主机上

# service openstack-nova-compute restart

再次创建实例

出错信息：

错误：创建实例“test-1”失败： 请稍后再试[错误： Unexpected vif_type=binding_failed].

用命令查看异常的主机YUN-15和正常的主机服务的区别

[root@YUN-14 ~]# openstack-status

== Nova services ==

openstack-nova-api:                     dead      (disabled on boot)

openstack-nova-compute:                 active

openstack-nova-network:                 dead      (disabled on boot)

openstack-nova-scheduler:               dead      (disabled on boot)

== neutron services ==

neutron-server:                         inactive  (disabled on boot)

neutron-dhcp-agent:                     inactive  (disabled on boot)

neutron-l3-agent:                       inactive  (disabled on boot)

neutron-metadata-agent:                 inactive  (disabled on boot)

neutron-lbaas-agent:                    inactive  (disabled on boot)

neutron-openvswitch-agent:              active

== Ceilometer services ==

openstack-ceilometer-api:               dead      (disabled on boot)

openstack-ceilometer-central:           dead      (disabled on boot)

openstack-ceilometer-compute:           active

openstack-ceilometer-collector:         dead      (disabled on boot)

== Support services ==

libvirtd:                               active

openvswitch:                            active

messagebus:                             active

Warning novarc not sourced

[root@YUN-15 ~]# openstack-status

== Nova services ==

openstack-nova-api:                     dead      (disabled on boot)

openstack-nova-compute:                 active

openstack-nova-network:                 dead      (disabled on boot)

openstack-nova-scheduler:               dead      (disabled on boot)

== neutron services ==

neutron-server:                         inactive  (disabled on boot)

neutron-dhcp-agent:                     inactive  (disabled on boot)

neutron-l3-agent:                       inactive  (disabled on boot)

neutron-metadata-agent:                 inactive  (disabled on boot)

neutron-lbaas-agent:                    inactive  (disabled on boot)

neutron-openvswitch-agent:              dead

== Ceilometer services ==

openstack-ceilometer-api:               dead      (disabled on boot)

openstack-ceilometer-central:           dead      (disabled on boot)

openstack-ceilometer-compute:           active

openstack-ceilometer-collector:         dead      (disabled on boot)

== Support services ==

libvirtd:                               active

openvswitch:                            dead

messagebus:                             active

Warning novarc not sourced

发现YUN-15和YUN-14的区别在于openvswitch和neutron-openvswitch-agent服务的状态，YUN-15是关闭状态

重启服务

[root@YUN-15 ~]# service openvswitch restart

Killing ovsdb-server (4862)                                [  OK  ]

Starting ovsdb-server                                      [  OK  ]

Configuring Open vSwitch system IDs                        [  OK  ]

Starting ovs-vswitchd                                      [  OK  ]

Enabling remote OVSDB managers                             [  OK  ]

[root@YUN-15 ~]# service neutron-openvswitch-agent restart

Stopping neutron-openvswitch-agent:                        [FAILED]

Starting neutron-openvswitch-agent:                        [  OK  ]

再次在YUN-15创建云主机，发现云主机可以看见配置的地址，只是一直处于创建状态

2.3.2、升级内核出现的问题二

在另外一台物理机上做

和上面的操作基本一致，仅在下面一步上变化

# make menuconfig

在选择"IPv4"模块时没有勾选其下面的ipt_MASQUERADE

编译安装异常

# make modules_install install

sh ./arch/x86/boot/install.sh 3.19.3 arch/x86/boot/bzImage \

System.map "/boot"

ERROR: modinfo: could not find module crc_t10dif

ERROR: modinfo: could not find module scsi_tgt

重启之后物理机器死机

再次重启系统启动成功

扩展这台升级内核之后的系统为openstack计算节点

扩展失败

错误信息：

192.168.0.11_neutron.pp:                             [ DONE ]      

192.168.0.16_neutron.pp:                          [ ERROR ]        

Applying Puppet manifests                         [ ERROR ]

ERROR : Error appeared during Puppet run: 192.168.0.16_neutron.pp

Error: sysctl -p /etc/sysctl.conf returned 255 instead of one of [0]

You will find full trace in log /var/tmp/packstack/20150421-110210-5TXrme/manifests/192.168.0.16_neutron.pp.log

Please check log file /var/tmp/packstack/20150421-110210-5TXrme/openstack-setup.log for more information

查看日志文件/var/tmp/packstack/20150421-110210-5TXrme/openstack-setup.log

2015-04-21 11:09:22::ERROR::run_setup::921::root:: Traceback (most recent call last):

  File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 916, in main

    _main(confFile)

  File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 605, in _main

    runSequences()

  File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 584, in runSequences

    controller.runAllSequences()

  File "/usr/lib/python2.6/site-packages/packstack/installer/setup_controller.py", line 68, in runAllSequences

    sequence.run(config=self.CONF, messages=self.MESSAGES)

  File "/usr/lib/python2.6/site-packages/packstack/installer/core/sequences.py", line 98, in run

    step.run(config=config, messages=messages)

  File "/usr/lib/python2.6/site-packages/packstack/installer/core/sequences.py", line 44, in run

    raise SequenceError(str(ex))

SequenceError: Error appeared during Puppet run: 192.168.0.16_neutron.pp

Error: sysctl -p /etc/sysctl.conf returned 255 instead of one of [0]^[[0m

You will find full trace in log /var/tmp/packstack/20150421-110210-5TXrme/manifests/192.168.0.16_neutron.pp.log

网上查看相关信息，初步认定是内核缺少模块（内核编译问题）

现在就有个问题，内核编译和扩展节点先后顺序比较

之前是在YUN-15机器上先扩展节点，再升级内核，最后扩展完节点，实例起不来；现在是先升级内核，再扩展节点，又出现由于缺少网桥模块无法扩展节点的情况

2.3.3、正确的方式升级内核

1）、查看内核升级前的系统版本

[root@YUN-17 ~]# uname -r

2.6.32-431.el6.x86_64

2）、环境准备

# yum install -y xz

# tar -Jxvf linux-3.19.3.tar.xz -C /usr/src       （这里选择的linux版本是linux-3.19.3.tar.xz）

# yum install -y hmaccalc zlib-devel binutils-devel elfutils-libelf-devel

# yum install -y bc

# cd /usr/src/linux-3.19.3

# yum groupinstall -y "Development Tools"

3）、升级内核的配置文件

这里选择使用老的内核配置，因如果编辑内核配置文件的话，在编译安装的时候就会出现缺少内核模块的错误

[root@YUN-17 linux-3.19.3]# cp /boot/config-2.6.32-431.el6.x86_64 .config

# sh -c 'yes "" | make oldconfig'

# make oldconfig

# make

# make modules_install install

sh ./arch/x86/boot/install.sh 3.19.3 arch/x86/boot/bzImage \

System.map "/boot"

ERROR: modinfo: could not find module crc_t10dif

ERROR: modinfo: could not find module scsi_tgt

这里出现的错误提示可以忽略

4）、给YUN-17扩展节点，创建实例

创建实例成功

正常运行

注意事项：

注意系统升级内核和扩展节点的先后顺序，如果先扩展节点再升级内核的话，计算节点将出现异常，不能再创建实例

2.4、升级完内核后搭建ceph集群

2.4.1、配置主机名

2.4.2、配置hosts文件

在deploy节点上

192.168.1.200    admin-node

192.168.1.201    node1

192.168.1.202    node2

192.168.1.203    node3

2.4.3、配置本地YUM源

163源、cephh源和epel源

[ceph]

name=Ceph packages for $basearch

gpgkey=http://192.168.1.199/ceph.com/release.asc

enabled=1

baseurl=http://192.168.1.199/ceph.com/rpm-giant/el6/$basearch

priority=1

gpgcheck=1

type=rpm-md

[ceph-source]

name=Ceph source packages

gpgkey=http://192.168.1.199/ceph.com/release.asc

enabled=1

baseurl=http://192.168.1.199/ceph.com/rpm-giant/el6/SRPMS

priority=1

gpgcheck=1

type=rpm-md

[ceph-noarch]

name=Ceph noarch packages

gpgkey=https://192.168.1.199/ceph.com/release.asc

enabled=1

baseurl=http://192.168.1.199/ceph.com/rpm-giant/el6/noarch

priority=1

gpgcheck=1

type=rpm-md

2.4.4、在deploy节点升级并安装部署工具

2.4.5、ntp服务

2.4.6、创建用户

每个节点上都做

[root@admin-node ~]# useradd -d /home/ceph -m ceph

[root@admin-node ~]# passwd ceph

[root@admin-node ~]# echo "ceph ALL = (root) NOPASSWD:ALL" | tee /etc/sudoers.d/ceph

ceph ALL = (root) NOPASSWD:ALL

[root@admin-node ~]# chmod 0440 /etc/sudoers.d/ceph

2.4.7、无密码访问

[root@admin-node ~]# su ceph

[ceph@admin-node root]$ cd

[ceph@admin-node ~]$ ssh-keygen

[ceph@admin-node ~]$ ssh-copy-id ceph@node1

bash: ssh-copy-id: command not found

[ceph@admin-node ~]$ sudo yum install openssh-clients -y

[ceph@admin-node ~]$ ssh-copy-id ceph@node1

[ceph@admin-node ~]$ ssh-copy-id ceph@node2

[ceph@admin-node ~]$ ssh-copy-id ceph@node3

测试

[ceph@admin-node ~]$ ssh ceph@node1

[ceph@node1 ~]$ exit

logout

Connection to node1 closed.

[ceph@admin-node ~]$ ssh ceph@node2

[ceph@node2 ~]$ exit

logout

Connection to node2 closed.

[ceph@admin-node ~]$ ssh ceph@node3

[ceph@node3 ~]$ exit

logout

Connection to node3 closed.

[ceph@admin-node ~]$ pwd

/home/ceph

[ceph@admin-node ~]$ vi .ssh/config

Host node1

   Hostname node1

   User ceph

Host node2

   Hostname node2

   User ceph

Host node3

   Hostname node3

   User ceph

再次验证出错

[ceph@admin-node ~]$ ssh ceph@node1

Bad owner or permissions on /home/ceph/.ssh/config

修改权限解决问题

[ceph@admin-node .ssh]$ ll

total 16

-rw-rw-r--. 1 ceph ceph  135 Mar  2 18:47 config

-rw-------. 1 ceph ceph 1675 Mar  2 18:31 id_rsa

-rw-r--r--. 1 ceph ceph  397 Mar  2 18:31 id_rsa.pub

-rw-r--r--. 1 ceph ceph 1203 Mar  2 18:42 known_hosts

[ceph@admin-node .ssh]$ ssh ceph@node1

Bad owner or permissions on /home/ceph/.ssh/config

[ceph@admin-node .ssh]$ chmod 600 *

[ceph@admin-node .ssh]$ ll

total 16

-rw-------. 1 ceph ceph  135 Mar  2 18:47 config

-rw-------. 1 ceph ceph 1675 Mar  2 18:31 id_rsa

-rw-------. 1 ceph ceph  397 Mar  2 18:31 id_rsa.pub

-rw-------. 1 ceph ceph 1203 Mar  2 18:42 known_hosts

[ceph@admin-node .ssh]$ ssh ceph@node1

Last login: Mon Mar  2 20:40:38 2015 from 192.168.1.120

[ceph@node1 ~]$ exit

logout

Connection to node1 closed.

2.4.8、防火墙和selinux

[ceph@node1 ~]$ ifconfig

eth2      Link encap:Ethernet  HWaddr 00:0C:29:59:C7:57  

          inet addr:192.168.1.201  Bcast:192.168.1.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe59:c757/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:45308 errors:0 dropped:0 overruns:0 frame:0

          TX packets:7103 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:59108143 (56.3 MiB)  TX bytes:648018 (632.8 KiB)

eth3      Link encap:Ethernet  HWaddr 00:0C:29:59:C7:61  

          inet addr:172.16.1.201  Bcast:172.16.1.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe59:c761/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:2317 errors:0 dropped:0 overruns:0 frame:0

          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:219673 (214.5 KiB)  TX bytes:538 (538.0 b)

网卡都相同

mon端口

[ceph@admin-node .ssh]$ sudo iptables -A INPUT -i eth2 -p tcp -s 192.168.1.201/24 --dport 6789 -j ACCEPT

osd端口

[ceph@admin-node .ssh]$ sudo iptables -A INPUT -i eth2  -m multiport -p tcp -s 192.168.1.202/24 --dports 6800:7100 -j ACCEPT

[ceph@admin-node .ssh]$ sudo iptables -A INPUT -i eth2  -m multiport -p tcp -s 192.168.1.203/24 --dports 6800:7100 -j ACCEPT

TTY

sudo visudo

Defaults requiretty 

to

Defaults:ceph !requiretty 

selinux

[ceph@admin-node .ssh]$ sudo setenforce 0

2.4.9、部署

[ceph@admin-node ~]$ cd my-cluster/

[ceph@admin-node my-cluster]$ ceph-deploy new node1

出错：

[ceph_deploy][ERROR ] RuntimeError: remote connection got closed, ensure ``requiretty`` is disabled for node1

Error in sys.exitfunc:

解决方法: 需要在node1、node2、和node3三个节点中使用ceph用户的身份执行sudo visudo命令，然后修改

Defaults requiretty 为Defaults:ceph !requiretty

删除配置

[ceph@admin-node my-cluster]$ ceph-deploy purgedata node1

[ceph@admin-node my-cluster]$ ceph-deploy forgetkeys

[ceph@admin-node my-cluster]$ ceph-deploy purge node1

[ceph@admin-node my-cluster]$ ceph-deploy new node1

生成

ceph.conf  ceph.log  ceph.mon.keyring

vi ceph.conf

osd pool default size = 2

ceph@admin-node my-cluster]$ ceph-deploy install node1 node2 node3

出错：

[node1][INFO  ] Running command: sudo rpm --import https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc

[node1][WARNIN] curl: (6) Couldn't resolve host 'ceph.com'

[node1][WARNIN] error: https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc: import read failed(2).

[node1][ERROR ] RuntimeError: command returned non-zero exit status: 1

[ceph_deploy][ERROR ] RuntimeError: Failed to execute command: rpm --import https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc

解决办法：

查找配置文件

[root@admin-node my-cluster]# find / -type f -name "*.py" | xargs grep "https://ceph.com/git"

/usr/lib/python2.6/site-packages/ceph_deploy/hosts/fedora/install.py:                    "https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/{key}.asc".format(key=key)

/usr/lib/python2.6/site-packages/ceph_deploy/hosts/fedora/install.py:                "https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/{key}.asc".format(key=key),

/usr/lib/python2.6/site-packages/ceph_deploy/hosts/centos/install.py:                    "https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/{key}.asc".format(key=key)

/usr/lib/python2.6/site-packages/ceph_deploy/hosts/centos/install.py:                "https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/{key}.asc".format(key=key),

/usr/lib/python2.6/site-packages/ceph_deploy/hosts/debian/install.py:                'https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/{key}.asc'.format(key=key),

/usr/lib/python2.6/site-packages/ceph_deploy/conf/cephdeploy.py:# gpgkey=https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/autobuild.asc

/usr/lib/python2.6/site-packages/ceph_deploy/conf/cephdeploy.py:# gpgkey=https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/autobuild.asc

/usr/lib/python2.6/site-packages/ceph_deploy/install.py:        gpg_fallback = 'https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc'

cd /usr/lib/python2.6/site-packages/ceph_deploy

可以看到install.py 、install.pyc 和install.pyo三个文件

pyc是一种二进制文件，是由py文件经过编译后，生成的文件，是一种byte code  

vi  install.py

        #gpg_fallback = 'https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc'

        gpg_fallback = 'http://192.168.1.199/ceph.com/release.asc'

还是出错        

[ceph@admin-node centos]$ pwd

/usr/lib/python2.6/site-packages/ceph_deploy/hosts/centos

[ceph@admin-node centos]$ ls

__init__.py   __init__.pyo  install.pyc  mon     pkg.pyc  uninstall.py   uninstall.pyo

__init__.pyc  install.py    install.pyo  pkg.py  pkg.pyo  uninstall.pyc

再次修改文件

vi /usr/lib/python2.6/site-packages/ceph_deploy/hosts/centos/install.py

if adjust_repos:

        if version_kind != 'dev':

            remoto.process.run(

                distro.conn,

                [

                    'rpm',

                    '--import',

                    #"https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/{key}.asc".format(key=key)

                    "http://192.168.1.199/ceph.com/release.asc"

                ]

            )

            if version_kind == 'stable':

                url = 'http://192.168.1.199/ceph.com/rpm-{version}/{repo}/'.format(

                    version=version,

                    repo=repo_part,

                    )

            elif version_kind == 'testing':

                url = 'http://192.168.1.199/ceph.com/rpm-testing/{repo}/'.format(repo=repo_part)

            #remoto.process.run(

            #    distro.conn,

            #    [

            #        'rpm',

            #        '-Uvh',

            #        '--replacepkgs',

            #        '{url}noarch/ceph-release-1-0.{dist}.noarch.rpm'.format(url=url, dist=dist),

            #    ],

            #)

再次执行  ceph-deploy install node1 node2 node3

执行成功

结束

[node3][DEBUG ] Complete!

[node3][INFO  ] Running command: sudo ceph --version

[node3][DEBUG ] ceph version 0.87 (c51c8f9d80fa4e0168aa52685b8de40e42758578)

Error in sys.exitfunc:

2.5、LVM分区格式下扩展系统根分区

[root@YUN17 ~]# umount /home

[root@YUN17 ~]# e2fsck -f /dev/mapper/vg_YUN2-lv_home

e2fsck 1.41.12 (17-May-2010)

e2fsck: No such file or directory while trying to open /dev/mapper/vg_YUN2-lv_home

The superblock could not be read or does not describe a correct ext2

filesystem.  If the device is valid and it really contains an ext2

filesystem (and not swap or ufs or something else), then the superblock

is corrupt, and you might try running e2fsck with an alternate superblock:

    e2fsck -b 8193 <device>

[root@YUN17 ~]# e2fsck -f /dev/mapper/vg_YUN17-lv_home

e2fsck 1.41.12 (17-May-2010)

/dev/mapper/vg_YUN17-lv_home is in use.

e2fsck: Cannot continue, aborting.

[root@YUN17 ~]# resize2fs -p /dev/mapper/vg_YUN17-lv_home 2G

resize2fs 1.41.12 (17-May-2010)

resize2fs: Device or resource busy while trying to open /dev/mapper/vg_YUN17-lv_home

Couldn't find valid filesystem superblock.

[root@YUN17 ~]# mount /home

[root@YUN17 ~]# df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/mapper/vg_YUN17-lv_root

                       50G  9.9G   37G  22% /

tmpfs                 253G  4.0K  253G   1% /dev/shm

/dev/sda1             477M   62M  387M  14% /boot

/srv/loopback-device/swiftloopback

                      1.9G  3.1M  1.7G   1% /srv/node/swiftloopback

/dev/mapper/vg_YUN17-lv_home

                      769G   69M  730G   1% /home

[root@YUN17 ~]# lvreduce -L 2G /dev/mapper/vg_YUN17-lv_home

  WARNING: Reducing active and open logical volume to 2.00 GiB

  THIS MAY DESTROY YOUR DATA (filesystem etc.)

Do you really want to reduce lv_home? [y/n]: y

  Size of logical volume vg_YUN17/lv_home changed from 780.90 GiB (199911 extents) to 2.00 GiB (512 extents).

  Logical volume lv_home successfully resized

[root@YUN17 ~]# df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/mapper/vg_YUN17-lv_root

                       50G  9.9G   37G  22% /

tmpfs                 253G  4.0K  253G   1% /dev/shm

/dev/sda1             477M   62M  387M  14% /boot

/srv/loopback-device/swiftloopback

                      1.9G  3.1M  1.7G   1% /srv/node/swiftloopback

/dev/mapper/vg_YUN17-lv_home

                      769G   69M  730G   1% /home

[root@YUN17 ~]# vgdisplay

  --- Volume group ---

  VG Name               vg_YUN17

  System ID             

  Format                lvm2

  Metadata Areas        1

  Metadata Sequence No  5

  VG Access             read/write

  VG Status             resizable

  MAX LV                0

  Cur LV                3

  Open LV               3

  Max PV                0

  Cur PV                1

  Act PV                1

  VG Size               834.90 GiB

  PE Size               4.00 MiB

  Total PE              213735

  Alloc PE / Size       14336 / 56.00 GiB

  Free  PE / Size       199399 / 778.90 GiB

  VG UUID               UY5pX2-BCLJ-x4ig-Cr0z-sAS1-mUEc-nixVw9

  --- Volume group ---

  VG Name               cinder-volumes

  System ID             

  Format                lvm2

  Metadata Areas        1

  Metadata Sequence No  1

  VG Access             read/write

  VG Status             resizable

  MAX LV                0

  Cur LV                0

  Open LV               0

  Max PV                0

  Cur PV                1

  Act PV                1

  VG Size               20.60 GiB

  PE Size               4.00 MiB

  Total PE              5273

  Alloc PE / Size       0 / 0   

  Free  PE / Size       5273 / 20.60 GiB

  VG UUID               ND2yf7-BRxo-sYm1-VB6A-t0nt-aVPg-Fq3MPH

[root@YUN17 ~]# lvextend -L +750G /dev/mapper/vg_YUN17-lv_root

  Size of logical volume vg_YUN17/lv_root changed from 50.00 GiB (12800 extents) to 800.00 GiB (204800 extents).

  Logical volume lv_root successfully resized

[root@YUN17 ~]# resize2fs -p /dev/mapper/vg_YUN17-lv_root

resize2fs 1.41.12 (17-May-2010)

Filesystem at /dev/mapper/vg_YUN17-lv_root is mounted on /; on-line resizing required

old desc_blocks = 4, new_desc_blocks = 50

Performing an on-line resize of /dev/mapper/vg_YUN17-lv_root to 209715200 (4k) blocks.

The filesystem on /dev/mapper/vg_YUN17-lv_root is now 209715200 blocks long.

[root@YUN17 ~]# df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/mapper/vg_YUN17-lv_root

                      788G   10G  745G   2% /

tmpfs                 253G  4.0K  253G   1% /dev/shm

/dev/sda1             477M   62M  387M  14% /boot

/srv/loopback-device/swiftloopback

                      1.9G  3.1M  1.7G   1% /srv/node/swiftloopback

/dev/mapper/vg_YUN17-lv_home

                      769G   69M  730G   1% /home

[root@YUN17 ~]# fdisk -l

Disk /dev/sda: 897.0 GB, 896998047744 bytes

255 heads, 63 sectors/track, 109053 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk identifier: 0x0000292d

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1   *           1          64      512000   83  Linux

Partition 1 does not end on cylinder boundary.

/dev/sda2              64      109054   875461632   8e  Linux LVM

Disk /dev/mapper/vg_YUN17-lv_root: 859.0 GB, 858993459200 bytes

255 heads, 63 sectors/track, 104433 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk identifier: 0x00000000

Disk /dev/mapper/vg_YUN17-lv_swap: 4294 MB, 4294967296 bytes

255 heads, 63 sectors/track, 522 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk identifier: 0x00000000

Disk /dev/mapper/vg_YUN17-lv_home: 2147 MB, 2147483648 bytes

255 heads, 63 sectors/track, 261 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk identifier: 0x00000000

三、注意事项

3.1、挂载目录是需要注意的事项

把分区挂载到目录下的操作要谨慎小心

对于存放系统重要文件的目录不要挂载，对于目录下有重要文件的目录需要做备份，因为挂载过程中会把目录清空

四、命令汇总

4.1、openstack命令汇总

查看openstack节点上服务状态

[root@YUN-14 ~]# openstack-status

当实例启动失败时可以尝试一下命令（test为虚机的名字）

重置虚机的状态

[root@YUN-11 ~(keystone_admin)]# nova reset-state test

关闭虚机

[root@YUN-11 ~(keystone_admin)]# nova stop test

启动虚机

[root@YUN-11 ~(keystone_admin)]# nova start test

查看虚机资源配额的列表

[root@YUN-11 ~(keystone_admin)]# nova flavor-list

查看镜像的列表

[root@YUN-11 ~(keystone_admin)]# nova image-list

查看网络的列表

[root@YUN-11 ~(keystone_admin)]# nova network-list

查看云主机的信息

[root@YUN-19 ~(keystone_admin)]# nova list

创建虚机的一般命令

# nova boot --image imageID --flavor flavorID --nic net-id=nicID name

（最后的name是指给云主机起的名字）

下面是一个示例，只是这个示例比上边的多了些参数，指定了要创建到那个openstack计算节点上。

[root@YUN-11 ~(keystone_admin)]# nova boot --image test-mini --flavor 1 test-1 --availability-zone nova:YUN-15 --nic net-id=e49ae481-4

（--image后边是指定的镜像名，--flavor后边是指定的虚机配给资源的id，后边的test-1是为虚机起的名字，-availability-zone后边的nova是域、YUN-15是openstack计算节点的主机名，--nic net-id是要把虚机所在网络的id）

添加镜像

[root@YUN-11 ~(keystone_admin)]# glance add name=test-26 is_public=true container_format=bare disk_format=raw < /root/disk4

（disk_format后面跟镜像格式，< 后面是镜像的目录）

删除云主机

# nova delete <instance-uuid>

查看云主机的详细信息

# nova show <instance-name>

当计算节点无法创建虚机，而且在dashboard中查看“管理员”---“主机集合”，可以看到节点名为YUN-15的服务为停止状态，就需要在这个节点上重启openstack计算节点的主服务

# service openstack-nova-compute restart

4.2、硬件相关命令

查看CPU信息

[root@YUN-19 ~]# cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c

    192  Intel(R) Xeon(R) CPU E7-8850 v2 @ 2.30GHz

4.3、虚拟化相关的命令

查看镜像的信息

# qemu-img info disk

转换镜像的格式

# qemu-img convert -O raw disk disk3

更改镜像的大小（增加）

# qemu-img resize disk3 +100M

更改镜像的大小（减少）

# qemu-img resize disk3 -- -100M

五、实验

5.1、迁移实验

冷迁移实验

1）、暂停云主机

2）、ssh登录YUN-12主机

# cd /var/lib/nova/instances

# scp -rp dbaab72b-75c3-4dc5-99f2-95a579a315c5 root@test -compute:/var/lib/nova/instances

3）、ssh登录YUN-11主机修改数据库

# mysql

use nova;

update instances set host='YUN-12' where hostname='test1'

4）、结果验证

此刻可以看见云主机所属主机发生变化，变为test-compute

在dashboard中选中test1“回复云主机”，结果“状态”、“任务”和“电源状态”分别是“Paused”、“None”和“No state”

另外一次的冷迁移实验

1）、YUN-19上

# mysql

mysql> use nova;

mysql> update instances set host='YUN-20' where hostname='test1';

# scp -r a8814340-98d5-4ed3-b99b-32ee38cfb78f/ root@192.168.0.20:/var/lib/nova/instances/

2）、YUN-20上

2.1）、[root@YUN-20 instances]# ll

total 20

drwxr-xr-x. 2 nova nova 4096 Apr 28 20:55 1c11a4b1-5df8-48f8-be5d-6e1c5efb7f99

drwxr-xr-x. 2 root root 4096 Apr 28 21:41 a8814340-98d5-4ed3-b99b-32ee38cfb78f

drwxr-xr-x. 2 nova nova 4096 Apr 28 20:55 _base

-rw-r--r--. 1 nova nova   29 Apr 28 21:28 compute_nodes

drwxr-xr-x. 2 nova nova 4096 Apr 23 23:49 locks

[root@YUN-20 instances]# chown -R nova:nova a8814340-98d5-4ed3-b99b-32ee38cfb78f/

[root@YUN-20 instances]# ll

total 20

drwxr-xr-x. 2 nova nova 4096 Apr 28 20:55 1c11a4b1-5df8-48f8-be5d-6e1c5efb7f99

drwxr-xr-x. 2 nova nova 4096 Apr 28 21:41 a8814340-98d5-4ed3-b99b-32ee38cfb78f

drwxr-xr-x. 2 nova nova 4096 Apr 28 20:55 _base

-rw-r--r--. 1 nova nova   29 Apr 28 21:28 compute_nodes

drwxr-xr-x. 2 nova nova 4096 Apr 23 23:49 locks

2.2）、网桥

# brctl addbr br0

# brctl add if br0 eth2

注：

eth2 192.168.0.20

结果 网络无法连通

做下面的操作

# brctl delbr br0

重启网络后主机连通

注：

brctl命令

brctl show  查看网桥

[root@YUN-20 a8814340-98d5-4ed3-b99b-32ee38cfb78f]# virsh define libvirt.xml

Domain instance-00000001 defined from libvirt.xml

[root@YUN-20 a8814340-98d5-4ed3-b99b-32ee38cfb78f]# virsh start instance-00000001

error: Failed to start domain instance-00000001

error: Cannot get interface MTU on 'qbr95221104-b9': No such device

[root@YUN-20 a8814340-98d5-4ed3-b99b-32ee38cfb78f]# brctl addbr qbr95221104-b9

[root@YUN-20 a8814340-98d5-4ed3-b99b-32ee38cfb78f]# brctl show

bridge name bridge id  STP enabled interfaces

qbr482b0524-26  8000.ea9b0ced7d50 no  qvb482b0524-26

tap482b0524-26

qbr95221104-b9  8000.000000000000 no  

show  8000.000000000000 no  

virbr0  8000.525400d2ae89 yes  virbr0-nic

[root@YUN-20 a8814340-98d5-4ed3-b99b-32ee38cfb78f]# virsh define libvirt.xml

Domain instance-00000001 defined from libvirt.xml

[root@YUN-20 a8814340-98d5-4ed3-b99b-32ee38cfb78f]# virsh start instance-00000001

Domain instance-00000001 started

2.3）、启动

发现云主机启动成功，但是其他机器无法PING通这台机器

进入控制台，发现无法进入系统，出现下面所示的错误

BIOS EDD facility 0 devices found

EDD information not available

Freeing unused kernel memory：900k freed

2.4）、发现YUN-19上还存在在YUN-20上创建的网桥

[root@YUN-19 ~(keystone_admin)]# brctl show

bridge name bridge id  STP enabled interfaces

qbr7a2e6ef4-55  8000.1e1edf473784 no  qvb7a2e6ef4-55

tap7a2e6ef4-55

qbr95221104-b9  8000.325dbda87640 no  qvb95221104-b9

qbra1cf60e8-36  8000.16f46f1ed7f8 no  qvba1cf60e8-36

tapa1cf60e8-36

show  8000.000000000000 no

删除不了，因为正在使用

[root@YUN-19 ~(keystone_admin)]# brctl delbr qbr95221104-b9

bridge qbr95221104-b9 is still up; can't delete it

关闭网桥

# ifconfig qbr95221104-b9 down

再次删除

[root@YUN-19 ~(keystone_admin)]# brctl delbr qbr95221104-b9

2.5）、关闭实例，重启系统

启动之后，启动实例，发现还是无法进入系统，错误相同

2.6）、解决问题

[root@YUN-20 ~]# ifconfig qbr95221104-b9 down

[root@YUN-20 ~]# brctl delbr qbr95221104-b9

[root@YUN-20 ~]# brctl show

bridge name bridge id  STP enabled interfaces

qbr482b0524-26  8000.1ec880fdff13 no  qvb482b0524-26

tap482b0524-26

virbr0  8000.525400d2ae89 yes  virbr0-nic

[root@YUN-20 ~]# brctl addbr qbr95221104-b9

[root@YUN-20 ~]# brctl show

bridge name bridge id  STP enabled interfaces

qbr482b0524-26  8000.1ec880fdff13 no  qvb482b0524-26

tap482b0524-26

qbr95221104-b9  8000.000000000000 no  

virbr0  8000.525400d2ae89 yes  virbr0-nic

2.7）、云主机ssh连不上

在控制节点进入控制台，发现屏幕背景是黑色的，在有下面出现一个弹窗

提示“The configuration defaults for GNOME Power Manager have not been installed correctly.Please contact your computertor”。

再次重启进入桌面，进入命令行界面，查看系统空间信息，发现根下面被完全占用。

解决办法：

网上的解决办法：

1、On login Screen,press Control+Alt+F2

2、Remove same files or folders

3、Check the permissiions on your /tmp folder or just set them to: sudo chmod 0777 /tmp

4、Execute the command: reboot

但是执行完上边的操作后，ssh还是连不上系统。

执行下面的操作

yum remove and re-install gnome-power-manager

reboot

之后发现系统可以通过SSH连接

主机正常

2.8）、确定镜像文件在拷贝到远程的主机之前是否需要转换一下格式

把YUN-11所在的集群实例迁移到YUN-19所在集群

YUN-17上的实例做实验

以cirros的镜像创建的实例为例

直接把实例目录下的disk文件拷贝到远程主机上

然后添加镜像，镜像格式化为qcow2

之后再dash中从该镜像启动实例，结果失败，状态为“Error”

在拷贝disk文件之前把镜像各是转换为qcow格式

拷贝后添加镜像，格式化为qcow2

之后再dash中从该镜像启动实例，结果启动成功，但是在随后绑定浮动IP后，结果在外部的机器无法PING通该实例的浮动IP

在YUN-11所在的集群内做迁移

直接把实例目录下的disk文件拷贝到远程主机上

然后添加镜像，镜像格式化为qcow2

之后再dash中从该镜像启动实例，结果失败，状态为“Error”

把上面转换为qcow格式的镜像拷贝到YUN-11上，在做之后的操作，最后发现外部主机可以PING通浮动IP

从这可以看出是YUN-19所在集群网络的问题，因为这两个集群网路相同

在YUN-19集群dash中创建实例，在YUN-11所在的集群上的实例无法ping通YUN-19所在集群上实例的内网IP，绑定浮动IP后也无法PING通

事实证明的确需要装换镜像格式

六、问题

6.1、创建网桥和扩展计算节点的先后顺序颠倒之后会不会产生意外的后果？

我在日常的部署中两个顺序在颠倒的情况下暂时没有发现意外的后果，有待测试

openstack项目中遇到的各种问题总结

标签：openstack ceph

原文地址：http://blog.51cto.com/xiaoxiaozhou/2113343