openstack节点备份、迁移、恢复，常见问题定位方法及修复方法，Openstack Neutron(网络)查错及解决，网络故障问题修复变更方案，故障排查及处理，openstack虚拟机磁盘故障处理

openstack节点备份、迁移、恢复，常见问题定位方法及修复方法，Openstack Neutron(网络)查错及解决，网络故障问题修复变更方案，故障排查及处理，openstack虚拟机磁盘故障处理。

OpenStack是一个广泛使用的云计算平台，其中，Neutron是负责网络服务的组件。Neutron提供诸如虚拟网络、IP地址管理、防火墙等功能。然而，由于配置、网络策略或其他环境因素的影响，Neutron在实际运用中可能会出现故障。

故障排查步骤
当Neutron出现故障时，可以按照以下步骤进行排查：

检查Neutron服务状态：
首先，检查所有Neutron服务是否正常运行。可以通过以下命令来查看服务状态：

openstack service list

确保所有Neutron相关的服务（如neutron-server、neutron-agent等）都处于“enabled”状态。

查看日志文件：
Neutron相关的日志会记录故障信息，通常位于/var/log/neutron/目录下。特别要注意neutron-server.log和neutron-agent.log文件，寻找错误信息或异常提示。

网络状态检查：
使用以下命令检查网络及其状态：

openstack network list
openstack subnet list

确认网络和子网的状态是否正常，通常应该显示为“ACTIVE”。

故障处理示例
假设在使用Neutron时无法创建或使用虚拟网络，可能是由于网络服务未正常工作。以下是处理逻辑的状态图，帮助理解故障原因及后续处理步骤：

修复网络配置
在处理网络配置时，如果发现某个网络的配置有误，可以使用命令行工具进行修复，例如：

openstack network set --admin-state-up my-network

该命令将名为my-network的网络状态设置为“UP”，使其可用。

故障恢复的过程
如果问题依旧存在，那么我们可能需要重启Neutron服务。可以通过以下命令来重启相关服务：

sudo systemctl restart neutron-server
sudo systemctl restart neutron-openvswitch-agent

接下来，通过一个序列图展示故障恢复的过程：

OpenStack Neutron的故障排查和处理是一项系统化的工作。在遇到问题时，建议从服务状态、日志文件、网络状态等方面入手进行排查。通过检查和重启服务，大部分问题可以有效解决。

先了解一下 openstack中neutron的主要概念和工作原理：

API server
API Server是 Neutron 的控制器，用户对网络资源的请求全部先交由 API Server 处理。 API Server 接到用户的请求后，会调用后端插件进行具体的任务实现。

网络插件和代理
Neutron 提供了灵活多样的网络插件和代理供用户选用，以便用户可以部署适合自身 的云环境网络。

插件与代理的主要功能在于实现由 API Server 转发的网络资源请求，如网络端口的插拔、路由增删、网络和子网创建以及提供 IP 地址等。

网络插件和代理的选取依赖于用户网络设备的厂家，个人理解为网络设备的驱动

Neutron网络概述
为了实现不同租户网络互相隔离，Neutron 提供了几种不同的网络拓扑与隔离技术，

1、Flat网络
在 Flat 网络中，不同计算节点上的全部实例接人同一个大二层网络内，全部实例共享此网络，不存在 VLAN 标记或其他网络隔离技术。

可以同时部署多个隔离的 Flat 网络，但是每个 Flat网络都要独占一个物理网卡

2、VLAN网络
VLAN 网络允许用户使用外部物理网络中的 VLAN ID 创建多个租户或供应商网络。

VLAN 网络通过 VLAN ID 进行二层网络的隔离，相同 VLAN ID 内部的实例可以实现自由 通信，而不同 VLAN 之间的实例通信则需要经过三层路由的转发。

由于 VLAN 网络可以实 现灵活多样的网络划分与隔离，故 VLAN 网络是生产环境中使用最为普遍的网络.

但是由于vlan仅有4064个，所以vlan主要用于私有云网络。

3、GRE和VxLAN
GRE 和 VxLAN 是一种网络封装协议

两者都是基于2次封装，类似vpn技术。
两者区别在于 GRE网络通过IP包进行数据传输，而VxLan通过UDP包进行数据传输，GRE或者VxLAN数据库包在流出节点之前会被打上相应的 GRE 或 VxLAN 网络 ID (Segmentation ID），而在进入节点后对应的ID会被剥离，之后再进入节点内部的虚拟网络进行数据转发。
GRE和VxLAN网络中的数据量要进入外部网络，必须配置路由器。

端口
端口port在 OpenStack 网络中是一种虚拟接口设备，用于模拟物理网络接口。

在 Neutron 中，端口是网络设备连接到某个虚拟网络的接人点，如虚拟机的 NIC 只能通过端口接入虚拟网络，端口还描述了与网络相关的配置，如配置到端口上的 MAC 和 IP

命名空间
在 Linux 系统中，网络命名空间（ Network Namespace）就是一个虚拟的网络设备， 网络命名空间有独立的路由表、 iptables 策略和接口设备等，网络命名空间彼此之间完全隔离。
假设系统中有 eth0 和 ethl 两个网卡设备，且 eth0 属于命名空间 namespacel ，而 etbl 属于 命名空间 namespace2 ，则 eth0 和 eth1 就类似于两个独立网络设备上的接口，彼此相互独立，而且只有进入各自的命名空间后，才能够对命名空间中的接口设备进行配置更改与查看。
因此，如果 eth0 和 ethl 加入各自的命名空间后，在 Linux 系统中，针对全局系统的网 络配置命令 ifconfig 是不能看到这两个网卡设备的相关配置信息的，必须进入各自的命名空间使用此命令才能看到相关信息。 在 Linux 中，使用命令 ip netns 可以查看系统中的全部网络命名空间，要配置或者查看命名空间中的设备，则需要进入特定命名空间并在命名空间 中执行相应命令。
例如，当前系统中有一个路由命名空间 qrouter-xxx，想要查看该命名空 间中的接口和 IP 配置情况，可以执行命令：
ip netns exec qroute-xxx ip addr show

Neutron 网络组件、架构与内部通讯
在 OpenStack 的模块架构中，网络是个代号为 Neutron 的独立社区项目，同 Compute、 Image 和 Identity 等项目一样， Neutron 的服务部署也需要跨越多个节点。
在 OpenStack 中，网络服务使用 Neutron-server 进程提供服务 API 接口，用户通过 Neutron-server 提供的 API 可以进行网络插件的管理配置。
通常为了实现网络配置数据的永久性存储，网络插件需要访问 OpenStack 的中心数据库。
Neutron-server 不仅向云用户提供网络服务API，还向计算服务 Nova 和控制面板服务 Horizon 提供网络资源请求 API。
同时 Neutron-server 与 Neutron 插件需要访问 Keystone 服务以进行身份验证，而为了实现彼此交互。
Neutron 的服务代理与插件需要访问消息队列服务。
其组件主要包括Neutron Server、插件代理 Plugin Agent、DHCP代理、L3代理和计量代理：
Neutron 内部各个组件代理与 Neutron Server 和 Plugins 之间以 RPC 的形式进行通信， 而 SDN Service 以 REST APis 的形式访问 Neutron Server 和相应的插件代理。 （现在REST较为流行（如对象存储的调用），早期的项目多使用RPC调用，RPC调用不透明，无法感知调用结果。REST调用采用http的报文，可用http回复的状态字节判断状态。）
Neutron Server
Neutron Server 主要负责对外提供openstack网络服务API及扩展。API接受请求后负责调用相应的Plugin进行请求处理。

而Plugin又负责调用Plugin Agent进行最终的任务处理并维护Openstack网络逻辑状态

主要运行在网络节点上，其组件包括Neutron Server服务进程和Neutron-*-plugin服务。或者说 Server API与插件构成了Neutron Server

API 接收请求后负责调用相应的 Plugin 进行请求处理，而 Plugin 又负责调用 Plugin Agent 进行最终的任务处理并维护 OpenStack 网络逻辑状态，因此Plugin 是 Neutron 中主要的数据库访问者。

1、Plugin Agent
租户网络服务请求在经过 Neutron Server 和 Plugin 之后，最终通过 Plugin Agent 来实现租户网络请求任务。

Plugin Agent ( neutron-*-agent）服务主要运行在计算节点并管理本地 虚拟交换机配置，用户选用的 Plugin 决定了计算节点所运行的 Plugin Agent，因为 Plugin 与 Agent 总是相互对应的。

插件代理服务需要访问消息队列以便和插件服务进行交互，同时插件代理需要访问数据库以便存储网络变更信息。 因此插件代理也是 Neutron 中主要的数据库访问者。

2、DHCP Agent
为租户提供DHCP服务，对neutron支持的全部网络plugins都是相同的，不依赖用户选择的Plugin

3、L3 Agent
L3 agent在provider类型的网络中并不是必须的，在self-servece网络中却是必须的。主要为外网访问租户网络中的虚拟机提供L3 route功能，L3 Agent也需要访问消息队列。

4、Network Provider Service
又称为SDN service 主要是向租户网络提供额外的网络服务

Neutron Plugin 与 Agent

Neutron plugin

从代码层面而言，插件是“可插拔（ Pluggable）”的 Python 类和函数，这些 Python 类 在 Neutron API 响应请求时被触发，同时插件在 Neutron Server 服务启动时加载，加载完成后插件被当成 Neutron Server 的一部分而运行。

用户对插件的实现可以是完整性（ Monolithic）的也可以是模块式 (Moduler）的。由于其实现过程较为复杂， Monolithic 形式的插件正被逐步淘汰，取而代之的是 Moduler 插件，其中最为成功的便是 Moduler Layer2，即 ML2 插件。

Neutron 的众多插件可以被归为两类 即 Core 插件和 Service 插件。

Core 插件实现的是 Neutron 中的 Core API，其主要负责 L2 网络通信和 IP 管理，如网络、子网、 子网池和端口 的创建与删除。 如ML2
Service 插件实现了 Neutron 中的扩展 API，并负责提供三层、四层和七层 的高级网络服务，如 L3 路由、防火墙、 VPN 与负载均衡等。
扩展：ML2插件详解
ML2 插件解耦了对不同网络驱动的调用，它将驱动分为两个部分， 即 TyperDriver 和 MechanismDriver。 在 Neutron 网络中， TyperDriver 代表不同的网络隔离类型（ Segmentation Type），如 Flat、 Local、 VLAN、 GRE 和 VxLAN

TyperDriver 负责维护特定类型网络所需的状态信息、执行 Provider 网络验证和租户网络分配等工作，而 MechanismDriver 主要负责提取 TyperDriver 所建立的信息并确保将其正确应用到用户启用的特定网络机制（ Networking Mechanism）中。

尽管 ML2 插件是个单一整体的插件，但是 ML2 插件支持多种 TyperDriver 和 MechanismDriver，并且不同的 MechanismDriver 所支持的 TyperDriver 种类不一样， 如 LinuxBridge 和 OpevSwitch 两种 MechanismDriver 都支持 Flat、 VLAN、 VXLAN 和 GRE这 4 种 TyperDriver，而 L2 population 仅支持 VXLAN 和 GRE这 2 种 TyperDriver，这意味着在启动 L2 population 时，用户不能使用 Flat 和 VLAN 进行租户网络的隔离。

ML2插件 typerdriver和MechanismDriver彼此支持矩阵：

ML2插件最大优势在于，可以并行使用不同开源软件或者厂家网络技术。

而这在ML2插件之前是不允许的。例如LinuxBridge和OpenvSwitch插件必须独立使用：

而使用ML2插件：
Plugin 必须与 Agent一一对应的硬性要求被屏蔽，即 ML2 插件可与多个 Agent 协同工作

Agents
Neutron Server 服务扮演的是网络控制中心的角色（通常 Neutron Server 服务也会部署在控制节点上），而实际上与网络相关的命令和配置主要在网络节点和 各个计算节点上执行，位于这些节点上的 Agents 便是与网络相关命令的实际执行者.

类似Plugin的Core 插件和 Service 插件， Agents 可以划分为 L2 Agents 与非 L2 Agents 两大类。

L2 Agents如 OpenvSwitch agent、 LinuxBridge Agent、 SRIOV nic switch Agent 和 Hyper-V Agent 等。 L2 Agents 主要负责处理 OpenStack 中的二层网络通信，是 Neutron 网络中最为核心的部分。
非 L2 Agents 主要包括 L3 Agent、 DHCP Agent 和 Metadata Agent 等。 L3 Agent 负责 L3 层服务，如路由和 Floating IP ; DHCP Agent 负责 Neutron 网络的 DHCP 服务， Metadata Agent 允许用户实例通过网络 访问 Cloud-init 元数据和用户数据。 Agents 所获取的消息或指令来自消息队列总线，并且由 Neutron Server 或 Plugins 发出。
由于 Agents 负责网络的具体实现，因此 Agents 与特定 的网络技术、 Plugins 密切相关，如使用 OpenvSwitch Agent 则意味着通过 OpenvSwitch 技 术来实现虚拟网络，并且其对应的插件是 OpenvSwitch Plugin （被 ML2 插件取代）。

图 所示是 ML2 插件协同 OpenvSwitch Agent 与 Neutron 中的其他网络服务进行交互的简单流程。

在图 所示中， Neutron Server 接收到客户端的 API 请求后，触发 ML2 插件进行请求处理， 由于 ML2 插件已经加载了 OVS Mechanism Driver （即 OpenvSwitch 插 件），于是 ML2 插件将请求转发给 ovs 驱动， ovs 驱动收到请求后使用其中的可用信息创建 RPC 消息， RPC 消息以 Cast 形式投递到计算节点上特定的 OVS Agent，计算节点上的 OVS Agent 接收到消息后便开始配置本地 OpenvSwitch 交换机实例。

与Plagin类似，Agent与Mechanism Driver也存在对应关系

通过以上分析可以看出，Neutron 的功能模块主要由 API Server、 Plugin 和 Agent 组成，其中 API Server 和 Plugins 主要由 Neutron-Server 服务运行，并且 Neutron 推荐的核心 Plugin 为 ML2 插件。

---

Neutron L3 Service 分析
在 Neutron 中， L3 Service 是个非常关键的服务， 其主要提供虚拟机不同 L2 子网之 间的 L3 路由，以及虚拟机与外网之间的 SNAT 和基于 Floating IP 的 DNAT 功能，如果 Open Stack 网络中未部署 L3 服务，则用户只能部署基于 Provider 的网络，而无法实现真正 的云计算 Self-Service 网络。

L3 Service 主要由 L3 Service 插件及其 API 和对应的 L3 Agent 组成，其中 L3 Service 插件和 API 由 Neutron-Service 服务来运行。通常部署在控制节点 上，而 L3 Agent 可以部署在控制节点上，也可以部署在网络节点上。

但是从 OpenStack 的 Juno 版本开始， L3 Agent 也可以部署在计算节点上以实现分布式虚拟路由（ Distributed Vritual Router, DVR）功能。

在实际工作中， Neutron 以 RESTful 的形式提供了两种类型的 API 服务，即 Core API 和 Extension API。 通过 Neutron 的 Core API，管理员可以创建网络、子网和端口等核心网络要素。通过 Extension API，管理员可以创建虚拟 Router、 LoadBalance、 VPN 和 Firewall 等高级的网络功能。

与 Neutron 的 Core API 和 Extension API 对应的是 Core Plugins 和 Service Plugins, Neutron Server 中的 API Server 在接收到请求后， 会调用相应的 Plugins 来 响应用户发起的网络资源请求。

Core Plugins 主要用于定义二层网络的网络类型以及网络接 口驱动等底层核心功能。

Service Plugins 主要用于定义 L3 Router 等三层以上的网络高级功能。

通常情况下，租户可以通过 L3 Plugin 提供的 APJ 创建虚拟 Router 和 Floating IP，并通 过Nova 的 API 将 Floating IP 绑定到实例上，从而实现租户内网与外网的通信。

---

L3 Service 服务过程梳理
插件加载。
位于控制节点的 Neutron-Server 在启动时加载 L3 Service 插件， L3 Service 插件主要负责响应和处理用户对三层网络服务的 REST 请求，并将请求以 RPCcast 形式通过消息队列传递给网络节点上的 L3 Agent 进行最终处理。

L3 Agent 注册。
L3 Agent 通常运行在网络节点上， L3 Agent 服务启动后，通过消息 队列将自身注册到位于控制节点上的 L3 Service Plugin 中，以作为 Router Scheduler 对象供 口 Plugin 调用。 L3 Agent 实现由 Neutron AP！请求的虚拟路由功能。

虚拟路由管理。
网络节点上的 L3 Agent 根据控制节点 L3 Service Plugin 传递的配置 参数进行本地（网络节点）虚拟路由的管理。

路由功能实现。
Neutron L3 Agent 使用 Linux Nam esp ace 和 iptables 规则实现虚拟路 由功能。

路由隔离。
Namespace 提供了隔离的网络樵（ Network Stack） 空间，每个网络枝命 名空间中都有属于自己的 Routing tables 和 iptables 规则，由于网络梳命名空间彼此隔离， IP 地址可以在命名空间限制范围内重复使用。

路由创建。
L3 Agent 在网络节点上为租户网络中的每一个虚拟路由创建一个命名空 间，之后在命名空间中创建相应的虚拟路由端口 。

添加租户子网接口 。
当用户将租户子网在接入虚拟路由时，对应命名空间中虚拟路 由接口被标记到集成网桥上（通常以 br-int 表示），标记 ID 为租户网络的 Segmentation ID。

设置外网网关。
命名空间中的虚拟路由包含一个外网（通常以 br-ex 表示）的网关 接口 。

路由功能实现。
L3 Router 将 iptables 规则应用到命名空间虚拟路由网关接口上以实 现 DNAT (Floating IP）和 SNAT 功能。

---

L3 Router的工作流程
为了举例说明 L3 Router 的工作流程， 这里以部署一套常见的三层（Web-App-DB) Web 应用云虚拟机和租户网络为例。

由于要求 Web、 App 和 DB 分别处于不同的网 络，因此租户需要分别创建三个网络 webnet、 app-net 和 db-net，同时在三个网络上分别启动用于 Web、 App 和 DB 应用的实 例 web-server、 app-server 和 db-server。

由于 Web 服务器需要访问 App 服务器，同时 App 服务器需要访问 DB，因此需要创建一个虚拟路由，并将三个网络同时接人路由，同时需要为路由设置外网网关以便外网可以 访问 Web 服务器。 网络和实例创建完成后。

在上述虚拟路由的创建、子网接入和网关设置过程中， L3 Agent会为命名空间中的虚拟路由创建对应三个网络的三个端口，并将三个端口绑定到集成网桥 br-int 上.

为了进行网络隔离，绑定到 br-int 上的每个接口都会被打上与租户网络对应的 Local VLAN ID。 当各个租户网络跨越物理节点进行网络通信时，具有各自 Local VLAN ID 的网络数据在进入隧道（ Tunnels）之前， Local VLAN ID 会被隧道网桥（ br-tun）映射成为 Segmentation ID。

图 9-17 所示中，网络节点中三个 DHCP 服务器分别为三个租户网络的实例提供 DHCP 服务，而三个租户网络均接入同一个虚拟路由，只是在 br-int 上创建了三个具有不同 Tag 的端口， 如 qr- ( <web＞代表租户 Web 网络 ID）、 qr-<app＞和 qr-<db＞，而对应的 VLAN Tag 分别为 1 、 2 和 3。

如果外部网络需要访问租户内网，则必须经过虚拟路由的网关接口才能实现，而如果租户内部私网在不同节点之间通信，则需要经过隧道网桥 br-tun，并通过 VxLAN 封装协议来实现。 在多数情况下，Neutron 的上述 L3 工作方式可以正常应对 OpenStack 灵活复杂的网络要求，但是这种 L3 功能集中部署的方式存在固有的限制，而这 种限制极大影响了整个 OpenStack 集群的性能和可扩展性。

在上述 3-Tier Web 应用服务器 部署示例中，除了租户私网与外网的南北向通信外，租户不同子网之间的通信数据流也要全部经过网络节点，这就意味着位于不同计算节点上的实例之间进行通信，其数据流也要进出网络节点， 即所有计算节点的数据流都要先汇聚到网络节点才能进行彼此通信。

而正常情况下， Web 服务器对 App 服务器的网络访问和 App 对 DB 的访问都不应该绕到网络节点，而是在两台服务器的宿主计算节点之间便可直接进行，然而由于计算节点没有 L3 Agent，因此全部计算节点的数据流都必须集中到部署了 L3 Agent 的网络节点。

在小规模的 OpenStack 集群中 ，计算节点数目较小的情况下，上述 L3 Agent 集中的网络部署形式对集群性能的影响可能不是很明显，但是随着集群规模的扩大，计算节点数目 变得越来越多，计算节点上的虚拟机之间的通信也变得越来越频繁，此时的网络负载便会出现质的提升，因此网络瓶颈将会十分突出。

在 L3 Agent 集中部署到网络节点的情况下，单一的网络节点很可能因为过大的网络负载而出现各种性能问题。 为了解决这一问题，从 Juno 版本开始，社区引入了分布式虚拟路由 DVR ( Distributed Vritual Router）功能。

DVR 的主旨思想就是将 L3 Agent 的功能由网络节点分布到计算节点，从而让计算节点分流单一网络节点上的网络负载。 OpenStack Juno 版本发行后， DVR 功能被实现， L3 Service 的 L3 Agent 可以部署到计算节点，计算节点实例无须再到网络节点获取 L3 Routing 服务，网络节点仅负责 L3 SNAT 功能，其余 L3 Routing 功能被分散到各个计算节点。

但是在启用 DVR 模式的情况下，用 户不能启用 Neutron 的 L3 HA 功能。 不过在 Mitaka 版本发行后， DVR 与 L3 HA 的冲突限制被解决，当计算节点启用 DVR 模式时，网络节点的 L3 SNAT 可以启用基于 VRRP 协议的 L3 SNAT 高可用功能，即 Mitaka 版本中的 Neutron 实现了 L3 Service 全部功能的高可用。

---

Neutron网络类型
Neutron 提供了两种网络类型，即租户Self-Service网络（Project Network 后者又称 Tenant 网络）和供应商网络（ Provider Network）。

二者主要区别在于 Provider 网络只能由云管理员创建，并且实例仅可接入 Provider 网络 （又称外部网络或物理网络）， Provider 网络中不存在租户私网，也没有 L3 路由和 Floating IP 地址，同时 Provider 网络仅支持 Flat 和 VLAN 网络类型；

Tenant 网络是对 Provider 的扩展， 在租户可以创建 Tenant 网络之前必须先由云管理员创建 Provider 网络， Tenant 网络具有 L3 服务， 因此实例可以接人租户私网，除了云管理员，其他非授权用户也可以自助管理和使用 Tenant网络， 包括用以将私网与外网进行互联的 Router。 在 Tenant 网络中 ，外部网络（如 Internet）对接人私网的实例访问通过 Floating IP 来实现。

Provider Network
Provider 网络是一种仅实现二层 网络虚拟化，LoadBlancer、 Firewall 等高级功能的 Neutron 网络类型，相对而言， Provider 是一种半虚拟化的网络。 在 Provider 中 ，三层以上的功能不被虚拟化，而是借助物理网络设备来实现。

在 Provider 网络中，由于二层网络直接接入物理设备，二层网络之间的通信也由物理设备进行转发，因此 Provider 网络在实现过程中无须口服务，控制节点只需部署 API Server、 ML2 核心插件及 DHCP 和 Linux bridging 代理即可。

计算节点中的实例通过虚拟二层交换机直接接人物理网络，因此计算节点只需部署如 Open vSwitch 或 Linux bridging 等代理软件即可。

Provider 网络拓扑架构很简单，只需在控制节点和计算节点中分别规划一块物理网卡， 并将其接入物理网络即可。 如果采用的是 VLAN 网络，则将交换机接口配置为 Trunk 模式， 节点只需一块物理网卡便可通过多个 VLAN ID 来实现不同网络的隔离。 如果采用的是 Flat网络，由于 Flat 网络没有 Tagging，如要配置多个 Flat 网络则需要节点提供同样数量的物理网卡。

在 Provider 网络中，实例直接接人 Provider 网络（外部网络，如 192.168.115.0/24 ), 因此也不存在私有网络和虚拟路由设备的概念，同时也无须 Floating IP，即实例虚拟接口上获取的就是外网 IP。 外部网络可以直接访问位于 Provider网络上的虚拟机实例，而访问控制由计算节点上的防火墙规则来实现。

外网对实例的访问需要经过两个阶段，即 Provider 物理网络和 Provider 虚拟网络（如图 9-23 所示）。 Provider 物理和虚拟网络属于同一个网 络（ 192.168.115.0/24 ），只是网络被分为物理实现和虚拟实现，即节点内部为虚拟网络，而节点外部为物理设备网络。

Self-Service 网络
Self-Service 网络不仅提供了二层网络功能，还提供了三层路由转发和 VPN、 LoadBlancer、 Firewall 等高级网络功能。 在 Self-Service 网络中，租户可以自主创建和管理属于自己的多个租户子网（私有网络）并分配任意有效的私网 IP 地址，不同租户子网之间和租户私网与外网之间通过 L3 路由进行转发。 除了 Flat 和 VLAN 网络， Tenant 还 支持 GRE 和 VxLAN 等 Overlay 形式的租户网络隔离方式。

与 Provider 网络不同， Self-Service 网络的 L3 层功能采用虚拟技术来实现，因此 Self-Service 网络在实现过程中需要运行更多的网络服务组件。 由于部署 Self-Service 网络之前， 必须首先实现 Provider 网络，因此 Self-Servic巳网络的服务布局相对于 Provider 主要是多了 L3 Agent。

在租户可以创建 Self-Service 网络之前，管理员必须事先创建 Provider 网络， 然后租户创建的 Self-Service 网络通过 NAT 形式接入 Provider 物理网络。

计算节点上的实例创建时，接入 Self-Service 网络的实例可以直接访问外部网络（如 Internet） 。 但是，外部网络要访问计算节点实例，则必须通过实例 Floating IP，并通过 DNAT 才可实现。 Self-Service 网络通常使用 GRE 或 VxLAN 这类 Overlay 网络，即将虚拟网络进行封装后叠加（ Overlay) 到物理网络上进行传输。 由于 Self-Service 本身是租户内部私有网络（虚拟网络）， SelfService 网络中不同节点之间要实现互通，需要借助隧道（ Tunnel）封装技术来实现（如 GRE 或 VxLAN），通常节点之间的 Tunnel 建立在物理管理网络之上（ Management Physical Network), Self-Service 网络拓扑如图 9-25 所示。 图 9-25 中，由于 Self-Service 网络建立在 Provider 网络基础之上，因此 Self-Service 网络中可以并存 Provider 网络。

如前文所述， Provider 网络仅支持 Flat 和 VLAN 网络，而 Self-Service 网络中可以并 存 Provider 网络，因此 Self-Service 网络支持 Flat、 VLAN、 GRE 和 VxLAN 网络类型，并 且 Self-Service 网络中的实例也可以直接接入 Provider 物理网络，并使用 Flat 或 VLAN 方 式进行网络隔离。

一般情况下，在创建 Self-Service 网络后，计算节点实例通常接入 SelfService 网络， Self-Service 网络再通过 L3 路由接入 Provider 物理网络，并且 Self-Service 中的网络类型通常采用 GRE 或 VxLAN。

当实例创建完成并接人 SelιService 网络后，通常需要在 Provider 物理网络中创建 Floating IP 并将其绑定到实例上，以使得外部网络可以直接访问实例，这里实例从 Self-Service 网络中获取的 IP 称为固定 IP (Fixed ID），而租户从 Provider 物理网络中获取并绑定到实例的 IP 称为浮动 IP。

浮动 IP 可以解绑定之后重新分配给其他实例（如果将实例直接接入 Provider 网络，则不存在固定 IP 与浮动 IP 的概念）。 Self-Service 网络内部的通信过程如图 9-26 所示。 图中不仅有 Self-Service 网络， 还存在 Provider 网络。

---

Provider 网络部署与分析
Provider 网络（或者物理网络）是 Neutron 网络部署中一种拓扑简单、 性能优异、 可靠性较好的网络架构，但是 Neutron Provider 网络的这些优点是基于物理网络设备实现的，因此 Provider网络本质上不具备云计算网络的弹性按需和灵活操作等特性。

Provider 网络基于 OpenvSwitch 实现
Neutron 的 Provider 网络可以通过各种开源或厂商的网络插件和代理来实现，在开源领域，使用最多的是 ML2 网络插件和代理。
其中， ML2 插件通常部署在控制节点上，而 LinuxBridge 代理或 OpenvSwitch 代理部署在计算节点上。
Provider 网络不需要网络节点。本节主要介绍基于 OpenvSwitch 开源网络技术的 Provider 网络部署实现，后一节将介绍基于 LinuxBridge 网络技术的 Provider 网络部署实现。 为了便 于介绍，这里以部署一个控制节点和两个计算节点组成的 VLAN 类型 Provider 网络为例。

控制节点和计算节点均至少需要两个网络接口，其中 InterfaceI 作为管理接口（管理网络为 10.0.0.0/24 ), lnterface2 作为 Provider 接口 。 各个节点的 Provider 接口 Interface2 接人常规物理网络中（物理交换机或路由到外部的网络）， Provider 网络接口上需要一个端口用于 OpenvSwitch 桥接，作为桥接用的物理网络端口不配置 IP。

Neutron 网络服务在控制节点和两个计算节点 上，其中，控制节点运行网 络管理服务 Neutron-Server、 ML2 插件、 DHCP 代理和 OpenvSwitch 软件及其代理服务，计算节 点除了运行 Nova-compute 服务之外，还需运行 ML2 插件、 OpenvSwitch 软件及其代理服务。

provider 网络架构
在 Provider 网络的常规架构中 ， 控制节点主要包括 OpenvSwitch Agent 和 DHCP Agent 网络组件，

其中， OpenvSwitch Agent 主要负责节点内部虚拟交换机的管理及其通信，同时还负责通过虚拟端口与其他网络组件进行交互，如命名空间 Namespace 或其他底层的接口 。

DHCP Agent 主要负责管理 DHCP 命名空间， DHCP 命名空间主要负责为使用 Provider 网络 的实例自动分发 IP。

与控制节点不同，计算节点主要运行的网络组件是 OpenvSwitch Agent 和 LinuxBridge Agent，其中 OpenvSwitch Agent 主要负责节点内部虚拟交换机的管理及其通信，同时还负责通过虚拟端口与其他网络组件的交互，如 LinuxBridge 或其他底层的网络接口 。

使用 OpenvSwitch Agent还需要使用LinuxBridge 的原因是传统 LinuxBridge 对安全组（ SecurityGroups）的处理要优于原生的 ovs 实现.

provider 南北向流量分析

如果位于计算节点上的实例发送一个数据包到外网中的主机上， 则计算节点将产生如下的操作：

首先实例 Tap 接口将数据转发到节点内部的 LinuxBridge 网桥 qbr 上，由于目标主机位于其他网络，实例发出的数据包中包含目标主机的 MAC 地址，数据进入 qbr 后，其上的安全组规则对数据包进行状态跟踪和防火墙处理。

之后 qbr 将数据转发到 OpenvSwitch 的集成网桥 br-int 上，集成网桥 br-int 为数据包添加与 Provider Network 对应的内部标记（ Internal tag） 。

然后 hr-int 将数据转发到 OpenvSwitch 的 ProviderBridge 网桥 br-ex 上， br-ex 用实际的 ProviderNetwork VLAN ID 替换掉 hr-int 添加的 Internal tag。

最后 br-ex 通过计算节点的 Provider 网络接口将数据包转发到物理网络设备上。

数据包进入物理网络设备后，将进行如下的操作：

首先由交换机处理 Provider Network 与路由之间的 VLAN tag 操作；

然后路由器将来自 Provider Network 的数据包路 由到外部网络，交换机再次处理路由器与外网之间的 VLAN tag 操作；

最后交换机将数据 包转发到外网。

外网主机对 Provider 网络中的实例访问过程与实例对外网主机的访问过程 正好相反。

provider 东西向流量分析
Provider 网络东西数据流分为两种类型，即位于相同网段中的实例通信和不同网段之间的实例通信。 二者的区别在于， 不同 Provider 网段之间的实例通信需要具备三层路由功能的物理网络设备进行路由转发， 而相同 Provider 网络中的实例通信只需二层物理交换机进行转发。

provider网络的部署\创建\验证
基于openvswitch和linuxbridge的provider网络的部署,创建,和验证详见书籍P418

Self-Service网络部署和高可用
在实现 Self-Service 网络之前管理员必须已经实现 Provider 网络，因此在 Self-Service 网络中，用户也可以直接使用 Provider 网络，并将实例直接接人 Provider 物理网络而不是租户私有云网络。

与基于 OpenvSwitch 的 Provider 网络类似， Self-Service 网络的网络插件仍 然选择 ML2 核心插件，而不是 OpenVS witch Plugin （此插件已被 ML2 替换），同时代理选择 OpenvSwitch Agent，而 ML2 的 MechanismDriver 选择 ovs （即 OpenvSwitch）

在最简单的三节点 Self-Service 网络部署中，为了 Project 网络既可以使用 VLAN 类型，也可以使用 GRE/VxLAN 类型，控制节点至少需要一个网络接口（管理网络），网络节点至少需要四个网络接口（管理网络、 隧道网络、 VLAN 网络和外部网络），计算节点至少需要三个网络接口（管理网络、隧道网络和 VLAN 网络）。需要指出的是，如果 External 网络和 Project 网络都采用 VLAN 类型，则节点互联的物理网络设备必须支持 VLAN tagging。

---

计算节点上除了运行 Nova-compute 服务外，还运行 Neutron 的 ML2 插件和 OpenvSwitch 软件及其代理 Agent;控制节点主要运行 Neutron-Server 和 ML2 插件,网络节点运行 OpenvSwitch 软件及其 Agent、ML2 插件、L3 Agent、DHCP Agent 和 Metadata Agent。

每个计算节点都有 VLAN 网络和 Tunnel 网络， 而网络节点包括 VLAN 网络、 Tunnel 网络和外部网络。

需要指出的是，计算节点和网络节点上并非同时需要 VLAN 网络和 Tunnel 网络。 根据 Project 网络类型，用户也可以只部署 VLAN 网络或 Tunnel 网络。 如 Project 网络为 GRE/VxLAN 类型 ，则仅需要 Tunnel 网络，如果 Project 网络为 VLAN，则仅需要 VLAN 网络。

网络节点
网络节点主要包括 OpenvSwitch Agent、 DHCP Agent、 Metadata Agent 和 L3 Agent。

OpenvSwitch Agent 主要负责管理虚拟交换机及其通信，以及通过虚拟交换机端口与其他网络组件的交互，如命名空间 LinuxBridge 和其他底层网络接口；

DHCP Agent 管理 DHCP 命名空间，主要负责为 Project 网络中的实例自动分配 IP;

L3 Agent 主要负责管理 qrouter 命名空间； qrouter 命名空间负责 Project 网络与 External 网络以及 Project 网络之间 的连接，同时还负责路由实例与 Metadata Agent 之间的元数据信息；而 Metadata Agent 主要负责实例元数据相关操作。

计算节点
计算节点主要运行的网络组件是 OpenvSwitch Agent 和 LinuxBridge Agent。

OpenvSwitch Agent 主要负责节点内部虚拟交换机的管理及其通信，同时还负责通过虚拟交换机端口与其他网络组件的交互，如 LinuxBridge 或其他底层的网络接口；

而 LinuxBridge Agent 主要用于处理与实例相关的安全组问题。

Self-Service 网络南北数据流分析
南北数据通信分为两种情况，即 Fixed IP 形式的南北网络通信 和 Floating IP 形式的南北网络通信。

对于仅有 Fixed IP 而没有为其绑定 Floating IP 的实例， 网络节点的 Router 负责 Project 网络与 External 网络的通信路由.

---

openstack 虚拟机磁盘故障处理

系统磁盘损坏

前提：disk文件为文件存储类型的云主机。

步骤：

1、查看损坏OS云主机所在宿主机 nova show 

   2、找到或创建一台与损坏云主机OS版本一致的云主机

   3、将损坏云主机A的磁盘文件disk拷贝一份至用于修复云主机B disk_bak

ls /var/lib/nova/instances/8a902cdf-2967-48c0-b928-df46544c78d5/disk_bak

-rw-r--r-- 1 root root 36662149120 6月  25 15:29 disk_bak

4、在修云主机B目录下创建xml文件

相关target 信息根据在宿主机查看的实例xml信息变更：virsh dumpxml instance-00021f44

cat  attach.xml

<disk  type = 'file'  device= 'disk' >
   <driver name= 'qemu'  type = 'qcow2'  cache= 'none' />
   < source  file = '/var/lib/nova/instances/8a902cdf-2967-48c0-b928-df46544c78d5/disk_bak' />
   <target dev= 'vdc'  bus= 'virtio' />
< /disk >

5、加载磁盘

查看实例名称

Virsh list|grep 8a902cdf-2967-48c0-b928-df46544c78d5

通过名称挂载disk

virsh attach-device instance-00008ba9 attach.xml

成功附加设备

6、查看是否挂载成功

在宿主机上查看

virsh dumpxml instance-00008ba9

云主机内查看

fdisk -l

Disk  /dev/vda : 21.4 GB, 21474836480 bytes
16 heads, 63 sectors /track , 41610 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
 
    Device Boot      Start         End      Blocks   Id  System
/dev/vda1    *           1         407      205127+  83  Linux
/dev/vda2              408       41610    20766312   83  Linux
 
Disk  /dev/vdb : 1073 MB, 1073741824 bytes
16 heads, 63 sectors /track , 2080 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
 
Disk  /dev/vdb  doesn't contain a valid partition table
 
Disk  /dev/vdc : 42.9 GB, 42949672960 bytes
16 heads, 63 sectors /track , 83220 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
 
    Device Boot      Start         End      Blocks   Id  System
/dev/vdc1    *           1         407      205127+  83  Linux
/dev/vdc2              408       83220    41737752   83  Linux

7、操作完成后卸载

virsh detach-device instance-00008ba9 attach.xml

成功分离设备

忘记密码（rhel)、修复系统fsck

1、获取uuid nova list --all-tenants --ip ip_addr

2、获取url访问界面 nova get-vnc-console uuid novnc

3、通过界面操作进入单用户模式，修改密码

I版nova stop uuid硬关机

在 icehouse 的版本中，执行 nova stop 时，会直接调用 virsh.destroy 硬关机

http://wiki.libvirt.org/page/FAQ#Why_doesn.27t_.27shutdown.27_seem_to_work.3F

修改源代码让其软关机超时后才执行硬关机解决

---

openstack-neutron 程序错误修复

以下所包括的错误已在 公告中解决。有关此公告的详情请点击以下链接 ：https://access.redhat.com/errata/RHBA-2018:2215.html。

OpenDaylight

BZ#1568311

当实例没有浮动 IP 地址访问另一个路由器上的浮动 IP 时，多个子网的 nova 实例之间的第 3 层连接可能会失败。当 nova 实例分散到多个计算节点时，会出现这种情况。这个问题还没有适当的临时解决方案。

BZ#1568976

在部署过程中，一个或多个 OpenDaylight 实例可能会因为功能加载错误而无法正确启动。这可能会导致部署或功能失败。

当部署通过时，三个 OpenDaylight 实例必须只有两个可以正常工作，才能成功进行部署。第三个 OpenDaylight 实例可能会错误地启动。使用 docker ps 命令检查每个容器的健康状况。如果不健康，请使用 docker restart opendaylight_api 重启容器。

当部署失败时，唯一的选项是重启部署。对于基于 TLS 的部署，所有 OpenDaylight 实例都必须正确引导或部署将失败。

BZ#1586169

在 NAT 设置过程中，创建FibEntry 中缺少的参数会生成 Null Pointer Exception (NPE)。这个错误可能会导致路由表中缺少 FIB 条目，从而导致 NAT 或路由失败。在这个版本中，在 RPC 调用中添加了正确的参数。OpenDaylight 日志中不再看到 NPE，且 NAT 和路由功能可以正常工作。

BZ#1587967

当在没有 VLAN 网络中任何端口的节点上选择了 NAPT 开关时，则不需要的所有流。对于网络没有浮动 IP 地址的所有虚拟机，外部连接会失败。在这个版本中，为作为路由器一部分的 VLAN 的 NAPT 切换中添加了一个伪端口，以创建 VLAN 空间。外部连接适用于没有浮动 IP 地址的虚拟机。

BZ#1588186

一个竞争条件会导致 Open vSwitch 没有连接到 Opendaylight openflowplugin。目前，针对此产品的 13.z 版本实施了一个修复程序。

BZ#1515815

当路由器网关被清除后，不会删除与学习 IP 地址相关的 3 层流。学到的 IP 地址包括 PNF 和外部网关 IP 地址。这会造成过时的流，但无法正常工作问题。外部网关和 IP 地址不会频繁更改。删除外部网络时，会删除过时的流。

openstack-neutron

BZ#1591206

为 neutron OVS 代理添加了一个名为 bridge_mac_table_size 的新配置选项。这个值设置为由 openvswitch-neutron-agent 管理的每个网桥上的 "other_config:mac-table-size" 选项。值控制可以在网桥上学习的最大 MAC 地址数。这个新选项的默认值为 50,000，大多数系统应该足够。OVS 将强制在合理范围之外的值(10 到 1000,000)

python-networking-odl

BZ#1519783

Neutron 可能会出现错误声明，用于 Neutron 路由器创建配额超过。存在一个已知问题：由于 networking-odl 错误，在 Neutron DB 中使用单一创建请求来创建多个路由器资源。造成此问题的解决方法是，使用 OpenStack Neutron CLI 删除重复的路由器，然后再次创建路由器，从而产生单个实例。

python-networking-ovn

BZ#1578312

当 OVSDB 服务器切换到其他控制器节点时，来自 neutron-server/metadata-agent 的重新连接不会发生，因为它们没有检测到这个条件。

因此，引导虚拟机可能无法作为 metadata-agent 置备新的元数据命名空间，集群不会如预期执行。

可能的解决方法是，在将新控制器提升为 OVN 数据库的 master 后，重启所有计算节点中的 ovn_metadata_agent 容器。另外，将 plugin.ini 上的 ovsdb_probe_interval 增加到 600000 毫秒。

BZ#1582512

如果没有为子网设置 'dns_nameservers' 字段，附加到子网的虚拟机具有空的 /etc/resolv.conf。在这个版本中，neutron-server 从其运行的主机的 /etc/resolv.conf 获取 DNS 解析器，并将其用作租户虚拟机的默认 dns_nameservers。

---

Openstack常见问题定位方法及修复方法

首先要确定错误的类型。常见的OpenStack错误类型包括：网络错误、认证错误、配置错误等。通过查看错误日志或者在命令行中输出错误信息，可以帮助我们确定错误的类型。

思路
1、查看日志
OpenStack的各个组件都会记录日志文件，通过查看日志文件可以帮助我们定位错误。常见的日志文件包括：
glance日志文件
/var/log/glance/api.log
nova日志文件
/var/log/nova/(api.log/compute.log)
neutron日志文件
/var/log/neutron/
glance 日志文件
/var/log/glance/
cinder日志文件
/var/log/cinder/
keystone 日志文件
/var/log/keystone/
libvirtd–qemu里的日志文件很重要
/var/log/libvirt/

2、查看配置文件
配置文件中包含了各种配置选项，可能会影响OpenStack的运行。可以通过查看配置文件来排除配置错误。
Keystone - 身份服务：
/etc/keystone/keystone.conf
Glance - 镜像服务：
/etc/glance/glance-api.conf
/etc/glance/glance-registry.conf
Nova - 计算服务：
/etc/nova/nova.conf
Neutron - 网络服务：
/etc/neutron/neutron.conf
/etc/neutron/plugin.ini（根据插件的不同，配置文件也可能是其他名称，例如/etc/neutron/l3_agent.ini）
Cinder - 块存储服务：
/etc/cinder/cinder.conf
Swift - 对象存储服务：
/etc/swift/swift.conf
/etc/swift/proxy-server.conf
Horizon - 仪表板：
/etc/openstack-dashboard/local_settings
Ceilometer - 监控服务：
/etc/ceilometer/ceilometer.conf

3、查看服务状态

crm status   # 查看高可用集群状态
systemctl | grep neutron   # 找出neutron的各个服务
systemctl | grep nova    # 找出nova的各个服务
systemctl | grep cinder   # 找出cinder 的各个服务
systemctl status ...

通过查看服务状态可以帮助我们发现服务是否正常运行。

查看Nova服务状态： openstack compute service list 查看Neutron服务状态： openstack network-agent list
4、重启服务
Nova —计算服务
sudo systemctl restart openstack-nova-api.service
sudo systemctl restart openstack-nova-compute.service
sudo systemctl restart openstack-nova-scheduler.service
sudo systemctl restart openstack-nova-conductor.service
Neutron —网络服务
sudo systemctl restart neutron-server.service
sudo systemctl restart neutron-linuxbridge-agent.service
sudo systemctl restart neutron-dhcp-agent.service
sudo systemctl restart neutron-metadata-agent.service
Keystone —认证服务
sudo systemctl restart apache2.service
Glance —镜像服务
sudo systemctl restart openstack-glance-api.service
sudo systemctl restart openstack-glance-registry.service
Cinder —块存储服务
sudo systemctl restart openstack-cinder-api.service
sudo systemctl restart openstack-cinder-scheduler.service
sudo systemctl restart openstack-cinder-volume.service
Horizon —仪表盘服务
sudo systemctl restart apache2.service

具体问题
Openstack 迁移失败问题定位

openstack server show vm 或者nova show vm  ##查看vm状态
nova instance-action-list vm_id  ## 查看虚拟机ID操作结果,执行的动作列表
nova instance-action [vm_id] [req_id]  ##server_id为执行创建或热迁移的虚拟机id，req_id

为instance-action-list中查询到的Request_ID

grep -r "Request_ID" /var/log/nova/nova-compute.logt

若是没选到主机，查看schedule日志，查找选主情况

OpenStack-vm获取不到ip

1. 看neutron服务状态，确保DHCP服务正常运行–neutron agent-list
2. 查看dnsmasq进程是否正常 – ps aux |grep dnsmasq
3. 检查ovs网桥中的br-int集成网桥是否有tap设备连接到了dhcp-agent的namespace上
   ovs-vsctl show ##找到Bridge br-int
4. 在dhcp命名空间中找到对应网络的namespace中br-int网桥上对应的tap设备，然后查看ip配置：

ip netns show
   ip netns exec qdhcp-062d2b07-339e-4d54-aaca-6b9169d17f6c  ip a

在创建虚拟机发请求后，dnsmasq进程会给虚拟机分配好mac地址和ip地址，并写入
到/var/lib/neutron/dhcp/network-id 目录下的host文件中。
虚拟机在内网中发送广播来获取ip的过程中，dnsmasq 会监听到然后将host文件中的
对应ip通过dchp-namespace分配给虚拟机。

#####问题分析
nova list --all-tenant |grep vm_01  ##查找虚拟机的id
nova interface-list  vm_id  ##查找虚拟机的port
nova interface-detach <vm_id> <port_id>  ##删除网卡
neutron port-list ##查看 port 信息

创建虚拟的时候ip获取过程：
在创建vm的时候，Neutron 会为其分配一个 port，里面包含了 MAC 和 IP 地址信息 /var/lib/neutron/dhcp/id。这些信息会同步更新到 dnsmasq 的 host 文件。同时，nova-compute会生成instance的xml文件，其中网络部分如下：virsh edit instance-00000001；xml中配置的IP和mac在/var/lib/neutron/dhcp/id/host中是有的；

启动过程：
虚拟机第一次启动时：
虚拟机vm1启动时，会发出dhcpdiscover广播报文，该报文会在整个network（vlan）中被收；
dhcpdiscover广播报文会到达tap2c6747c1-2a，dnsmasq监听在它上面，dnsmasq检查对应网络的host文件，发现有对应选项，于是dnsmasq以dhcpoffer报文将ip（192.168.1.10），netmask（24）等信息发送给虚拟机vm1
虚拟机vm1发送dhcprequest广播消息，确认接受dhcpoffer消息。
dnsmasq对虚拟机vm1的dhcprequest报文发送dhcpack消息进行确认，虚拟机vm1收到dhcpack消息之后，开始使用对应ip，整个过程结束。

dnsmasq作为DHCP服务端；DHCP agent 在网络节点运行上，默认通过 dnsmasq 实现 DHCP 功能。

在创建虚拟机的时候，会通过neutron的DHCP服务为虚拟机动态分配一个ip地址。Neutron提供DHCP功能的组件是运行在网络节点上的neutron-dhcp-agent服务。
ps -elf | grep dnsmasq ##dnsmasq进程为网络提供dhcp功能

每创建一个network,就会有一个dnsmasq进程；也就是说 /var/lib/neutron/dhcp/下面的id数量和dnsmasq的进程一样多。

dnsmasq重要命令参数解释：

–interface： dnsmasq用来监听DHCP请求/响应的端口，从而提供DHCP服务。
–dhcp-hostsfile：存放DHCP host信息的文件，dnsmasq会从该文件中获取port和mac地址的对应关系。
–dhcp-leasefile: 租约文件，当我们成功运行dhcpd服务后，就可以分配ip地址给客户端，这些租用信息都可以通过查看租约文件/var/lib/dhcpd/dhcpd.leases来查看每个ip地址的租约记录。
DHCP对应的namespace以qdhcp-network_id命名，可以通过ip netns查看.
通过命令ip netns exec qdhcp-6f854b6c-231d-48c3-876d-0514718bbb58 ip a 可以看到在该网络的namespace中，为tap22c9cf6e-cb设备配置了ip地址;而tap22c9cf6e-cb设备是连接在br-int上的一个port(通过ovs-vsctl show查询)，dnsmasq就是通过监听该端口来为对应网络提供dhcp服务。
nova list报错
所有虚拟机无法访问，执行nova list等指令报错。
问题确认：
1.查看openstack日志log(nova,keystone)发现rabbitmq无法连接
2.执行rabbitmqctl status确认rabbitmq服务状态
问题解决：
1.重启openstack控制节点
2.控制节点服务器重启后，第一时间执行service rabbitmq-server restart，手动启动rabbitmq服务

OpenStack-vm Read only
问题描述： 虚拟出现出现Read-only
报错read-only file system的原因是你所在的分区只有读权限， 没有写权限
操作系统为了保护自身，避免损坏文件系统，采取措施：文件系统read only

先查看/etc/fstab
故障恢复办法：
如果是系统盘可以尝试reboot ，启动时系统会提示自动修复。
如果是挂载盘，可以尝试修复文件系统：
fsck -t ext4 -a /dev/sdb (xfs格式磁盘对应修复命令为xfs_repair）

或者重新挂载：mount -o remount -rw /data

从虚拟机上分离volume卷: nova volume-detach VM_ID Volume_ID

[root@controller ~]# openstack volume list  ## 查看卷ID
[root@controller ~]# nova volume-detach ROLY-3 volume_id #把卷从虚拟机上分离
[root@controller ~]# nova volume-attach 云主机名称 volume_id ##把卷连接到虚拟机上

创建虚拟失败
No valid host was found. There are not enough hosts available

1、 nova show vm_id ## 查看错误信息

nova instance-action-list vm-id 查看vm的操作信息
nova hypervisor-list 查看计算节点状态

#查看虚拟机信息
nova show $VM_UUID
openstack server show $VM_UUID
#查看虚拟机当前状态
nova instance-action-list $VM_UUID

#重置虚拟机状态
nova reset-state --active $VM_UUID
openstack server set --state active $VM_UUID 
#重置后需要硬重启 
nova reboot $VM_UUID --hard 
#验证 
openstack server show $VM_UUID

nova availability-zone-list   ##查看域信息

1、看将要创建虚拟所在可用区AZ下的compute是否充足
2、看对应compute的nova-compute日志和nova-scheduler.log
3、查看虚机对应的宿主机compute: nova show vm-id ｜grep host

删除compute并重新加回
尝试将compute节点从nova service-list中删除，并重新加入到集群中
停掉compute节点的nova-compute 服务：nova service-delete <计算节点的uuid>
开启计算节点的nova-compute服务，让计算节点重新注册：sudo systemctl restart openstack-nova-compute.service

---

openstack节点备份、迁移、恢复

openstack-控制节点，单点备份恢复

一.备份

####需要备份数据库和以下文件夹
mysqldump --opt --all-databases > openstack.sql

/etc/chrony.conf
/etc/my.cnf.d/openstack.cnf
/etc/sysconfig/memcached
/etc/etcd/etcd.conf
/etc/httpd/conf/httpd.conf
/etc/placement/placement.conf
/etc/httpd/conf.d/00-placement-api.conf
/etc/nova
/var/log/nova
/var/lib/nova
/var/lib/glance
/etc/glance
/var/log/glance
/etc/keystone
/var/log/keystone
/var/lib/keystone
/etc/cinder
/var/log/cinder
/var/lib/cinder
/etc/neutron
/var/log/neutron
/var/lib/neutron

备份脚本

vi bak.sh

#/bin/bash
#### /var/lib/glance下的镜像文件较大，可单独备份
echo -ne '''
/etc/chrony.conf
/etc/my.cnf.d/openstack.cnf
/etc/sysconfig/memcached
/etc/etcd/etcd.conf
/etc/httpd/conf/httpd.conf
/etc/placement/placement.conf
/etc/httpd/conf.d/00-placement-api.conf
/etc/nova
/var/log/nova
/var/lib/nova
/etc/glance
/var/log/glance
/etc/keystone
/var/log/keystone
/var/lib/keystone
/etc/cinder
/var/log/cinder
/var/lib/cinder
/etc/neutron
/var/log/neutron
/var/lib/neutron
''' | while read line;do rsync -azR --progress $line /opt/;rsync -az --progress /opt/* root@192.168.5.35:/opt/;done
#### 分别备份一份到本地和远端服务器，记得配置到5.35的免密登录

二.恢复

1.初始环境安装

yum install chrony
yum install centos-release-openstack-train -y
yum install https://rdoproject.org/repos/rdo-release.rpm -y
yum upgrade -y
yum install python-openstackclient openstack-selinux -y
yum install mariadb mariadb-server python2-PyMySQL -y
yum install rabbitmq-server -y
yum install memcached python-memcached -y
yum install etcd -y
yum install openstack-keystone httpd mod_wsgi -y
yum install openstack-glance -y
yum install openstack-placement-api -y
yum install -y openstack-nova-api openstack-nova-conductor \
  openstack-nova-novncproxy openstack-nova-scheduler
yum install -y openstack-neutron openstack-neutron-ml2 \
  openstack-neutron-linuxbridge ebtables 
yum install openstack-cinder -y

echo 'net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1' >> /etc/sysctl.conf
modprobe br_netfilter
sysctl -p

2.恢复备份文件

1.恢复脚本：

vi recover.sh

#/bin/bash

echo -ne '''
/etc/chrony.conf
/etc/my.cnf.d/openstack.cnf
/etc/sysconfig/memcached
/etc/etcd/etcd.conf
/etc/httpd/conf/httpd.conf
/etc/placement/placement.conf
/etc/httpd/conf.d/00-placement-api.conf
/etc/nova
/var/log/nova
/var/lib/nova
/etc/glance
/var/log/glance
/etc/keystone
/var/log/keystone
/var/lib/keystone
/etc/cinder
/var/log/cinder
/var/lib/cinder
/etc/neutron
/var/log/neutron
/var/lib/neutron
''' | while read line;do rsync -azR --progress $line /mnt/tmp/ && rsync -az root@192.168.5.35:/opt/ / ;done
####恢复后注意检查，配置文件和日志文件的权限，文件属主关系，不然启动服务器会有异常报错

2.关联文件

ln -s /usr/share/keystone/wsgi-keystone.conf /etc/httpd/conf.d/
ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini

3.恢复数据库

systemctl enable chronyd.service
systemctl start chronyd.service
systemctl status chronyd.service

systemctl enable mariadb.service
systemctl start mariadb.service
systemctl status mariadb.service

mysql < /openstack.sql

5.启动服务

systemctl enable rabbitmq-server.service
systemctl start rabbitmq-server.service
systemctl status rabbitmq-server.service

rabbitmqctl add_user openstack RABBIT_PASS
rabbitmqctl set_permissions openstack ".*" ".*" ".*"
rabbitmqctl set_user_tags openstack administrator

systemctl enable memcached.service
systemctl start memcached.service
systemctl status memcached.service

systemctl enable etcd
systemctl start etcd
systemctl status etcd

systemctl enable httpd.service
systemctl start httpd.service
systemctl status httpd.service

systemctl enable openstack-glance-api.service
systemctl start openstack-glance-api.service
systemctl status openstack-glance-api.service

systemctl enable \
    openstack-nova-api.service \
    openstack-nova-scheduler.service \
    openstack-nova-conductor.service \
    openstack-nova-novncproxy.service
	
systemctl start \
    openstack-nova-api.service \
    openstack-nova-scheduler.service \
    openstack-nova-conductor.service \
    openstack-nova-novncproxy.service
systemctl status \
    openstack-nova-api.service \
    openstack-nova-scheduler.service \
    openstack-nova-conductor.service \
    openstack-nova-novncproxy.service
	
systemctl enable neutron-server.service \
  neutron-linuxbridge-agent.service neutron-dhcp-agent.service \
  neutron-metadata-agent.service
systemctl start neutron-server.service \
  neutron-linuxbridge-agent.service neutron-dhcp-agent.service \
  neutron-metadata-agent.service
systemctl status neutron-server.service \
  neutron-linuxbridge-agent.service neutron-dhcp-agent.service \
  neutron-metadata-agent.service
  
systemctl enable openstack-cinder-api.service openstack-cinder-scheduler.service
systemctl start openstack-cinder-api.service openstack-cinder-scheduler.service
systemctl status openstack-cinder-api.service openstack-cinder-scheduler.service

####多注意各个服务状态

6.检查
1.服务，和文件属组，权限，是否正常
2.查看各个服务状态

openstack server list
openstack endpoint list
openstack compute service list


rabbitmqctl list_users
curl http://controller:8778
curl http://controller:5000/v3


systemctl status chronyd.service
systemctl status rabbitmq-server.service
systemctl status memcached.service
systemctl status etcd
systemctl status httpd.service
systemctl status openstack-glance-api.service

systemctl status \
    openstack-nova-api.service \
    openstack-nova-scheduler.service \
    openstack-nova-conductor.service \
    openstack-nova-novncproxy.service

计算节点：

systemctl status neutron-server.service \
  neutron-linuxbridge-agent.service neutron-dhcp-agent.service \
  neutron-metadata-agent.service

systemctl status openstack-cinder-api.service openstack-cinder-scheduler.service

---

Openstack Neutron(网络)查错及解决

常见问题分类
您可能遇到的问题可以分为以下几类：

配置错误 - 遇到问题可能是因为你在neutron配置文件中进行了错误的配置。使用错误的配置工具也可能导致问题。配置错误的底层网络会影响neutron的功能，因为每个数据包最终都会通过物理层。举个例子，产生错误的原因可能是外部网络不可访问，或由于防火墙规则阻止了你的虚拟机流量通往外部。所以如果底层网络不可用，neutron也将无法正常工作。

代码中的错误 - 你可能会在代码中发现错误。幸运的是，你大概率不会是第一个遇到这个bug的人，如果有人已经上报了bug，你可以在 这里 找到答案。如果找不到这个bug，那么你可能是第一个遇到它的人，你应该报告这个bug，这样开发人员就可以开始修复它了。

问题一: 无法用private IP ping通或ssh远程登录虚拟机
这是一个常见的问题，特别是对于openstack新手来说。为了调试这个问题，我们首先应当理解虚拟机是如何获得一个IP的。

虚拟机如何获得IP？
为了回答这个问题，我们需要介绍 DHCP 代理。如果你熟悉网络，会知道 DHCP 是分发不同网络参数（包括IP地址）的协议。

DHCP 代理通过 RPC 与 neutron-server 进行通信，它使用 namespaces （命名空间）确保网络隔离，因此每个网络都有自己的DHCP命名空间。在这个命名空间里有一个名为 dnsmasq 的进程，它实际上服务于DHCP参数，包括IP地址。DHCP代理使用一个 lease file （租约文件）来配置这个dnsmasq。

firewall bridge（防火墙）是一个 linux bridge，这是应用 security groups（安全组）的地方，使用 iptables 来实现。我们不能将iptables应用到连接到 openvswitch 端口的接口，所以我们需要在中间有防火墙。

集成网桥（integration bridge，br-int）负责用与网络相关联的 VLAN ID 标记或取消标记那些来往于虚拟机的流量。每个网络都有一个VLAN ID，运用于主机内部以隔离流量（这也是为什么它被称为本地VLAN ID）。

隧道桥（tunnel bridge，br-tun）是负责连同的通道。它将分配给网络的VLAN ID转换成 segmentation id （分段ID）。举个例子，如果你正在使用 GRE tuneel ，则 GRE tunnel ID 将是分配给网络的分段ID。

在linux bridge实现中，每个网络都有一个linux bridge。现在我们有net1并且虚拟机连接到net1上，同时可看到插入net1网桥的接口是eth0.100，这意味着vlan 100被分配给net1网络。

Debug步骤
首先检查虚拟机是否启动，这听起来很简单，但不能略过这一步：

nova list --all

在上面的输出中，我们可以看到实例正在运行。如果它没有运行，我们可以在日志中查看出错的线索。查看日志总是一个明智的步骤，因为许多问题都反映在日志里。

$ grep -E -R -i "trace|error" /var/log/nova/ var/log/neutron/

log中可能会提示代码错误，需要我们手动改动配置文件或python文件，一般都能在网上查到方法。由于我们使用openstack存在版本差异，可能在某个版本出现的bug在下个版本修复了，但依旧存在于这个版本，于是我们可以参考 github 上不同版本对比修改。

需要明确的是，错误可能是由任何因素造成的。它甚至可能与你的OpenStack部署无关，而与你的硬件有关。举个例子，也许是因为你已经没有足够的空间或内存去启动和运行虚拟机，你可以通过以下方式验证：

$ df -Ph && free -m

错误的另一个常见原因是默认的安全组规则。default security group默认情况下不允许ICMP（ping命令使用的协议），所以我们需要配置它。

可以在openstack horizon界面中添加ICMP和ssh（TCP）规则，也可以通过命令行。命令行方式给默认安全组添加规则的方法如下：

$ nova secgroup-add-rule default icmp -l -l 0.0.0.0/0

$ nova secgroup-add-rule default tcp 22 22 0.0.0.0/0

其中，第一条命令使虚拟机能被ping通，第二条使虚拟机可以ssh远程登录。

如前所述，物理底层网络也可能导致问题，在排查问题前，应当确保openstack各个节点间能ping通。

在引入环境变量后，可以使用如下命令查看各个节点的情况：

$ openstack compute service list

如果发现某个节点的状态是down，应当及时检查硬件设备：电源是否接通，网线是否接通。

端口绑定
如果虚拟机没有启动，请检查是否在虚拟机端口或路由器、DHCP端口上遇到了端口绑定故障。

对于虚拟机端口，将会被记录为端口绑定失败，因此很容易发现。

对于DHCP或路由器来说，并不是那么容易，因为端口是异步创建的，这意味着你不会马上看到它。以路由器为例。当你创建路由器并添加新的接口时，即使在背后创建的端口进入绑定失败状态，操作也会成功。那是因为这是异步发生的。

针对原文下面的指令，首先我们可以从openstack horizon界面中获得端口的ID，或者通过命令行获得。我们可以通过命令行看到所有的端口ID：

$ openstack port list

查看端口绑定情况：

$ neutron port-show <port_id> -F "binding:vif_type" -F "binding:host_id"

有两种情况容易导致这个错误发生：

1.当你在路由器中添加新的子网或新的接口端口时，OVS代理已经挂掉。 这可以通过以下方式轻松验证：

$ neutron agent-list

你可以在openvswitch agent那行查看状态，如果正常，在alive栏会看到笑脸。

笔者在安装openstack的时候参照的是官方文档，并没有用到 openvswitch 。但上述指令不失为一种检测网络代理是否正常的方法。笔者上次遇到错误就是发现 Linux bridge agent 出错，然后在log中找到了问题。

另一种OVS代理挂掉的症状是tap设备下没有VLAN标记。你可以通过以下方式验证：

$ ovs-vsctl show | grep tap -A 3

这种情况下唯一的解决方法就是重新创建虚拟机。

2.代理或服务器配置文件中的配置错误。这通常是因为在配置文件中使用了一些非默认值。

虚拟机是否接受到IP？
既然我们知道了虚拟机得到IP的过程，我们可以检查虚拟机是否接受到IP。可以在虚拟机命令行中使用如下指令：

$ ip a

如果没有IP，检查DHCP代理是否正常运行：

$ neutron agent-list

接下来，可以检查 dnsmasq 是否在你指定的网络节点正常运行。

$ ps -ef | grep dnsmasq | grep <network_id>

还可以检查 lease file（租约文件）是否存在并且虚拟机的mac地址在host 文件中。

$ cat /var/lib/neutron/dhcp/<network_id>/host

如果以上都排查了发现没有IP并且其他一切都看起来很正常，那么可以检查DHCP代理的log文件：

$ less /var/log/neutron/dhcp-agent.log

此时，还需要确保没有跨节点连接问题，所以请尝试在主机和虚拟机之间进行ping操作。不要忘记给主机设定正确的静态IP。

要记住的是，如果底层网络有问题，它会影响neutron的运行。 例如，如果物理交换机中不允许使用某些vlan ID，它将反映在neutron中，并且可能存在连接问题。

如果还没有找到问题，那么是时候拿出终极武器了—— tcpdump。tcpdump将允许你跟踪数据包的完整过程，并查看它们在每个步骤中的变化情况。有很多很棒的在线教程解释了如何使用它，对于最基本的使用，试试运行：

$ tcpdump -i <name_of_the_device>

问题二: 虚拟机无法访问外部网络
为了解决这个问题，我们需要了解L3 agent（L3代理）的工作原理。其主要职责是允许L3连接和路由，也提供NAT，并使用命名空间进行网络隔离。通常它将被安装在网络节点上，也是提供访问外部网络的代理。

在官网的安装文档上并没有网络节点，而是把网络服务分装在控制节点和计算节点上，这里所说的网络节点应当就是我们平时配置的控制节点。

让我们看看虚拟机尝试访问外部网络的过程,和解析虚拟机如何获得IP类似。

Debug步骤
首先，确保在环境中配置了正确的安全组规则，需要明确地允许ssh和ping。（这在上文中已经讲过，如下指令可以查看环境中的所有安全组都具有哪些规则，也可以在horizon界面中查看）

$ neutron security-group-rule-list

检查是否可以ping通 private IP。如果不能，就不必指望浮动IP起作用。请检查虚拟机是否可以到达路由器，因为如果不能到达路由器，必然不能到达外部网络。

官网教程 创建一个虚拟机 中写了如何创建 provider network 和 self-service network。在self-service netwrok中，创建的网络有一个内部IP和一个外部IP。创建self-service network时，需要有一个provider network，并创建一个路由，把self-service network的子网作为路由的一个接口，再把路由连接到provider网络上。这时运行以下命令，可以看到provider网络的两个网关：

$ neutron router-port-list router

其中 172.16.1.1 是self-service network的内部网关，是无法从外部ping通的，203.0.113.102 是外部网关，可以从外部ping通。如上所说，在创建self-service network时，会通过建立一个路由把该网络和一个provider network连接以保证self-service network可以访问外部网络。

在self-service network中创建虚拟机，需要给虚拟机分配一个浮动IP，如果我们想ping通虚拟机，应当使用这个浮动IP。

上文的ping通private IP笔者略有疑惑，可能指的是从虚拟机内部ping 类似 172.16.1.1 的内部网关，也可能是从外部ping虚拟机绑定的浮动IP。

接下来，从路由器命名空间尝试使用浮动IP来ping 虚拟机：

$ sudo ip netns exec qrouter-xxx-xxx-xxx ping <vm_floating_ip>

上面命令的命名空间可以用如下指令获得：

$ ip netns

用如下指令可以得到所有虚拟机的IP：

$ openstack server list

这可能是个愚蠢的检查，因为浮动IP总是处于路由器命名空间内，但至少它会告诉我们情况有多糟糕。

你还应该检查网桥配置问题。 用下面的命令检查它：

$ ovs-vsctl show

别忘了检查L3 agent的log文件：

$ sudo grep -E -i "error|trace" /var/log/neutron/l3-agent.log

用以下命令看虚拟机是否得到了IP：

$ ip a

从虚拟机里ping网关看是否能到达：

$ route -n

$ ping <default_gateway_ip>

问题三: 虚拟机无法访问元数据服务器
元数据服务器是为虚拟机提供元数据的服务。数据可以是ssh密钥，ip地址，主机名。

元数据代理负责将来自虚拟机的请求代理到元数据服务器或 nova。 有两种方法来配置它：

路由网络 - 当你有一个连接到路由器的网络

非路由网络 - 当你有没有连接到路由器的网络，所以它是隔离的。

我们来看看路由网络的工作流：
metdata代理由L3代理生成，并监听请求。当来自虚拟机的请求到达元数据代理时，它将一些信息添加到虚拟机和路由器id的头部IP中，并将其转发给元数据代理。
现在让我们更仔细地看看其他配置 - 隔离网络：

注意：为了隔离网络能工作，必须在dhcp配置文件中进行配置：

enable_isolated_metadata = True

在以下文件中配置：

/etc/neutron/dhcp_agent.ini

我们还使用DHCP的 option 121，在向DHCP请求IP地址时向虚拟机注入路由。 所以元数据代理是到达元数据服务器的下一个跃点。

Debug步骤
首先查看metadata agent是否正常运行：

$ neutron agent-list

在metadata agent 那行应当看到alive下面的微笑。

接着，检查metadata proxy是否正常。请记住，它是由L3代理在路由器（或dhcp）命名空间中产生的，所以您应该检查它是否在命名空间的进程表中：

$ sudo ip netns exec qrouter-xxx-xxx-xxx ps -ef | grep metadata-proxy

问题会反映在metadata的log文件中，所以前去检查：

$ sudo grep -E -i "error|trace" /var/log/neutron/metadata-agent.log /var/log/neutron/neutron-ns-metadata-proxy-xxx-xxx-xxx.log

检查是否可以通过路由/DHCP到达元数据服务器：

$ sudo ip netns exec qrouter-xxx-xxx-xxx ping <metadata-server_IP>

检查创建虚拟机的镜像是否支持 option 121。如果不支持，那么虚拟机可能无法得到路由并且到达元数据服务器。

如果所有都尝试了还没有发现问题，试着使用 tcpdump 来解决问题。

问题四: VIF plugging timeout
为了理解为什么会遇到timeout问题，我们需要介绍L2代理。

L2代理在计算主机上运行，其主要职责是配置节点上的本地交换机并连接新设备，它通过RPC与neutron服务器通信，还负责提供使用iptables和ip集合的安全组规则。

让我们更详细地看看VIF如何工作：

当Nova发送allocate_network请求时，它将超时设置为5分钟。如果Nova在5分钟内没有得到Neutron的回复，你会得到VIF plugging timeout。

debug步骤
检查日志。L2代理，neutron和nova日志可以帮助查找问题，在计算节点上输入：

$ sudo grep -E -i "error|trace" /var/log/nova/nova-compute.log /var/log/neutron/openvswitch-agent.log

在控制节点上：

$ sudo grep -E -i "error|trace" /var/log/neutron/server.log

如果系统加载缓慢，或者你正在执行压力测试，则可能需要调整/etc/nova/nova.conf文件中的服务器配置：

尝试增加 vif_plugging_timeout 以提供更多的时间来插入接口

尝试增加 rpc_thread_pool_size 和 rpc_conn_pool_size 以使处理速度更快

一些好用的工具，在对neutron进行debug过程中用到的工具。

ip a
ip addr（ip a只是一个快捷方式）对于检查你的机器/命名空间中的设备非常有用。它允许你获取设备名称、查看设备是否启动、获取IP地址、MTU以及其他一些网络参数。

route -n
它会显示路由表。通过路由表，你可以知道你的数据包在流出时将采用哪个路径。

iptables -L
查看节点上存在哪些防火墙规则。如果你的数据包突然消失或没有到达最终目的地，防火墙的某些规则可能是原因。

arp
查看主机上的arp表。利用它可以查看你的节点能不能找到其他节点的地址。

tcpdump
这是一个很棒的数据包追踪工具，容易安装，也容易使用。我将在另一篇文章中介绍它，因为有很多方法可以使用，最好花时间专门学习。对于最基本的使用，只需运行：

$ tcpdump -i <device_name>

ip netns

查看namespace。为了列出你所在节点可用的namespaces，可以使用：

$ ip netns list

你可以使用 ip netns exec 查看更多。例如，要在命名空间中显示路由表，请使用：

$ ip netns exec qrouter-xxx-xxx-xxx route -n

OpenVSwich
如果你在部署中使用openvswitch，则有几个用于调试和故障排除的工具：

ovs-vsctl show —— 显示机器上网桥的配置

ovs-ofctl show —— 显示数据路径

ovs-ofctl dump-flows —— 转储安装在机器上的所有流

ovs-ofctl dump-flows br-tun —— 转储br-tun上的所有流

ovs-ofctl dump-flows br-tun table = 21 —— 在特定表中转储br-tun上的所有流

LinuxBridge
对于linux网桥，请使用以下命令：

brctl show —— 显示机器上网桥的配置

brctl show —— 显示特定网桥的配置

补充
再介绍一些你可能想要熟悉的几个重要的网络设备。

我们从TAP设备开始。TAP设备是一个虚拟网络接口，用于连接由虚拟机管理程序（KVM，Xen等）实现的虚拟机实例。流量到达TAP设备，由虚拟机实例接收。要记住TAP设备通常是流量的起点，可以从TAP设备开始跟踪流量。

要查看TAP设备，只需运行：

$ ip a | grep -i tab

更多关于TAP设备的信息，可以在 这里 找到。

TAP设备使用Linux bridge进行桥接。通常Linux桥名以qbr开头，这是qunaum bridge的简写（qunaum是neutron以前的名字）。你可以使用brctl列出系统上的linux bridge。

$ brctl show

你会在输出中看到TAP接口和qvb接口。

qvb（Quantum veth bridge）和另一end - qvo（Quantum veth openvswitch）构成一个虚拟以太网对（Virtual Ethernet Pair）。它用来连接Linux桥和OVS桥。可以把它们想象成一条管道，任何在一个设备上进入的东西都应该从这个设备上离开。

如果你列出集成桥上的端口，你将看到其中一个端口是qvo，它将你连接到Linude Bridge。

路由器和DHCP设备直连到br-int。在列出DHCP命名空间中的接口或列出集成网桥上的端口时，可以看到TAP设备条目。

$ ip netns exec qdhcp-<network_id> ip address

$ ovs-vsctl list-ports br-int

在了解了neutron的基础概念，通过一些图表知道了数据流的走向后，对于我们debug最有用的还是查看log。Openstack的log都处于 /var/log 目录下，我们通过查看、解决log里的问题，并重启相应网络服务，基本可以解决问题。