【已解决】通过Dashboard启动云主机后无法连接。

CentOS6.5，icehouse。
使用cirros-0.3.2-x86_64-disk.img作为镜像创建云主机，分配IP为10.0.1.4。

客户机与租户虚拟路由器的外部网关在同一网段，均为192.168.25.0/24，客户机上做了策略路由，可以ping通租户虚拟路由器的外部网关（192.168.25.51）和内部接口（10.0.1.1），但是无法ping通云主机的IP（10.0.1.4）。

后通过控制台登录云主机，ifconfig发现网卡eth0上没有IP地址。



请问，我是不是哪里操作错了？
还请高手指点一下。

顶一下，这个比较麻烦。
按照官方文档也不行，还是获取不到IP（云主机本身）。

原因找到了。
网络节点（虚拟机）的第二块网卡（GRE），跟计算节点的不在同一个网络，所以导致错误。

另，计算节点的dnsmasq没有启动。不知道会不会影响云主机？

分配一个浮动IP后，还是ping不通（访问&安全中的安全组规则已经开放入口的ICMP和SSH）。



计算节点日志如下：
2015-01-14 21:06:34.528 1638 WARNING nova.virt.disk.vfs.guestfs [req-106505af-b983-4d08-873b-e6dbb830ab4a a6fcfb1d08cb4d7f8d8097fe81f10076 e749593321444a89a2ab0359d52a8f88] Failed to close augeas aug_close: do_aug_close: you must call 'aug-init' first to initialize Augeas
2015-01-14 21:06:47.156 1638 WARNING nova.virt.libvirt.driver [req-106505af-b983-4d08-873b-e6dbb830ab4a a6fcfb1d08cb4d7f8d8097fe81f10076 e749593321444a89a2ab0359d52a8f88] Timeout waiting for vif plugging callback for instance 3b9ae081-c9b4-4e23-8335-e4d6e4837130

计算节点的nova.conf已经做了如下修改：

• vif_plugging_timeout = 10
  
• vif_plugging_is_fatal = False
  

网络节点：
[root@network ~]# ovs-vsctl show
913e4e40-5d42-4d02-8cb1-748f74788bdc
    Bridge br-int
        fail_mode: secure
        Port br-int
            Interface br-int
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port "qr-b7e16568-6c"
            tag: 2
            Interface "qr-b7e16568-6c"
                type: internal
        Port "tap671168d5-36"
            tag: 2
            Interface "tap671168d5-36"
                type: internal
    Bridge br-tun
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port br-tun
            Interface br-tun
                type: internal
        Port "gre-ac100a1f"
            Interface "gre-ac100a1f"
                type: gre
                options: {in_key=flow, local_ip="172.16.10.21", out_key=flow, remote_ip="172.16.10.31"}
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
        Port "qg-fbcbfabe-77"
            Interface "qg-fbcbfabe-77"
                type: internal
        Port "eth2"
            Interface "eth2"
    ovs_version: "2.1.3"
[root@network ~]#

计算节点：
[root@compute1 ~]# ovs-vsctl show
6de8d1ca-a456-4a75-86dd-cc4a7f460c43
    Bridge br-tun
        Port "gre-c0a8190c"#说明，这个是之前配错了，也删除了，后来不知道怎么又冒出来了。【该问题已解决】
            Interface "gre-c0a8190c"
                type: gre
                options: {in_key=flow, local_ip="172.16.10.31", out_key=flow, remote_ip="192.168.25.12"}
        Port "gre-ac100a15"
            Interface "gre-ac100a15"
                type: gre
                options: {in_key=flow, local_ip="172.16.10.31", out_key=flow, remote_ip="172.16.10.21"}
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port br-tun
            Interface br-tun
                type: internal
    Bridge br-int
        fail_mode: secure
        Port "qvoa90f72d0-bb"
            tag: 1
            Interface "qvoa90f72d0-bb"
        Port "qvo514d189d-e4"
            tag: 1
            Interface "qvo514d189d-e4"
        Port br-int
            Interface br-int
                type: internal
        Port "qvoead40042-f2"
            tag: 1
            Interface "qvoead40042-f2"
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
    ovs_version: "2.1.3"
[root@compute1 ~]#

marsaber 发表于 2015-1-14 20:12
另，计算节点的dnsmasq没有启动。不知道会不会影响云主机？

先把dnsmasq启动了

langke93 发表于 2015-1-14 22:23
先把dnsmasq启动了

谢谢您的回复，已经启动了，问题依旧。

marsaber 发表于 2015-1-14 22:42
谢谢您的回复，已经启动了，问题依旧。

网卡获取不到ip，原因很多
防火墙规则清除了吗？
用的是什么网络模式
重启过openvswitch 和openvswich agent 了吗？

langke93 发表于 2015-1-14 22:53
网卡获取不到ip，原因很多
防火墙规则清除了吗？
用的是什么网络模式

系统默认的防火墙都被清掉了，现在的规则是neutron或者openvswitch生成的。

网络模式该怎么查看？

计算节点的neutron-openvswitch-agent和openvswitch都重启过了。

dnsmasq进程是在neutron server进程所在的节点上的。不是启动计算节点上的dnsmasq。每个建立的租户都会有属于自己的dnsmasq进程

sheldon 发表于 2015-1-15 09:27
dnsmasq进程是在neutron server进程所在的节点上的。不是启动计算节点上的dnsmasq。每个建立的租户都会有属 ...

非常感谢您的回复。