11月 212017
 

 

一个bridge诞生时,会有一个mac地址;当向bridge上addif  veth2时,bridge的mac地址就跟随了veth2的mac地址,难道br0就不能固定一个mac地址吗?

可以的:

默认情况下,bridge总是跟随port中mac地址最小的那个port的mac地址,如果不想让mac地址总是变化,则可以设置bridge的首选mac地址,方法就是显式地给bridge设置mac地址:

参考:

http://blog.csdn.net/fanwenbo/article/details/2131193

 Posted by at 下午 2:58
11月 062017
 
  1. 同网段的机器ping的时候报没有路由的问题
    1. arp -an查看,发现mac地址都没查到
    2. 通过宿主机直接看虚拟机,发现虚拟机的网卡、ip都是在的
    3. 解决:
      1. 虚拟机桥接的网桥重启过,而虚拟没有重启,相当于“网线断了”
    4. 结论:
      1. 不要随便重启网桥,重启之后端口信息就没了,其下属的机器就相当于断了网线,后果很严重
  2. openstack启动的机器我们都可以看到libvirtd的xml配置文件,xml配置文件中有关于网卡机器对应的tap的信息; 我们直接virt-manager上通过桥接方式配置的网卡,在xml文件中找不到关于tap的名字的信息,但是对应的网桥下确实会多出来一个类似于vnet的网络设备

 

 

 

 

 Posted by at 下午 12:14
10月 302017
 

在使用neutron的provider网络时,使用linuxbridge做驱动,配置是这样的:

提供一个设置了IP的网络设备(不能是bridge)

当启用该网络时,linuxbridge会创建一个bridge,将配置中的IP配置到该bridge上,然后,把配置的设备插到该bridge上

其实,我不想把宿主机上唯一的网卡给neutron,于是:

  1. 在宿主机网卡上配置一个bridge
  2. 把宿主机IP配置在该bridge上
  3. 创建一个设备对儿
  4. 设备对的一端叫veth@br0,插到上面创建的bridge上
  5. 设备对儿的另一段叫veth@neutron,配置一个IP,把该IP和veth@neutron写到neutron的配置文件中

这样neutron只需要操作veth@neutron就行了

这样基本是可以的,唯一的问题在于veth@neutron这个名字里面的@不招待见,neutron服务会报错, 修改个名字就行了

续: veth@br0 的命名也是会遭到抵制的,在使用ip link list的时候,会出现这样一个设备:

似乎@也是一个特殊字符,如果@出现两次,则linuxbridge代码中会出现异常,如下:

显然,这里只觉得设备名称最多有一个@

 

相关脚本:

 Posted by at 下午 7:50
10月 252017
 

设置:

读写最大10MB/s,iops最大50/s

  • 设置flavor, 在flavor上添加属性

  • 通过virsh dumpxml验证:

  • 验证

关于对卷的限速: http://ceph.com/planet/openstack-ceph-rbd-and-qos/

The disk I/O options are:

  • disk_read_bytes_sec
  • disk_read_iops_sec
  • disk_write_bytes_sec
  • disk_write_iops_sec
  • disk_total_bytes_sec
  • disk_total_iops_sec

参考: https://docs.openstack.org/nova/pike/admin/flavors.html

对于单独创建的卷来讲,可以在创建卷时指定卷类型,而卷类型可以预先关联已定义好的qos规格的,如:

 

注意:

  1.  对于创建虚拟机时使用新建卷的情况,该限速没有被应用,应该是bug吧
  2. 官方文档的一点儿要问题
  3. openstack的dashboard上也有一些误导的地方:

    这里的提示仅仅可以当做是示例,真正需要什么就写什么就行了,如,关于磁盘限速的相关键为:

    • read_bytes_sec
    • read_iops_sec
    • write_bytes_sec
    • write_iops_sec
    • total_bytes_sec
    • total_iops_sec
      注意: 这里不需要上面所谓的 disk_ 前缀

 

 Posted by at 下午 5:50
10月 242017
 

前言

openstack是个很不错的东西,结合ceph之后,openstack就如同插上了翅膀,更加强大了。

 

ceph的好处:

  1. 有了ceph这个共享存储,guest的热迁移就方便多了
  2. ceph提供的块儿存储支持snap和clone,是的创建虚机和快照都不用copy磁盘,使得创建虚机可以秒级完成,而且非常节省存储

我遇到的问题:

  1. 在我将openstack和ceph结合起来之后,创建虚机依然很慢,并没有达到创建虚机不复制磁盘的效果

解决办法:

  1. 调试虚拟创建过程,发现如果要利用上rbd的snap和clone的特性,需要在image上有location属性;然而,我创建的image并没有该属性,openstack image命令行没有location相关选项,dashboard上创建镜像也没有该属性,只有glance命令行允许指定或单独添加该属性,却又报location invisible的错误;临时解决办法:直接修改代码,在代码中添加:
  2. 关于glance设置location失败的问题,根据关键字去glance代码中查看代码,发现当配置文件中的show_multiple_locations = false时,是不允许操作location的:

    然后,去glance-api的机器上grep show_multiple_locations ,并修改为True,重启glance-api 服务;然后再尝试location-add,提示url已存在,其实,该信息本来是存在的,只是显示与否的问题,现在不需要做任何操作,已经可以从image的信息中看到url了,如下:

    参考配置文件 /etc/glance/glance-api.conf 得知,show_multiple_locations = True使得image的地址直接暴露给了client,client就可以直接操作image了,可能存在一定的安全问题;当我们认为这不是问题的时候,我们就可以修改该配置,现在,我正是想利用rbd的一些特性,就需要将给选项设置为True;

  3. 至此,纠结已经的问题正式告一段落

总结:

  1. 按照手册安装openstack没有太大意义,能发现问题并解决问题才能进步;在解决该问题的过程中,尝试了python的单步调试(效果很差)、从代码上了解了虚拟机创建的过程,也了解了一些glance的代码,受益匪浅
 Posted by at 下午 1:54
10月 122017
 

在openstack管理的虚拟机中启动vnc时,:1 是启动不了的,似乎是被kvm已某种方式给占用了,而这种占用方式似乎并不依赖虚拟机中的vnc软件。

浏览器中的vnc性能和体验都不如vnc客户端软件

 Posted by at 上午 10:00
9月 292017
 

软件包: libguestfs-tools

这里的 guestfish 挺不错的

  1. 查看镜像分区及其使用情况:
  2. 查看镜像中的文件信息
  3. copy 文件到镜像
  4. 查看镜像中的文件
  5. 查看镜像中的文件系统分区信息: virt-filesystems –long –parts –blkdevs -h -a CentOS-7-x86_64-GenericCloud-1708.raw

virt-resize:  –shrink  并不能让镜像文件变的更小(反而变大了)

virt-sparsify  可以使得一个镜像文件变成一个稀疏文件,对于发布、存储镜像很有必要

 Posted by at 下午 2:35
9月 272017
 

文档中说在 /etc/openstack-dashboard/local_settings 中修改(或添加)SESSION_TIMEOUT 可以控制dashboard的过期时间,但是修改了怎么也不生效,后看代码发现:

dashboard登录后总是去keystone获取一个token的,token总有过期时间的,所以,dashboard的session过期时间就是自己定义的过期时间和token的过期时间取小的那个。

keystone 的token过期时间配置参考: /etc/keystone/kestone.conf

 

 Posted by at 下午 3:36
9月 262017
 

在配置openstack的热迁移时遇到了几个问题,这里记录一下。

  1. 迁移和热迁移的区别
    不太注意的情况下,发现迁移也挺快的,其实区别太大了

    1. 迁移是先停掉虚拟机,再启动虚拟机
    2. 热迁移基本是无感知的,虚拟机中的进程是不会死掉的
    3. openstack中,热迁移可以选择目标地址,迁移不能选择目标地址
    4. 迁移不需要libvirtd listen12506端口,热迁移需要
  2. 热迁移注意事项
    1. 要确保该落地的都落地了
    2. 虚拟机所在环境要高度一致
      1. 都使用正确配置了的共享存储
      2. qemu-kvm版本要一致
  3. 热迁移失败的故障排查
    1. 由于使用的qemu-kvm是官方的源,后来安装的qemu-kvm版本高了一些,所以热迁移总是失败,nova的日志中没有看到错误信息,结果却是在dashboard的httpd的错误日志中发现了问题所在,于是将所有qemu-kvm升级到最新版本
    2. 由于对热迁移没有研究过,基本小白一个,再次热迁移失败后,从目标机器nova的日志中看到错误信息,大致意思为libvirt连接源计算节点的12506端口失败,然而源计算节点并没有listen 12506端口,解决办法: http://yansu.org/2013/03/25/open-tcp-port-of-libvirt.html
 Posted by at 下午 5:27