【学习】五、Nova 组件详解

发表于 2017-09-12 更新于 2021-05-17 分类于 SRE 阅读次数： Valine：

Nova组件详解

nova-api

nova-api 是 nova 组件的门户，所有对 nova 的请求都首先由 nova-api 处理，nova 对外暴露几个接口，也就是 endpoint，查看 endpoint：

1	openstack endpoint show nova

nova-api 对接收到的请求会做如下操作：

检查传递的参数是否合法
调用 nova 的其他子服务来处理请求
格式化其他子服务返回的结果并返回给客户端

nova-api 可以接受哪些请求？
简单来说，只要是与虚拟机生命周期管理相关的操作，nova-api 都可以相应，大部分的操作在 dashboard 上面都可以找到，如图所示：

nova-conductor

nova-compute 需要访问数据库获取 instance 的信息，但是 nova-compute 不会直接访问数据库，需要通过 nova-conductor 实现数据的访问。

这样做有两个好处：

更好的系统安全性
更好的系统伸缩性

更好的系统安全性

在 OpenStack 的早期版本中，nova-compute 可以直接访问数据库，但这样存在非常大的安全隐患。因为 nova-compute 这个服务是部署在计算节点上的，为了能够访问控制节点上的数据库，就必须在计算节点的 /etc/nova/nova.conf 中配置访问数据库的连接信息，比如

1 2	[database] connection = mysql+pymysql://root:secret@controller/nova?charset=utf8

试想任意一个计算节点被黑客入侵，都会导致部署在控制节点上的数据库面临极大风险。为了解决这个问题，从 G 版本开始，Nova 引入了一个新服务 nova-conductor，将 nova-compute 访问数据库的全部操作都放到 nova-conductor 中，而且 nova-conductor 是部署在控制节点上的。这样就避免了 nova-compute 直接访问数据库，增加了系统的安全性。

更好的伸缩性

nova-conductor 将 nova-compute 与数据库解耦之后还带来另一个好处：提高了 nova 的伸缩性。nova-compute 与 conductor 是通过消息中间件交互的。

这种松散的架构允许配置多个 nova-conductor 实例。在一个大规模的 OpenStack 部署环境里，管理员可以通过增加 nova-conductor 的数量来应对日益增长的计算节点对数据库的访问。

nova-scheduler

在 /etc/nova/nova.conf 中，nova 通过 scheduler_driver、scheduler_available_filters、scheduler_default_filters 来配置 nova-scheduler。

filter_scheduler

filter_scheduler 是 nova-scheduler 默认的调度器，调度过程分为两步：

通过 filter 选择满足条件的计算节点（运行 nova-compute）
通过权重计算（weighting）选择在最优的计算节点上创建 instance

调度过程

Filter

当 filter-scheduler 需要执行调度操作时，会让 filter 对计算节点进行判断，filter 返回 True 或 False。Nova.conf 中的 scheduler_available_filters 选项用于配置 scheduler 可用的 filter，默认是所有 nova 自带的 filter 都可以用于滤操作。

1	scheduler_available_filters = nova.scheduler.filters.all_filters

另外还有一个选项 scheduler_default_filters，用于指定 scheduler 真正使用的 filter，默认值如下

scheduler_default_filters = RetryFilter, AvailabilityZoneFilter, RamFilter, DiskFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter

RetryFilter

RetryFilter 的作用是过滤掉已经调度过的节点，比如上次选择部署在计算节点 A 上面，但是由于某种原因失败了，那么这次就不会再部署。

AvailabilityZoneFilter

为提高容灾性和提供隔离服务，可以将计算节点划分到不同的Availability Zone中。例如把一个机架上的机器划分在一个 Availability Zone 中。 OpenStack 默认有一个命名为 “Nova” 的 Availability Zone，所有的计算节点初始都是放在 “Nova” 中。用户可根据需要创建自己的 Availability Zone。nova-scheduler 会将不属于指定 AvailableZone 的计算节点过滤掉。

RamFilter

RamFilter 将不能满足 flavor 内存需求的计算节点过滤掉。

对于内存有一点需要注意：为了提高系统的资源使用率，OpenStack 在计算节点可用内存时允许 overcommit，也就是可以超过实际内存大小。超过的程度是通过 nova.conf 中 ram_allocation_ratio 这个参数来控制的，默认值为 1.5

1	ram_allocation_ratio = 1.5

其含义是：如果计算节点的内容为 10GB，OpenStack 则会认为它有 15GB（10*1.5）内存。

DiskFilter

DiskFilter 将不能满足 flavor 磁盘需求的计算节点过滤掉。Disk 同样允许 overcommit，通过 nova.conf 中 disk_allocation_ratio 控制，默认值为 1

1	disk_allocation_ratio = 1.0

CoreFilter

CoreFilter 将不能满足 flavor vCPU 需求的计算节点过滤掉。vCPU 同样允许 overcommit，通过 nova.conf 中 cpu_allocation_ratio 控制，默认值为 16

1	cpu_allocation_ratio = 16.0

ComputeFilter

ComputeFilter 保证只有 nova-compute 服务正常工作的计算节点才能够被 nova-scheduler调度。ComputeFilter 显然是必选的 filter。

ComputeCapabilitiesFilter

ComputeCapabilitiesFilter 根据计算节点的特性来筛选。这个比较高级，我们举例说明。
例如我们的节点有 x86_64 和 ARM 架构的，如果想将 Instance 指定部署到 x86_64 架构的节点上，就可以利用 ComputeCapabilitiesFilter。还记得 flavor 中有个 Metadata 吗，Compute 的 Capabilitie s就在 Metadata中指定。

ImagePropertiesFilter

ImagePropertiesFilter 根据所选 image 的属性来筛选匹配的计算节点。跟 flavor 类似，image 也有 metadata，用于指定其属性。

例如希望某个 image 只能运行在 kvm 的 hypervisor 上，可以通过 “Hypervisor Type” 属性来指定。

ServerGroupAntiAffinityFilter

ServerGroupAntiAffinityFilter 可以尽量将 Instance 分散部署到不同的节点上。

例如有 inst1，inst2 和 inst3 三个 instance，计算节点有 A,B 和 C。为保证分散部署，进行如下操作：

创建一个 anti-affinity 策略的 server group “group-1”

1	nova server-group-create --policy anti-affinity group-1

请注意，这里的 server group 其实是 instance group，并不是计算节点的 group。

依次创建 Instance inst1, inst2和inst3并放到group-1中

1
2
3

nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst1
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst2
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst3

因为 group-1 的策略是 AntiAffinity，调度时 ServerGroupAntiAffinityFilter 会将 inst1, inst2 和 inst3 部署到不同计算节点 A, B 和 C。目前只能在 CLI 中指定 server group 来创建 instance。

创建 instance 时如果没有指定 server group，ServerGroupAntiAffinityFilter 会直接通过，不做任何过滤。

ServerGroupAffinityFilter

与 ServerGroupAntiAffinityFilter 的作用相反，ServerGroupAffinityFilter 会尽量将 instance 部署到同一个计算节点上。方法类似

创建一个 affinity 策略的 server group “group-2”

1	nova server-group-create --policy affinity group-2

依次创建 instance inst1, inst2 和 inst3 并放到 group-2 中

1
2
3

nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst1
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst2
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst3

因为 group-2 的策略是 Affinity，调度时 ServerGroupAffinityFilter 会将 inst1, inst2 和 inst3 部署到同一个计算节点。创建 instance 时如果没有指定 server group，ServerGroupAffinityFilter 会直接通过，不做任何过滤。

weight

通过过滤之后会计算权重值，根据计算节点空闲内存来计算权重值，内存越多，权重值越大。

日志

1	/var/log/nova/scheduler.log

注：要显示 DEBUG 日志，需要在 /etc/nova/nova.conf 中打开 debug 选项

1 2	[DEFAULT] debug = True

nova-compute

nova-compute 通过 Driver架构支持多种 Hypervisor。

我们可以在 /opt/stack/nova/nova/virt/ 目录下查看到 OpenStack 源代码中已经自带了上面这几个 Hypervisor 的 Driver：

某个特定的计算节点上只会运行一种 Hypervisor，只需在该节点 nova-compute 的配置文件 /etc/nova/nova.conf 中配置所对应的 compute_driver 就可以了。

nova-compute 的功能可以分为两类：

定时向 OpenStack 报告计算节点的状态
实现 instance 生命周期的管理

定时向 OpenStack 报告计算节点的状态

前面我们看到 nova-scheduler 的很多 Filter 是根据算节点的资源使用情况进行过滤的。比如 RamFilter 要检查计算节点当前可以的内存量；CoreFilter 检查可用的 vCPU 数量；DiskFilter 则会检查可用的磁盘空间。

那这里有个问题：OpenStack 是如何得知每个计算节点的这些信息呢？答案是 nova-compute 会定期向 OpenStack 报告。

nova-compute 是如何获得当前计算节点的资源使用信息的？nova-compute 可以通过 Hypervisor 的 driver 拿到这些信息。

实现 instance 生命周期的管理

OpenStack 对 instance 最主要的操作都是通过 nova-compute 实现的，包括 instance 的 launch、shutdown、reboot、suspend、resume、terminate、resize、migration、snapshot 等。

本节讨论实例的创建操作。

nova-compute 创建 instance 的过程可以分为 4 步：

为 instance 准备资源
创建 instance 的镜像文件
创建 instance 的 XML 定义文件
创建虚拟网络并启动虚拟机

为 instance 准备资源

nova-compute 首先会根据指定的 flavor 依次为 instance 分配内存、磁盘空间和 vCPU。可以在日志中看到这些细节。

网络资源也会提前分配。

创建 instance 的镜像文件

OpenStack 启动一个 instance 时，会选择一个 image，这个 image 由 Glance 管理。 nova-compute会：

首先将该 image 下载到计算节点
然后将其作为 backing file 创建 instance 的镜像文件

从 Glance 下载 image

nova-compute 首先会检查 image 是否已经下载（比如之前已经创建过基于相同 image 的 instance）。如果没有，就从 Glance 下载 image 到本地。由此可知，如果计算节点上要运行多个相同 image 的 instance，只会在启动第一个 instance 的时候从 Glance 下载 image，后面的 instance 启动速度就大大加快了。

可以看到：

image（ID为 917d60ef-f663-4e2d-b85b-e4511bb56bc2）是 qcow2 格式，nova-compute 将其下载。Nova 默认会通过 qemu-img 转换成 raw 格式，以提高 IO 性能。
image 的存放目录是 /opt/stack/data/nova/instances/_base，这是由 /etc/nova/nova.conf 的下面两个配置选项决定的。

1 2	instances_path = /opt/stack/data/nova/instances base_dir_name = _base

下载的 image 文件被命名为 60bba5916c6c90ed2ef7d3263de8f653111dd35f，这是 image id 的 SHA1 哈希值。

为 instance 创建镜像文件

有了 image 之后，instance 的镜像文件直接通过 qemu-img 命令创建，backing file 就是下载的 image。

可以通过 qume-info 查看 disk 文件的属性：

这里有两个容易搞混淆的术语，在此特别说明一下：

image，指的是 Glance 上保存的镜像，作为 instance 运行的模板。计算节点将下载的 image 存放在 /opt/stack/data/nova/instances/_base 目录下。
镜像文件，指的是 instance 启动盘所对应的文件
二者的关系是：image 是镜像文件的 backing file。image 不会变，而镜像文件会发生变化。比如安装新的软件后，镜像文件会变大。

创建 instance 的 XML 定义文件

创建的 XML 文件会保存到该 instance 目录 /opt/stack/data/nova/instances/f1e22596-6844-4d7a-84a3-e41e6d7618ef，命名为 libvirt.xml

创建虚拟网络并启动 instance

本环境用的是 linux-bridge 实现的虚拟网络。

CLI 查看实例：

1	virsh list

【学习】四、Nova 综述及 OpenStack 通用设计思路

发表于 2017-09-12 更新于 2021-05-17 分类于 SRE 阅读次数： Valine：

nova架构

nova组件

可分为以下几类

api

nova-api

接收和响应客户的 API 调用。除了提供 OpenStack 自己的API，nova-api 还支持 Amazon EC2 API。

compute core

nova-scheduler

虚机调度服务，负责决定在哪个计算节点上运行虚机

nova-compute

管理虚机的核心服务，通过调用 Hypervisor API 实现虚机生命周期管理

Hypervisor

计算节点上跑的虚拟化管理程序，虚机管理最底层的程序。不同虚拟化技术提供自己的 Hypervisor。常用的 Hypervisor 有 KVM，Xen， VMWare 等

nova-conductor

nova-compute 经常需要更新数据库，比如更新虚机的状态。出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor，这个我们后面详细讨论。

Console Interface

nova-console

用户可以通过多种方式访问虚机的控制台： nova-novncproxy，基于 Web 浏览器的 VNC 访问 nova-spicehtml5proxy，基于 HTML5 浏览器的 SPICE 访问 nova-xvpnvncproxy，基于 Java 客户端的 VNC 访问

nova-consoleauth

负责对访问虚机控制台请亲提供 Token 认证

nova-cert

提供 x509 证书支持

Database

Nova 会有一些数据需要存放到数据库中，一般使用 MySQL。

数据库安装在控制节点上。 Nova 使用命名为 “nova” 的数据库。

Message Queue

在前面我们了解到 Nova 包含众多的子服务，这些子服务之间需要相互协调和通信。

为解耦各个子服务，Nova 通过 Message Queue 作为子服务的信息中转站。所以在架构图上我们看到了子服务之间没有直接的连线，是通过 Message Queue 联系的。

Nova组件如何协同工作

1、只有nova-compute组件需要安装在计算节点上

2、可以使用命令查看nova组件分别安装在哪些节点上

1	nova service-list

3、虚拟机创建流程：

客户向 api 发送请求，api 传递给消息队列，消息队列通知 scheduler，scheduler 通过调度算法确定在哪一台虚拟机上面创建，发消息给消息队列，消息队列通知该计算节点的 compute 组件，compute 创建虚拟机，发送消息给消息队列，消息队列传递给 conductor 组件，conductor 组件写入更新数据库。

OpenStack通用设计思路

每一个 OpenStack 组件都通过 api 对外提供服务，还可以运行多个 api 实现高可用。
对于某项操作，如果有多个实体能够完成任务，那么一般都会有 scheduler 调度服务，如 nova、cinder。
worker 工作服务：如 nova 的nova-compute服务，如果调度不过来那么可以增加scheduler服务，如果计算资源不够可以增加计算节点。
采用基于 driver 的框架。以 nova 为例，OpenStack 的计算节点支持多种 Hypervisor。包括 KVM, Hyper-V, VMWare, Xen, Docker, LXC 等。 nova-compute 为这些 Hypervisor 定义了统一的接口，Hypervisor 只需要实现这些接口，就可以 driver 的形式即插即用到 OpenStack 中。

配置文件 /etc/nova/nova.conf 中由 compute_driver 配置项指定该计算节点使用哪种 Hypervisor 的 driver。glance 支持多种存储后端，也是一种 driver 架构，cinder、neutron 都是。
消息队列服务。将每一个服务解耦，实现异步调用。
database。每一个服务的状态信息都在数据库中维护。

【学习】三、Glance 以及如何使用 CLI

发表于 2017-09-07 更新于 2021-05-17 分类于 SRE 阅读次数： Valine：

Glance架构

glance-api

glance-api 是系统后台运行的服务进程。对外提供 REST API，响应 image 查询、获取和存储的调用。

glance-api 不会真正处理请求。如果操作是与 image metadata（元数据）相关，glance-api 会把请求转发给 glance-registry；如果操作是与 image 自身存取相关，glance-api 会把请求转发给该 image 的 store backend。

glance-registry

glance-registry 是系统后台运行的服务进程。负责处理和存取 image 的 metadata，例如 image 的大小和类型。

glance支持的镜像格式

Store backend

Glance 自己并不存储 image。真正的 image 是存放在 backend 中的。 Glance 支持多种 backend，包括

A directory on a local file system（这是默认配置）
GridFS
Ceph RBD
Amazon S3
Sheepdog
OpenStack Block Storage (Cinder)
OpenStack Object Storage (Swift)
VMware ESX

具体使用哪种 backend，是在 /etc/glance/glance-api.conf中配置的。

1
2
3

glance image-list # 查看有哪些镜像。
glance image-create --name cirros --file /tmp/cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare --progress # 上传镜像，--progress用来显示百分比
glance image-delete imageID

CLI

不同服务用的命令虽然不同，但这些命令使用方式却非常类似，可以举一反三。

1. 执行命令之前，需要设置环境变量

这些变量包含用户名、Project、密码等；如果不设置，每次执行命令都必须设置相关的命令行参数。如：

1	$ . admin-openrc

2. 各个服务的命令都有增、删、改、查的操作

其格式是

CMD <obj>-create [parm1] [parm2]…
CMD <obj>-delete [parm]
CMD <obj>-update [parm1] [parm2]…
CMD <obj>-list CMD <obj>-show [parm]

例如 glance 管理的是 image，那么 CMD 就是 glance，obj 就是 image，对应的命令就有：

glance image-create
glance image-delete
glance image-update
glance image-list
glance image-show

再比如 neutron 负责管理网络和子网，那么 CMD 就是 neutron，obj 就是 net 和 subnet，对应的命令就有：

网络相关操作

neutron net-create
neutron net-delete
neutron net-update
neutron net-list
neutron net –show

子网相关操作

neutron subnet-create
neutron subnet-delete
neutron subnet-update
neutron subnet-list
neutron subnet–show

有的命令可以省略，比如 nova 下面的操作都是针对 instance：

1
2
3

nova boot
nova delete
nova list nova show

3. 每个对象都有 ID

delete，show 等操作都以 ID 为参数

4. 使用help查看命令的用法

例如：glance help

查看 glance image-update 的用法：

1	glance help image-update

Troubleshooting

日志位于 /etc/log/glance

glance主要有两个日志：glance_api.log 以及 glance_registry.log

glance-api：记录 REST API 调用情况
glance-registry：记录 Glance 服务处理请求的过程以及数据库操作

【学习】二、Keystone 的一些基本概念

发表于 2017-09-07 更新于 2021-05-17 分类于 SRE 阅读次数： Valine：

基本概念

Keystone的作用：

管理用户及其权限
维护OpenStack的endpoint
Authentication（认证）和 Authorization（鉴权）

一个用户（user）可以有多个角色（role），user 可以是用户也可以是其他服务，user 可以属于多个 project，project 用于将 OpenStack 的资源进行隔离。

user 访问 OpenStack 时，Keyston 会对其进行验证，它使用的是密码这个时候，然后 Keystone 会给它发一个 Token 作为后续访问的 Credentials。

Credentials 包括：

用户名/密码
Token
API Key
其他高级方式

Token 是由数字和字母组成的字符串，User 成功 Authentication 后 Keystone 生成 Token 并分配给 User。

Token 用做访问 Service 的 Credential
Service 会通过 Keystone 验证 Token 的有效性
Token 的有效期默认是 24 小时

每个service会提供若干个Endpoint，service通过endpoint暴露自己的API。

使用以下命令查看endpoint：

1 2	source devstack/openrc admin admin openstack catalog list

使用以下命令查看角色：

1	openstack role list

service通过 /etc/nova/policy.json 对 role 进行访问控制。

Troubleshoot

OpenStack排查问题主要通过日志。

Keystone 主要有两个日志，一个是 keystone.log，一个是 keystone_access.log，在 /var/log/keystone 中。

（在newton版本中，我只看到了第一个日志。）

如果需要得到最详细的日志信息，可以在 /etc/keystone/keystone.conf 中打开 debug 选项。

【学习】一、虚拟化原理及 OpenStack 架构

发表于 2017-09-07 更新于 2021-05-17 分类于 SRE 阅读次数： Valine：

虚拟化介绍

宿主机通过 Hypervisor 程序将自己的硬件资源虚拟化。

虚拟化原理

CPU虚拟化

一个虚拟机在宿主机中其实就是一个qemu-kvm进程，而每一个虚拟的CPU则是进程中的一个线程，CPU可以超配（overcommit）

内存虚拟化

kvm需要完成VA虚拟内存–>PA物理内存–>MA机器内存直接的地址转换。虚机OS不能直接访问实际机器内存，所以KVM要负责映射客户物理内存到实际机器内存的转换（PA–>MA）。内存也可以overcommit。

存储虚拟化

KVM的存储虚拟化是通过存储池（Storage Pool）和卷（Volume）来管理的。

Storage Pool 是宿主机上可以看到的一片存储空间，可以是多种类型。

KVM将宿主机目录 /var/lib/libvirt/images 作为默认的 Storge Pool。KVM 是怎么知道要把 /var/lib/libvirt/images 这个目录当做默认 Storage Pool 的呢？KVM 所有可以使用的 Storage Pool 都定义在宿主机的 /etc/libvirt/storage 目录下，每一个 Pool 一个 xml 文件，默认有一个default.xml。

KVM 支持多种 Volume 格式

raw 是默认格式，即原始磁盘镜像格式，移植性好，性能好，但大小固定，不能节省磁盘空间。

qcow2 是推荐使用的格式。cow 表示 copy on write，能够节省磁盘空间，支持 AES 加密，支持 zlib 压缩，支持多快照，功能很多。

vmdk 是 VMWare 的虚拟磁盘格式，也就是说 VMWare 虚机可以直接在 KVM上运行。这种是目录类型，还有LVM类型的Storge Pool，还有 iscsi，ceph

LVM 类型的 Storage Pool

不仅一个文件可以分配给客户机作为虚拟磁盘，宿主机上 VG 中的 LV 也可以作为虚拟磁盘分配给虚拟机使用。不过，LV 由于没有磁盘的 MBR 引导记录，不能作为虚拟机的启动盘，只能作为数据盘使用。

宿主机上的 VG 就是一个 Storage Pool，VG 中的 LV 就是 Volume。 LV 的优点是有较好的性能；不足的地方是管理和移动性方面不如镜像文件，而且不能通过网络远程使用。

网络虚拟化

虚拟机的虚拟网卡可以通过桥接的方式桥接到物理网卡。

Linux Bridge

Linux Bridge 是 Linux 上用来做 TCP/IP 二层协议交换的设备，其功能大家可以简单的理解为是一个二层交换机或者 Hub。

参考：https://mp.weixin.qq.com/s?__biz=MzIwMTM5MjUwMg==&mid=2653587933&idx=1&sn=958532f257d5b4ba575f297a0b66db25&chksm=8d3081c4ba4708d2199ddfaa151e93da2905eab86e963f194d1a7f90bb77535e5de5b7f83d52&scene=21#wechat_redirect

esben@all-in-one:~$ brctl show # 查看 Linux Bridge 的配置
bridge name	bridge id		    STP enabled	  interfaces
virbr0		8000.525400d43ff6	yes		      virbr0-nic

virsh list --all # 查看所有的虚拟机
virsh start VM # 启动虚拟机
virsh domiflist VM1 # 查看虚拟机网卡信息

参考：https://mp.weixin.qq.com/s?__biz=MzIwMTM5MjUwMg==&mid=2653587932&idx=1&sn=d8442e02c9d19114ed2a64b3375b07f6&chksm=8d3081c5ba4708d326b27352349a01c2f2175c0cc7d56944f40af2fc2c64ffdc9a5548f1b89e&scene=21#wechat_redirect

virbr0

virbr0 是 KVM 默认创建的一个 Bridge，其作用是为连接其上的虚机网卡提供 NAT 访问外网的功能。为连接其上的其他虚拟网卡提供 DHCP 服务。

virbr0 使用 dnsmasq 提供 DHCP 服务，可以在宿主机中查看该进程信息。

1 2	esben@all-in-one:~$ ps aux \| grep dnsmasq esben 6841 0.0 0.0 14224 1024 pts/22 R+ 19:14 0:00 grep --color=auto dnsmasq

VLAN

VLAN 将一个交换机分成了多个交换机，限制了广播的范围，在二层将计算机隔离到不同的 VLAN 中。VLAN 的隔离是二层上的隔离，A 和 B 无法相互访问指的是二层广播包（比如 arp）无法跨越 VLAN 的边界。但在三层上（比如IP）是可以通过路由器让 A 和 B 互通的。概念上一定要分清。

通常交换机的端口有两种配置模式： Access 和 Trunk：

Access 口

这些端口被打上了 VLAN 的标签，表明该端口属于哪个 VLAN。不同 VLAN 用 VLAN ID 来区分，VLAN ID 的范围是 1-4096。 Access 口都是直接与计算机网卡相连的。

Trunk 口

假设有两个交换机 A 和 B，连接 A 和 B 的口就是 Trunk 口，允许所有 VLAN 的数据通过。

eth0 是宿主机上的物理网卡，有一个命名为 eth0.10 的子设备与之相连。 eth0.10 就是 VLAN 设备了，其 VLAN ID 就是 VLAN 10。

这样的配置其效果就是：宿主机用软件实现了一个交换机（当然是虚拟的），上面定义了一个 VLAN10。

eth0.10，brvlan10 和 vnet0 都分别接到 VLAN10 的 Access口上。

而 eth0 就是一个 Trunk 口。VM1 通过 vnet0 发出来的数据包会被打上 VLAN10 的标签。

eth0.10 的作用是：定义了 VLAN10
brvlan10 的作用是：Bridge 上的其他网络设备自动加入到 VLAN10 中

参考：https://mp.weixin.qq.com/s?__biz=MzIwMTM5MjUwMg==&mid=2653587920&idx=1&sn=79332fb8fd8370b8d6b7d9728c383008&chksm=8d3081c9ba4708df9fcff17839e3c0fbb53a82298799c15ee45889f830a0087a46672505f115&scene=21#wechat_redirect

Linux Bridge + VLAN = 虚拟交换机

物理交换机存在多个 VLAN，每个 VLAN 拥有多个端口。同一 VLAN 端口之间可以交换转发，不同 VLAN 端口之间隔离。所以交换机其包含两层功能：交换与隔离。
Linux 的 VLAN 设备实现的是隔离功能，但没有交换功能。
Linux Bridge 专门实现交换功能。
Linux Bridge 加 VLAN 在功能层面完整模拟现实世界里的二层交换机。eth0 相当于虚拟交换机上的 trunk 口。