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 上?

vxlan实践

vxlan 也能在单台机器上演示:

网络拓扑:

pic

执行命令:

  1. 创建两个网络名字空间:(相当于做了两个虚拟机)

     
  2. 创建一个设备对儿:

     
  3. 将设备对分别添加到两个名字空间:

     
  4.  进入名字空间进行配置:

     
  5. 进入另外一个名字空间进行类似配置:

     
  6. 通过ip link show veth01   和ip link show veth10, 查到:
    veth01 Mac: fe:ea:f2:aa:1f:fc
    veth0 Mac: ee:b4:c4:3f:b3:2b
  7. 添加转发表:
  8. 验证:

     
  9. 注意:我们在各自的名字空间内ping不到自己的IP,因为我们没有启动lo,启动lo就可以ping到自己了

 

参考: http://tech.mytrix.me/2017/04/vxlan-overlay-in-linux-bridge/