OpenStack 虚拟机创建源码分析：创建网络及子网

2017-11-23

在上一篇博文分析完 Neutron Server 的启动过程后，按原先安排应该是接着分析 L2、L3 等服务(agent)的启动过程，但发现它们的启动过程相对于 Neutron Server 来说要简单的多，也比较类似，再过多阐述有点重复的嫌疑；另外也是为了从实践角度出发，对虚拟机创建过程的情景做一个分析，将 Nova、Glance、Neutron 及 Cinder 模块串联起来，其中夹杂对一些关键服务（如 L2、L3）的分析，也不失为一个好的办法。所以，接下来，我们将从虚拟机创建情境入手，一步步来分析涉及的知识点。今天我们先来看下创建虚拟机会用到的网络及子网。

网络及子网在 Neutron 中都属于 Core Resouce，它们的创建入口在 Core Plugin（ML2）中（具体路由分析见上一篇博文 Neutron Server 的启动过程）。还有一点需要特别注意的是，Core Plugin 中的 Resource CRUD 操作一般都会涉及与 Type driver、Mechanism driver、Extension driver 及 RPC 的交互。接下来对网络及子网的创建也会重点从这 4 点出发来分析。

开始之前，我们先说一下本文一些前提条件：

L2 Agent 采用的是 Linux Bridge Agent
新建的（租户）网络的类型为 VLAN（Enable 了 Admin State）
新建（该网络的）子网开启 DHCP，手动设置 CIDR（不从 subnet pool 分配）
其余都采用默认值（Extension driver 默认开启了 port security）

创建网络

在 ML2 中，创建网络（create_network 函数）算是最简单的，因为它最主要的事情就是把网络相关信息保存到 Neutron 数据库当中。

下边我们可以从 5 个部分来分析一下：

自身(网络)：在 networks 表添加一条记录，记录自己的信息
Type driver：在 networksegments 表添加一条记录，记录该网络的类型信息、segmentation id
Mechanism driver: 所调用的 create_network_precommit 和 create_network_postcommit 均是直接返回（pass）
Extension driver: 在 networksecuritybindings 表添加一条记录，记录是否开始 port security（默认开启）
RPC：ML2 中初始化的 DhcpAgentNotifyAPI（参考上文）订阅（subscribe）了网络创建的事件（AFTER_CREATE，详细参考上文Callback System），所以在创建网络结束后会轮询调用到 DhcpAgentNotifyAPI 中的 _native_event_send_dhcp_notification 函数，但最后还是直接返回而没有其他操作

具体创建流程可以参考博文 OpenStack Neutron ML2 Deep Dive 中的一张示意图：

创建子网

跟创建网络相比，创建子网就要复杂的多了。除了涉及的 Type/Mechanism/Extension 3 个部分基本都是直接返回（pass）外，其余涉及的需要详述的还有：

IPAM
Callback System
Network 调度
（DHCP）Port 创建
网络设备（vlan、tap、veth、bridge）
Dnsmasq（配置文件及开启进程）
RPC

下边我们一一详述。

IPAM

IPAM 是 IP Address Management 的缩写，用于 IP/Subnet 的分配（Allocation）。其实，官方文档对 IPAM 的描述是 Pluggable，也就是 IPAM 是可插拔的，说白了，IPAM 是要做成支持多个驱动的方式。从配置文件就可以看出来（cfg.CONF.ipam_driver 值默认为 “internal”）：

# setup.cfg
neutron.ipam_drivers =
    fake = neutron.tests.unit.ipam.fake_driver:FakeDriver
    internal = neutron.ipam.drivers.neutrondb_ipam.driver:NeutronDbPool

通过这种方式，只要符合接口标准，要写一个我们自己的 IP/Subnet 分配策略驱动就很方便了。可扩展性强。

接下来，我们按官方文档对 IPAM 进行一个简单介绍（具体类名有些跟代码中的不一致，看图就可以了）。

代码结构

跟很多驱动式代码一样，IPAM 也有一个抽象类（IPAMDriver），定义接口；然后有一个实现抽象类接口的类（NeutronIPAM）。最后 Neutron 通过调用该 NeutronIPAM 来实现对 IP/Subnet 管理。请见下图：

Subnet（Allocation Pools）分配

由下图可见，Subnet 的分配是要先经过 IPAM 处理，最后才将其返回的 subnet 信息（只取其中的 allocation pools）和用户传入的参数一起写入到 subnet 自身的数据库表（subnets、ipallocationpools）中：

在具体代码中，往数据库写入 Subnet 信息最终会调用到 allocate_subnet 函数：

# neutron/db/ipam_pluggable_backend.py
class IpamPluggableBackend(ipam_backend_mixin.IpamBackendMixin):
    ...

    def allocate_subnet(self, context, network, subnet, subnetpool_id):
        ...
        # 1. 根据（用户传入的）参数分配 subnet（包括 allocation pools），
        #    并将这些信息写到数据库中
        ipam_subnet = ipam_driver.allocate_subnet(subnet_request)
        # get updated details with actually allocated subnet
        subnet_request = ipam_subnet.get_details()

        # 2. 根据（用户传入的）参数和 IPAM 返回的信息（只取其中的 allocation pools）
        #    在数据库中写入 subnet 相关的信息
        try:
            subnet = self._save_subnet(context,
                                       network,
                                       self._make_subnet_args(
                                           subnet_request,
                                           subnet,
                                           subnetpool_id),
                                       subnet['dns_nameservers'],
                                       subnet['host_routes'],
                                       subnet_request)
        ...

    def _save_subnet(self, context,
                     network,
                     subnet_args,
                     dns_nameservers,
                     host_routes,
                     subnet_request):
        ...

        # 保存 Subnet 自身信息到数据库
        subnet = models_v2.Subnet(**subnet_args)
        segment_id = subnet_args.get('segment_id')
        try:
            context.session.add(subnet)
            context.session.flush()
            ..

        if validators.is_attr_set(dns_nameservers):
        if validators.is_attr_set(host_routes):
        if validators.is_attr_set(service_types):
            ...

        # 只用到了 IPAM 中返回（分配）的 allocation_pools
        self.save_allocation_pools(context, subnet,
                                   subnet_request.allocation_pools)

        return subnet

到这里，我们就很清楚，IPAM 分配 subnet 其实最重要的就是确定 subnet 的可用地址范围（即 allocation pools），而对于其他信息，除了 subnet 自身信息，它都是不处理的（如 dns_nameserver、host_routes）。

IP 分配

由下图可见，IP 的分配是要先经过 IPAM 处理，最后才将其返回的 ip 信息（及 port 信息，稍后分析）写到 subnet 自身的数据库表（ipallocations）中：

Network 调度及网络设备创建

在数据库中创建完 subnet 相关的条目其实只是做了一个记录，并没有实际在宿主机中体现出来。接下来我们重点就在于分析后者。

事件订阅过程说明

我们再来看一下 subnet 创建的代码：

# neutron/plugins/ml2/plugin.py
class Ml2Plugin(...)
    def create_subnet(self, context, subnet):
        # 这一步已经完成
        result, mech_context = self._create_subnet_db(context, subnet)
        # 通过 Callback System 调用订阅该资源（SUBNET）该事件（AFTER_CREATE）的函数
        kwargs = {'context': context, 'subnet': result}
        registry.notify(resources.SUBNET, events.AFTER_CREATE, self, **kwargs)
        ...

而我们在上一篇博文Neutron Server 的启动过程有提到在初始化 ML2 的过程当中会初始化 RPC Notifiers：

# neutron/plugins/ml2/plugin.py
class Ml2Plugin(...)

    @resource_registry.tracked_resources(...)
    def __init__(self):
        ...
        self._start_rpc_notifiers()
        ...

    @log_helpers.log_method_call
    def _start_rpc_notifiers(self):
        """Initialize RPC notifiers for agents."""
        # 这一句不是我们的重点，不过我们在本小结最后有一个简单备注
        self.ovo_notifier = ovo_rpc.OVOServerRpcInterface()
        ...
        self.agent_notifiers[const.AGENT_TYPE_DHCP] = (
            dhcp_rpc_agent_api.DhcpAgentNotifyAPI()
        )

而在 DhcpAgentNotifyAPI 的初始化中会订阅几个 Core Resources 的事件，下边我们只看一下订阅 AFTER_CREATE 事件的代码：

# neutron/api/rpc/agentnotifiers/dhcp_rpc_agent_api.py
class DhcpAgentNotifyAPI(object):
    """API for plugin to notify DHCP agent.

    This class implements the client side of an rpc interface.  The server side
    is neutron.agent.dhcp.agent.DhcpAgent.  For more information about changing
    rpc interfaces, please see doc/source/devref/rpc_api.rst.
    """
    # It seems dhcp agent does not support bulk operation
    VALID_RESOURCES = ['network', 'subnet', 'port']
    VALID_METHOD_NAMES = [...
                          'subnet.create.end',
                          ...]

    def __init__(self, topic=topics.DHCP_AGENT, plugin=None):
        ...
        for resource in (resources.NETWORK, resources.PORT, resources.SUBNET):
            ...
            registry.subscribe(self._native_event_send_dhcp_notification,
                               resource, events.AFTER_CREATE)
            ...

也就是说，在 Ml2Plugin::create_subnet 函数中的 registry.notify 动作会最终调用到 DhcpAgentNotifyAPI::_native_event_send_dhcp_notification 函数。下边我们从该函数入手：

# neutron/api/rpc/agentnotifiers/dhcp_rpc_agent_api.py
class DhcpAgentNotifyAPI(object):

    def _native_event_send_dhcp_notification(self, resource, event, trigger,
                                             context, **kwargs):
        action = event.replace('after_', '')
        ...
        method_name = '.'.join((resource, action, 'end'))	# subnet.create.end
        payload = kwargs[resource]
        data = {resource: payload}
        ...
        self.notify(context, data, method_name)

    def notify(self, context, data, method_name):
        # data is {'key' : 'value'} with only one key
        ...
        elif obj_type in ['port', 'subnet'] and 'network_id' in obj_value:
            network_id = obj_value['network_id']
        ...
        method_name = method_name.replace(".", "_")	# create_subnet_end
        if ...
        else:
            self._notify_agents(context, method_name, data, network_id)

其中 _notify_agents 函数定义如下：

# neutron/api/rpc/agentnotifiers/dhcp_rpc_agent_api.py
class DhcpAgentNotifyAPI(object):
    def _notify_agents(self, context, method, payload, network_id):
        """Notify all the agents that are hosting the network."""
        # fanout is required as we do not know who is "listening"
        ...
        cast_required = method != 'network_create_end'

        if ...	# fanout_required is False
        elif cast_required:
            admin_ctx = (context if context.is_admin else context.elevated())
            # 1. 从 Core Plugin(ML2) 获取 network 信息
            network = self.plugin.get_network(admin_ctx, network_id)
            ...
            # 2. 判断 network 已经绑定的 DHCP Agents，此时因为该 network 还未绑定任何 DHCP Agent，返回为空列表
            agents = self.plugin.get_dhcp_agents_hosting_networks(
                context, [network_id], hosts=network.get('candidate_hosts'))
            # !!!! 3. 调度 network 到 DHCP Agents 上（可以有多个）。这部分是重点，下文我们会详细分析。
            schedule_required = (
                method == 'subnet_create_end' or
                ...)
            if schedule_required:
                agents = self._schedule_network(admin_ctx, network, agents)
            if not agents:
                ...
            enabled_agents = self._get_enabled_agents(
                context, network, agents, method, payload)
            # 4. 向每一个 DHCP Agent 发送 RPC 信息。这里不是很重要，我们就不做过多分析了。
            for agent in enabled_agents:
                self._cast_message(
                    context, method, payload, agent.host, agent.topic)

这里最终调用的 _notify_agents 函数的重点在Network 调度（如果存在多个 DHCP Agent，确定该网络应该由哪“几”个 DHCP Agent 来服务）（上述代码注释中的第 3 步）。下边我们也就从这步着手。

注：对于 ovo_notifier，在其初始化过程中也会订阅这些 Core Resources 的事件，不过这里不是我们关注的重点，大家简单看下订阅的代码就可以了：

# neutron/plugins/ml2/ovo_rpc.py
class OVOServerRpcInterface(object):
    """ML2 server-side RPC interface.

    Generates RPC callback notifications on ML2 object changes.
    """

    def __init__(self):
        self._rpc_pusher = resources_rpc.ResourcesPushRpcApi()
        self._setup_change_handlers()
        LOG.debug("ML2 OVO RPC backend initialized.")

    def _setup_change_handlers(self):
        """Setup all of the local callback listeners for resource changes."""
        resource_objclass_map = {
            ...
            resources.SUBNET: subnet.Subnet,
            ...
        }
        self._resource_handlers = {
            res: _ObjectChangeHandler(res, obj_class, self._rpc_pusher)
            for res, obj_class in resource_objclass_map.items()
        }

class _ObjectChangeHandler(object):
    def __init__(self, resource, object_class, resource_push_api):
        ...
        for event in (events.AFTER_CREATE, events.AFTER_UPDATE,
                      events.AFTER_DELETE):
            registry.subscribe(self.handle_event, resource, event)

Network 调度

而我们在上一篇博文Neutron Server 的启动过程有提到在初始化 ML2 的过程当中会初始化 DHCP（的 network_scheduler）：

# neutron/plugins/ml2/plugin.py
class Ml2Plugin(...)

    @resource_registry.tracked_resources(...)
    def __init__(self):
        ...
        self._setup_dhcp()
        ...

    def _setup_dhcp(self):
        """Initialize components to support DHCP."""
        # network_scheduler_driver 默认配置为 'neutron.scheduler.dhcp_agent_scheduler.WeightScheduler'
        self.network_scheduler = importutils.import_object(
            cfg.CONF.network_scheduler_driver
        )
        ...

而在 _notify_agents 函数 中，我们先来看 network 调度部分：

# neutron/api/rpc/agentnotifiers/dhcp_rpc_agent_api.py
class DhcpAgentNotifyAPI(object):

    def _notify_agents(self, context, method, payload, network_id):
        ...
        if ...
        elif cast_required:
            ...
            # 3. 调度网络到一个 DHCP Agent 上
            schedule_required = (
                method == 'subnet_create_end' or
                ...)
            if schedule_required:
                agents = self._schedule_network(admin_ctx, network, agents)
            ...

    def _schedule_network(self, context, network, existing_agents):
        """Schedule the network to new agents

        :return: all agents associated with the network
        """
        # 1. 选择并绑定 DHCP Agents（可以不止一个）
        new_agents = self.plugin.schedule_network(context, network) or []
        if new_agents:
            # 2. 将 network create 信息通过 RPC 通知每一个 DHCP Agent
            for agent in new_agents:
                self._cast_message(
                    context, 'network_create_end',
                    {'network': {'id': network['id']}}, agent['host'])
        ...

我们先来看 _schedule_network 函数中的第 1 步。

绑定 network 到 DHCP Agents

一图胜千言：

RPC 通知 DHCP Agent “network create” 信息

注：因为我们现在所在还是 Neutron Server 的进程，所以要调用 DHCP Agent（进程），需要通过 RPC。

我们先来看一下 RPC 调用概览图：

下边我们将从上图提到的 DhcpAgent::enable_dhcp_helper 函数的两个点出发来分析。

注：到这里，我们已经进入 DHCP Agent 进程，与 Neutron Server 的通信就要通过 RPC 了。

RPC 获取 Core Plugin 的 network 信息

我们现在在 DhcpAgent::enable_dhcp_helper 函数的第 1 步：

# neutron/agent/dhcp/agent.py
class DhcpAgent(manager.Manager):
    def enable_dhcp_helper(self, network_id):
        # 第 1 步
        network = self.safe_get_network_info(network_id)
        if network:
            # 第 2 步
            self.configure_dhcp_for_network(network)

在上一篇博文 Neutron Server 的启动过程中我们有提到在启动 Neutron Server 服务的过程当中，在最终启动服务的时候启动 Core Plugin(ML2) 的 RPC Listener：

# neutron/plugins/ml2/plugin.py
class Ml2Plugin(...):

    @log_helpers.log_method_call
    def start_rpc_listeners(self):
        """Start the RPC loop to let the plugin communicate with agents."""
        self._setup_rpc()
        self.topic = topics.PLUGIN	# 注意监听的 topic
        self.conn = n_rpc.create_connection()
        self.conn.create_consumer(self.topic, self.endpoints, fanout=False)
        ...
        return self.conn.consume_in_threads()

    def _setup_rpc(self):
        """Initialize components to support agent communication."""
        self.endpoints = [
            ...
            dhcp_rpc.DhcpRpcCallback(),
            ...
        ]

所以，在 DhcpAgent::enable_dhcp_helper 函数通过 RPC 调用 Core Plugin RPC 服务获取 network 信息最终会调用到 dhcp_rpc.DhcpRpcCallback() 这个 Endpoint。我们现在来看一下具体调用过程：
1. RPC Client 端

# neutron/agent/dhcp/agent.py
class DhcpAgent(manager.Manager):
    def enable_dhcp_helper(self, network_id):
        network = self.safe_get_network_info(network_id)
        ...

    def safe_get_network_info(self, network_id):
        try:
            network = self.plugin_rpc.get_network_info(network_id)
            if not network:
                LOG.debug('Network %s has been deleted.', network_id)
            return network
        ...

    def __init__(self, host=None, conf=None):
        ...
        self.plugin_rpc = DhcpPluginApi(topics.PLUGIN, self.conf.host)	# 注意 client 端的 topic
        ...

而 get_network_info 函数定义如下：

# neutron/agent/dhcp/agent.py
class DhcpPluginApi(object):
    """Agent side of the dhcp rpc API.

    This class implements the client side of an rpc interface.  The server side
    of this interface can be found in
    neutron.api.rpc.handlers.dhcp_rpc.DhcpRpcCallback.  For more information
    about changing rpc interfaces, see doc/source/devref/rpc_api.rst.
    """
    def get_network_info(self, network_id):
        """Make a remote process call to retrieve network info."""
        cctxt = self.client.prepare()
        # 注意这里是 RPC call 而不是 cast
        network = cctxt.call(self.context, 'get_network_info',
                             network_id=network_id, host=self.host)
        if network:
            return dhcp.NetModel(network)

2. RPC Server(Endpoint) 端

# neutron/api/rpc/handlers/dhcp_rpc.py
class DhcpRpcCallback(object):
    """DHCP agent RPC callback in plugin implementations.

    This class implements the server side of an rpc interface.  The client
    side of this interface can be found in
    neutron.agent.dhcp.agent.DhcpPluginApi.  For more information about
    changing rpc interfaces, see doc/source/devref/rpc_api.rst.
    """
    def get_network_info(self, context, **kwargs):
        """Retrieve and return extended information about a network."""
        network_id = kwargs.get('network_id')
        host = kwargs.get('host')
        ...
        plugin = directory.get_plugin()
        try:
            network = plugin.get_network(context, network_id)
        ...
        filters = dict(network_id=[network_id])
        subnets = plugin.get_subnets(context, filters=filters)
        ...
        network['subnets'] = sorted(subnets, key=operator.itemgetter('id'))
        network['ports'] = plugin.get_ports(context, filters=filters)
        return network

DHCP 服务建立过程

DhcpAgent::enable_dhcp_helper 函数的第 2 步就是要为 network 配置 DHCP 了。这部分特别特别重要！代码如下：

# neutron/agent/dhcp/agent.py
class DhcpAgent(manager.Manager):
    def enable_dhcp_helper(self, network_id):
        # 第 1 步
        network = self.safe_get_network_info(network_id)
        if network:
            # 第 2 步
            self.configure_dhcp_for_network(network)

    def configure_dhcp_for_network(self, network):
        if not network.admin_state_up:
            return

        for subnet in network.subnets:
            if subnet.enable_dhcp:
                if self.call_driver('enable', network):
                    self.update_isolated_metadata_proxy(network)
                    self.cache.put(network)
                    # After enabling dhcp for network, mark all existing
                    # ports as ready. So that the status of ports which are
                    # created before enabling dhcp can be updated.
                    self.dhcp_ready_ports |= {p.id for p in network.ports}
                break

而其中的 call_driver 函数定义如下：

# neutron/agent/dhcp/agent.py
class DhcpAgent(manager.Manager):
    def call_driver(self, action, network, **action_kwargs):
        """Invoke an action on a DHCP driver instance."""
        LOG.debug('Calling driver for network: %(net)s action: %(action)s',
                  {'net': network.id, 'action': action})
        try:
            # the Driver expects something that is duck typed similar to
            # the base models.
            # 1. 初始化 neutron.agent.linux.dhcp.Dnsmasq
            # 这里要特别注意，每次都会为每个 network 的 "New" DHCP Agent 新初始化一次 Dnsmasq 类，
            # 也就是说，对于每一个 "network-dhcpagent" 关系而言，它都会对应一个"独立"的 Dnsmasq 实例，
            # 这样一来，针对该实例而作的配置（如每个 network 的 DHCP 配置目录都是独一无二的
            # /opt/stack/data/neutron/dhcp/network.id）也都是独立于其他实例的
            driver = self.dhcp_driver_cls(self.conf,
                                          network,
                                          self._process_monitor,
                                          self.dhcp_version,
                                          self.plugin_rpc)
            # 2. 调用 neutron.agent.linux.dhcp.Dnsmasq 的 enable 函数
            getattr(driver, action)(**action_kwargs)
            return True
        ...

    def __init__(self, host=None, conf=None):
        ...
        # dhcp_driver 的默认值为 neutron.agent.linux.dhcp.Dnsmasq
        self.dhcp_driver_cls = importutils.import_class(self.conf.dhcp_driver)
        self.plugin_rpc = DhcpPluginApi(topics.PLUGIN, self.conf.host)
        ...

对于 DhcpAgent::call_driver 函数我们也要分两步来看。

1. 初始化 neutron.agent.linux.dhcp::Dnsmasq

# neutron/agent/linux/dhcp.py
class Dnsmasq(DhcpLocalProcess):
    ...

@six.add_metaclass(abc.ABCMeta)
class DhcpLocalProcess(DhcpBase):

    def __init__(self, conf, network, process_monitor, version=None,
                 plugin=None):
        super(DhcpLocalProcess, self).__init__(conf, network, process_monitor,
                                               version, plugin)
        self.confs_dir = self.get_confs_dir(conf)	# 值为 /opt/stack/data/neutron/dhcp
        self.network_conf_dir = os.path.join(self.confs_dir, network.id) # 值为 self.confs_dir/network.id
        fileutils.ensure_tree(self.network_conf_dir, mode=0o755) # 创建目录 self.confs_dir/network.id

@six.add_metaclass(abc.ABCMeta)
class DhcpBase(object):

    def __init__(self, conf, network, process_monitor,
                 version=None, plugin=None):
        ...
        # 注意：这里的 plugin 是 `DhcpAgent::call_driver` 函数中传入的
        #      DhcpPluginApi(topics.PLUGIN, self.conf.host)，别误解为 Core Plugin
        self.device_manager = DeviceManager(self.conf, plugin)
        ...

要特别注意上边初始化的 self.device_manager。

2. 调用 neutron.agent.linux.dhcp::Dnsmasq 的 enable 函数
这一步是重中之重，该函数主要做了一下事情：
1）初始化 DHCP 相关设备
A）创建一个 DHCP Port（这部分涉及到 Port 的创建，放到本文最后分析）
B）添加 DHCP namespace 及在该 namespace 添加 lo 网卡
C）在宿主机 root namespace 和 DHCP namespace 之间添加一个 Veth Pair；该 Veth 两端网卡分别是 tapXXX 及 ns-XXX（XXX 表示 Port.id 的前 11 位）
D）Metadata（这里暂未开启，后续博文再分析）及默认路由设置
2）初始化 DHCP 相关配置文件及启动 Dnsmasq 服务
A）生成 DHCP 相关配置文件：leases、host、addn_hosts、opts 文件
B）启动 Dnsmasq 进程

我们会用一个 UML 图来做说明：

最后启动起来的 Dnsmasq 的进程（样例）我们可以用 ps -elf 命令看一下：

1
2

stack@ubuntu-controller:~$ ps -elf | grep dnsmasq
5 S nobody   26045     1  0  80   0 -  7056 -      17:40 ?        00:00:00 dnsmasq --no-hosts  --strict-order --except-interface=lo --pid-file=/opt/stack/data/neutron/dhcp/e99e9fa4-1cd8-4ceb-8f39-1f3e5659461a/pid --dhcp-hostsfile=/opt/stack/data/neutron/dhcp/e99e9fa4-1cd8-4ceb-8f39-1f3e5659461a/host --addn-hosts=/opt/stack/data/neutron/dhcp/e99e9fa4-1cd8-4ceb-8f39-1f3e5659461a/addn_hosts --dhcp-optsfile=/opt/stack/data/neutron/dhcp/e99e9fa4-1cd8-4ceb-8f39-1f3e5659461a/opts --dhcp-leasefile=/opt/stack/data/neutron/dhcp/e99e9fa4-1cd8-4ceb-8f39-1f3e5659461a/leases --dhcp-match=set:ipxe,175 --bind-interfaces --interface=ns-2d01c8ce-ee --dhcp-range=set:tag0,172.16.101.0,static,86400s --dhcp-option-force=option:mtu,1500 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal

可以看到，该 Dnsmasq 进程正在监听的 interface 正是 DHCP namespace 中的 interface ns-XXX。

Bridge 初始化

在前面，DHCP 相关的 namespace、ns-XXX、tapXXX 设备已经建立完毕，但 DHCP 现在还不能正常工作，因为还差一个（Linux）Bridge。

关于 Brige 创建的代码隐藏的比较深。如果我们不考虑太多细节的话，Bridge 创建的代码流程如下：

**1. **Linux Brige Agent 启动之后会进入一个死循环，不断扫描系统中设备的变化，例如刚刚新建的 DHCP tapXXX 设备：

# neutron/plugins/ml2/drivers/agent/_common_agent.py
class CommonAgentLoop(service.Service):
    def daemon_loop(self):
        ...
        while True:
            ...
            device_info = self.scan_devices(previous=device_info, sync=sync)
            ...
            if (self._device_info_has_changes(device_info)
                or ...):
                try:
                    sync = self.process_network_devices(device_info)
                ...

**2. **根据是否新增或更新设备，进行下一步操作。此时是新增了 tapXXX 设备：

# neutron/plugins/ml2/drivers/agent/_common_agent.py
class CommonAgentLoop(service.Service):
    def process_network_devices(self, device_info):
        # 此时 device_info 内容为：
        #   {'current': set([...]), 'timestamps': {...},
        #    'removed': set([]), 'added': set(['tapXXX']), 'updated': set([])}
        ...
        # 关于 Security Group，对于 DHCP Port 而言，它不会为其添加各种防火墙规则，
        # 因为 SG 是用来保护虚拟机的，只会针对虚拟机的 Port 添加防火墙规则。
        # !!! 这部分我们放到 plug 虚拟机的 Port 的时候再讲。
        self.sg_agent.setup_port_filters(device_info.get('added'),
                                         device_info.get('updated'))
        # Updated devices are processed the same as new ones, as their
        # admin_state_up may have changed. The set union prevents duplicating
        # work when a device is new and updated in the same polling iteration.
        devices_added_updated = (set(device_info.get('added'))
                                 | set(device_info.get('updated')))
        if devices_added_updated:
            resync_a = self.treat_devices_added_updated(devices_added_updated)
        ...

**3. **RPC call 到 ML2 获取设备信息

# neutron/plugins/ml2/drivers/agent/_common_agent.py
class CommonAgentLoop(service.Service):
    def treat_devices_added_updated(self, devices):
        try:
            devices_details_list = self.plugin_rpc.get_devices_details_list(
                self.context, devices, self.agent_id, host=cfg.CONF.host)
        ...
        for device_details in devices_details_list:
            self._process_device_if_exists(device_details)	# 看下一步

# device_details 的一个内容样例如下：
# [{
# 	'profile': {
# 	},
# 	'network_qos_policy_id': None,
# 	'qos_policy_id': None,
# 	'allowed_address_pairs': [],
# 	'admin_state_up': True,
# 	'network_id': '9595178d-0bb5-4af4-9250-6b7d1982ddc9',
# 	'segmentation_id': 100,
# 	'mt': 1500,
# 	'device_owner': 'network: dhcp',
# 	'physical_network': 'default',
# 	'mac_address': 'fa: 16: 3e: b4: 69: dd',
# 	'device': 'tap4faba9e5-ed',	# DHCP tapXXX
# 	'port_security_enabled': False,
# 	'port_id': '4faba9e5-ed08-4ee1-a97b-bb656194e9a6',
# 	'fixed_ips': [{
# 		'subnet_id': '54e3c7e9-71fd-4e02-b397-f9989bc73a6f',
# 		'ip_address': '172.16.100.2'
# 	}],
# 	'network_type': 'vlan'
# }]

**4. **创建 Vlan interface/Bridge，并添加 Vlan interface/tapXXX 到 Bridge

# neutron/plugins/ml2/drivers/agent/_common_agent.py
class CommonAgentLoop(service.Service):
    def _process_device_if_exists(self, device_details):
        ...
        device = device_details['device']
        with self._ignore_missing_device_exceptions(device):
            ...
            if 'port_id' in device_details:
                ...
                segment = amb.NetworkSegment(
                    device_details.get('network_type'),
                    device_details['physical_network'],
                    device_details.get('segmentation_id'),
                    device_details.get('mtu')
                )
                ...
                # !!! 重点，下文 UML 图将详述
                interface_plugged = self.mgr.plug_interface(
                    network_id, segment,
                    device, device_details['device_owner']) # device_owner 为 'network: dhcp'

                ...
                # 在前文创建 DHCP port 的时候（DeviceManager::_setup_new_dhcp_port），
                # 数据库中写入的 port 的 admin_state_up 就是为 True（注意跟 network 的
                # admin_state_up 区分开来）
                if interface_plugged:
                    # 实际执行 ip link set tapXXX up/down
                    self.mgr.ensure_port_admin_state(
                        device, device_details['admin_state_up'])
                # update plugin about port status if admin_state is up
                if device_details['admin_state_up']:
                    if interface_plugged:
                        self.plugin_rpc.update_device_up(...)
                    ...

接下来的 LinuxBridgeManager::plug_interface 函数调用就进入到 neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent::LinuxBridgeManager 这个类了，详细操作过程请见下图：

创建（DHCP）Port

在前边小节“2.2.2.2.2 DHCP 服务建立过程”部分提到的 neutron.agent.linux.dhcp::Dnsmasq::enable 函数首先做的就是通过 RPC Call 调用 Core Plugin 的 RPC Endpoint neutron.api.rpc.handlers.dhcp_rpc::DhcpRpcCallback 的 create_dhcp_port 函数来创建一个 DHCP Port。

这里之所以将 DHCP Port 的创建过程单独拿出来分析，主要是因为 DHCP Port 跟一般的 Port 本质上只在于 device_owner 不一样，所以将其单独抽取出来我们可以借此分析一下 Port 的创建过程；另外，Port 本身是一种 Core Resource（同 Network、Subnet），所以有必要单独拿出来说。

我们先来看一下 DhcpRpcCallback::create_dhcp_port 函数：

# neutron/api/rpc/handlers/dhcp_rpc.py
class DhcpRpcCallback(object):
    def create_dhcp_port(self, context, **kwargs):
        """Create and return dhcp port information.
        """
        ...
        port['port']['device_owner'] = constants.DEVICE_OWNER_DHCP	# "network:dhcp"
        ...
        plugin = directory.get_plugin()	# Core Plugin (ML2)
        return self._port_action(plugin, context, port, 'create_port')

    def _port_action(self, plugin, context, port, action):
        """Perform port operations taking care of concurrency issues."""
        try:
            if action == 'create_port':
                return p_utils.create_port(plugin, context, port)
            ...

# neutron/plugins/common/utils.py
def create_port(core_plugin, context, port, check_allow_post=True):
    port_data = _fixup_res_dict(context, attributes.PORTS,
                                port.get('port', {}),
                                check_allow_post=check_allow_post)
    # 从这里我们就直接进入 Core Plugin (ML2) 的 Port（“标准”）创建过程
    return core_plugin.create_port(context, {'port': port_data})

最终调用的还是 Ml2Plugin::create_port 函数定义：

# neutron/plugins/ml2/plugin.py
class Ml2Plugin(...):
    def create_port(self, context, port):
        # 1. 在数据库中创建相关条目
        result, mech_context = self._create_port_db(context, port)

        # 2. 调用注册事件回调函数
        # notify any plugin that is interested in port create events
        kwargs = {'context': context, 'port': result}
        registry.notify(resources.PORT, events.AFTER_CREATE, self, **kwargs)

        try:
            self.mechanism_manager.create_port_postcommit(mech_context)
        except ml2_exc.MechanismDriverError:
            with excutils.save_and_reraise_exception():
                LOG.error(_LE("mechanism_manager.create_port_postcommit "
                              "failed, deleting port '%s'"), result['id'])
                self.delete_port(context, result['id'], l3_port_check=False)

        # 3. Security Group 更新
        # REVISIT(rkukura): Is there any point in calling this before
        # a binding has been successfully established?
        self.notify_security_groups_member_updated(context, result)

        try:
            # 只是对第 1 步已写入 ml2_port_bindings 的条目进行更新（添加 vif_type、vif_details）
            bound_context = self._bind_port_if_needed(mech_context)
        ...

        return bound_context.current

下边我们就按代码注释中的 3 步来对该函数进行分析。

1. 数据库条目创建
Ml2Plugin::create_port 函数会在一下这些数据表中写入条目：

在 ports 表添加新 port 的信息条目（id 及 mac 地址在自动生成，除非有作为创建参数传入）
利用 IPAM（这部分我们在前文 IPAM 处已经有介绍）为该 port 分配 IP 地址（除非有作为创建参数传入），并在 ipamallocations 表添加该 IP 信息条目，之后再在 ipallocations 表该 IP 信息条目（跟 ipamallocations 表的稍有不同）
在 portsecuritybindings 表添加一个条目
在 ml2_port_bindings 表添加一个条目

2. 调用注册事件回调函数
在前边 “2.2.1 事件订阅过程说明”中，我们提到了类 dhcp_rpc_agent_api::DhcpAgentNotifyAPI 在初始化的时候会订阅 Core Resources 的 AFTER_CREATE 事件，所以，当在数据库中创建完 Port 及相关信息条目后，就会调用注册的 DhcpAgentNotifyAPI::_native_event_send_dhcp_notification 函数。这次因为 Network 已经调度过了，所以该函数此次没做什么实质性的东西。

注：除了 DhcpAgentNotifyAPI 和 OVOServerRpcInterface 类在初始化的时候会订阅 port 的 AFTER_CREATE 事件之外，Service Plugin neutron.services.l3_router.l3_router_plugin::L3RouterPlugin 在初始化的时候也会订阅该事件（关于 L3 Agent 我们这里暂时不分析，放到后续博文当中）：

# neutron/services/l3_router/l3_router_plugin.py
class L3RouterPlugin(...):

    def __init__(self):
        ...
        if 'dvr' in self.supported_extension_aliases:
            l3_dvrscheduler_db.subscribe()

# neutron/db/l3_dvrscheduler_db.py
def subscribe():
    ...
    registry.subscribe(
        _notify_l3_agent_new_port, resources.PORT, events.AFTER_CREATE)
    ...

def _notify_l3_agent_new_port(resource, event, trigger, **kwargs):
    ...

3. Security Group 更新
self.notify_security_groups_member_updated(context, result) 最终调用的其实是 SecurityGroupAgentRpcCallbackMixin::security_groups_provider_updated 函数，但该函数是一个空（NOOP）函数（可以看一下函数的注释）：

class SecurityGroupAgentRpcCallbackMixin(object):
    def security_groups_provider_updated(self, context, **kwargs):
        """Callback for security group provider update.

        This is now a NOOP since provider rules are static. The server just
        generates the notification for agents running older versions that have
        IP-specific rules.
        """