使用rbd-nbd挂载rbd image

由于我的rbd image中都是一个相同的基础镜像，里面的文件系统都一样，相同的xfs文件系统格式，相同的文件系统id；所以，就算可以rbd map多个，也不能同时mount多个，因为文件系统id一样啊。

问题是，我已经umount了rbd image1，再去mount rbd image2，为啥还是提示：

原因： 虽然umount了，但是相关的xfs后台进程并没有退出，所以，可以进一步unmap掉那个不需要的设备，xfs进程就会退出：

不要把openstack neutron组件虚拟机放到计算节点上

对于使用linux-bridge来实现网络虚拟化的情况：

如果需要使用vlan来作为provider，则，配置基本如下：

 

/etc/neutron/plugins/ml2/linuxbridge_agent.ini

 

/etc/neutron/plugin.ini

 

注意：  network_vlan_ranges 是需要配置的， 这样在重启neutron服务的时候，会在neutron数据库中创建：

network_vlan_ranges 配置从注释来看，似乎可以不写vlan范围，其实不行，因为需要在表中创建条目，如果指定range大小会1000，则会一次产生1000个数据库记录；

另外，当我们从配置文件中把 provider 删除（或重命名）时，数据库中的条目并不被删除，而且会导致neutron服务启动失败，这时候，可以手动删除上述条目

 

当我们在provider上创建一个vlan id为3000的vlan provider时，会自动创建eth0.3000, 假如compute节点上部署openstack-controller（确切说，应该是neutron）虚拟机，由于该虚拟机也需要类似eth0.3000的接口，然而，宿主机只有一个网卡的情况下，如果虚拟机桥接的也是eth0的话，宿主机上创建了eth0.3000后，虚拟机将不再能收到vlan3000的流量了（被截流了），所以就比较麻烦，所以，建议neutron虚拟机不要部署在计算节点上；也或者还有其它的不愉快。

 

当然，如果确实没有其它的机器安装neutron虚拟机呢？其实办法还是有的：

openstack 中配置给provider的物理网卡使用veth1 就行， 这样的话，vm-neutron也能看到vlan3000的数据包了

 

问： openstack 中配置给provider的物理网卡使用veth0 行不？

根据veth对儿实现原理，veth0接收到的数据如果不是从veth1来的，肯定发送给veth1，否则发送给br0；假如，配置为veth0，则vm的数据发送给veth0.3000后，经过veth0会被发送给veth1，而不是br0，这不是我们想要的

KVM 通过virsh console连入虚拟机

参考： https://www.cnblogs.com/xieshengsen/p/6215168.html

在kernel启动参数中添加： console=ttyS0

这岂不是要重启？

也不用，centos7下，只需要启动一个服务就行：

为了下次能自动启动，可以enable一下：

注意： 最好确保 ttyS0已经加入了 /etc/securetty :

然后就可以virsh console $domain 了

其实对应domain的console在宿主机是有一个tty的，如下方式查看：

如：

比较有趣的玩法是：

  1. 在终端1 去 cat /dev/pts/2
  2. 在终端2 去 echo -e “$username\n$password\necho hello world” >/dev/pts/2
  3. 在终端1就能看到输出
  4. 最后别忘了echo “exit” >/dev/pts/2 否则，下次不需要密码就进去了

为什么virsh console没有配置的时候，virt-manager依然能看到虚拟机的界面呢？virt-manager走的是vnc(或spice）方式，而且是宿主机里面提供的，和虚拟机里面是否有vnc（spice）没有关系。

 

通过ps也能查看：

默认情况下，虚拟机的vnc（或spice）会listen 127.0.0.1 上的端口，远程通过virt-manager访问的时候，如果使用ssh协议的话，会通过如下方式将vnc（或spice）端口重定向到本地：

然后在这个打开的流上进行vnc（或spice）协议，这个可就不想tty那么好模拟了

 

那么，kvm如何就能启动一个vnc，使得能够访问虚拟机呢？模拟硬件的tty？

 

参考： https://www.cnblogs.com/xieshengsen/p/6215168.html

virtio nic 在流量大时不可用的问题

表象：

kvm虚拟机vm的nic使用virio驱动，在vm流量大的时候，vm就直接断网了； 我们原本有多台vm的，但是其中几台已经多次出现断网的情况，重启vm就好使了；我以为这个vm有问题，后来其他的vm也出现类似问题，我才察觉，其实是这台vm的流量通常更高，出现问题的概率大而已。

虚拟机信息：

宿主机信息：

 

我的问题和 https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978 基本是一样的

 

解决办法：

重新attach网络接口：

  1. 查看接口信息
  2. 分离网络接口
  3. 挂载网络接口(网卡接口信息都是上面查看到的)
  4. 启动网卡
  5. xx

 

参考：

https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1050934

https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978

docker on openstack

场景，用docker做开发用的虚拟机，每个docker都有一个可以公开访问的IP地址。

由于docker和宿主机共享内核，一不小心可能会把整个宿主机搞挂，而且，docker热迁移也是个难题，所以，尽管openstack马上可以支持docker，我也不想让docker直接部署在计算节点；我的思路是，将docker部署在openstack管理的kvm虚拟机上，这样还能通过热迁移kvm的方式将容器迁移到别的计算节点。

 

注意事项：

  1. 关闭openstack的端口安全，注意：
    1. 需要先从安全组中拿掉
    2. 在管理员界面操作
  2. 热迁移后容器的IP地址在交换机上的mac地址与端口的映射不能及时更新
    1. 如果容器频繁地和外部通信的话，mac地址与端口的映射会被及时刷新
    2. 如果没能及时刷新的话，可以在与容器IP同网段的机器上，先clear一下arp缓存，在ping 一下容器IP，就可以了；
    3. 如何自动处理呢？在kvm虚拟机上（就是容器的宿主机上），docker exec到容器内部，然后ping一下网关就行。

linux 虚拟网络设备之vlan

我们通过一个网桥两个设备对，来连接两个网络名字空间，每个名字空间中创建两个vlan

借助vconfig来配置vlan：

 

查看一下vlan配置：

 

现在，我们可以分别在两个名字空间来ping另外一个名字空间的两个IP，虽然两个IP都能ping通，但是使用的源IP是不同的，走的vlan也是不同的，我们可以在veth01/veth10/veth02/veth20/br-test-vlan 任意一个上抓包，会看到vlan信息：

 

如果试图从veth10.3001 去ping 172.16.30.22 是不能通的，因为是不同的vlan呀：

 

不适用vconfig的解法：

另： vlan 一般以  设备名.vlanid 来命名，不过并非强制，如下命名为 vlan3003也是没问题的

注意：一个主设备上相同vlan好的子设备最多只能有一个

 

所以，正常来讲，一般是这样的：

 

参考： http://network.51cto.com/art/201504/473419.htm

http://www.mamicode.com/info-detail-2357921.html

ceph 之 ceph-bluestore-tool

ceph-bluestore-tool 可以对bluestore 文件系统进行检查：

注意： 必须把对应的osd停掉才行

ceph 之 mon quorum操作

取消某个mon的法人资格：

恢复一个mon的法人资格

不幸的是，该命令卡死不动；甚至，如果期望提示enter补全都会卡死不动; 哪怕是4个mon，exit一个再tell回来也是卡死的，所以，tell命令似乎只能取消法人资格，不能恢复法人资格

 

方法2： 直接在需要恢复法人资格的daemon上执行如下命令

当while read 遇上ssh

为什么第二条命令输出的不是a b c三行？

改进：

这里把ssh的标准输入关闭了，结果就正常了，可见，原来不能输出三行是有ssh的标准输入导致的

再次验证如下：

这里比较清晰地说明了b、c被ssh给读走了

如果不想费这心思，完全可以别走管道：

 

有时候就是这样，能用简单明了的写法，最好别摆酷

 

非图片版：

 

vxlan 问题排查

现象：

openstack中创建的vpc网络中，虚拟机不能dhcp到IP地址，抓包分析如下：

这是openstack控制节点的网络相关信息，问题是： vxlan-60中一个虚机想要通过dhcp获取IP地址，现在dhcp的数据包可以通过eth0到达brqce4d2a54-44，抓包可以验证 ：

但是vxlan-60上却抓不到dhcp数据包：

我觉得，到达了 brqce4d2a54-44 的vxlan数据包，如果vxlan id是60就直接转给vxlan-60 就是了，还可能被哪里的规则给拦截？问题都定位了这地步了，应该问题就出现在openstack-controller身上吧？不应该和其它机器有关系吧？（我不断祭出bridge fdb、brctl、ip等工具，浪费了有半天的时间）

后来，在我都试图想重启openstack-controller的时候，我决定分别在两个compute上创建两个机器，如果两个机器之间能够通信，则说明openstack-controller 的问题，否则，就不是openstack-controller的问题； 测试发现，两个机器不能通信，我才把重点放在了compute节点；

compute节点网络架构：

话说，这个网络和官方指导架构或者书本上指导的架构都不一样； 正常来讲，把bond0 添加到 /etc/neutron/plugins/ml2/linuxbridge_agent.ini 中就可以了，也不会出现今天的问题，因为最初是这样的，我测试vpc功能都是OK的；

加入我把bond0给了neutron，则neutron会将bond0的IP转移给brqce4d2a54-44 ， 由于机器有限，我需要在这些compute节点上起ceph node，ceph node也通过虚拟机提供存储服务（如上图的vnet0），如果让vnet0桥接到brqce4d2a54-44 上，总感觉不大好，于是，便有了上述的网络架构；

既然  /etc/neutron/plugins/ml2/linuxbridge_agent.ini  里面配置成了veth_neutron ,那么 /etc/neutron/plugins/ml2/linuxbridge_agent.ini 里面的 local_ip 也应该修改为 veth_neutron 的IP，不是吗？（当然不是，错就错在这儿了），于是我就这么改了

 

 

因为vxlan-60 的 dev 是brqce4d2a54-44 ，数据只有先到达brqce4d2a54-44  才可能进入vxlan-60 ；

我发现，进入的vxlan数据包首先是要走到bond0的，然后走到br0，我期望能通过veth_br0 到 veth_neutron ， 再到 brqce4d2a54-44 ，然后再到vxlan-60， 然而，实际情况是，vxlan数据包根本不进入veth_br0； 我猜测，很可能内核已经在分析vxlan数据包了，该给谁给谁，没人要就丢掉呗； 然而，vxlan-60是base在brqce4d2a54-44  上的，没有base在br0上； 如果让vxlan-60 base在br0上是不是就可以了呢？

关于vxlan-60 base在哪个设备是通过/etc/neutron/plugins/ml2/linuxbridge_agent.ini  里面的local_ip 来决定的，和 physical_interface_mappings 是不必相同的。

修改后，重启 neutron-linuxbridge-agent.service , 重新创建vpc， 问题解决。

 

思考：

为什么vxlan的目的IP是brqce4d2a54-44， 而实际却不能真正落到brqce4d2a54-44 上？