大多数商业化软件产品一般会通过实现GUI(Graphical User Interface)或者TUI(Text-based User Interface/Textual User Interface/Terminal User Interface)来降低软件的使用难度。本文简要介绍一个TUI库: newt。

newt是由RedHat开发，主要用在RatHat的Linux发行版本(RHEL, Fedora和CentOS)的安装程序项目Anaconda中。NEWT的全称是: Not Erik’s Windowing Toolkit，它基于S-Lang库实现。

因为newt是用于Linux发行版本的安装程序中，因而它的运行空间非常有限，需要保证程序尽可能小，所以在设计时选择使用C语言进行开发，也尽量不支持多余特性。于是在设计之初就不支持事件驱动。在支持事件驱动的窗口库中，有一个事件循环监听事件发生，根据发生的事件展示不同的窗口。在newt中，窗口创建和销毁基于栈模式，新创建的窗口位于之前的窗口之上，且只能展示最上层窗口，当最上层窗口销毁之后才能展示下边的窗口。这也就是说所有窗口都为模态窗口(model windows)。这种特性限制了newt库本身只适合用于完成顺序的程序流程，一个典型的场景就是程序的安装向导。SHELL程序往往也是顺序的流程，从SHELL程序转换为newt窗口程序完全不涉及程序流程的改变，实现非常简单。

Celery是一个基于消息传递的分布式任务队列。与单纯的消息队列相比较，队列中传递的消息为任务(Task/Job)信息，而不是数据类信息，Celery基于这些消息完成了任务信息的管理。实现这种任务管理的相似项目还有Gearman，只不过这个项目已经很久未更新了，更推荐使用Celery。

Celery支持同步和异步执行两种模式。同步模式为任务调用方等待任务执行完成，这种方式等同于RPC(Remote Procedure Call)， 异步方式为任务在后台执行，调用方调用后就去做其他工作，之后再根据需要来查看任务结果。Celery自己没有实现消息队列，而是直接已存在的消息队列作为Broker角色。官方推荐的Broker为RabbitMQ，除此之外，Redis、Beanstalkd、MongoDB等也都支持，具体可参考官方文档。

Celery整体架构可以理解为下图:

默认情况下，在OpenStack上私有网络上开启的虚拟机接口必须配置IP，否则网络包无法到达该接口。而之前的文章<<OpenStack私有网络旁路部署虚拟防火墙>>最后提到某些厂商的VFW只支持二层透明接入，那么我们怎样在OpenStack环境上跑通这样的VFW实例呢？本文来通过实例说明。

上篇文章的示例网络拓扑如下:

之前的文章<<OpenStack私有网络安全防护>>介绍了在私有网络中将虚拟防火墙(以下称为VFW)串联接入的方法。本文来介绍旁路部署VFW, 通过策略路由实现防火墙接入的方法。

逻辑网络拓扑如下:

上篇文章<<D-Bus实例介绍>>中简要介绍了D-Bus的基本概念，其中提到systemd、NetworkManager等系统服务导出了D-Bus API供其他程序来调用。本文通过示例来说明这些API的查找与调用。

上篇文章我们提到D-Bus的object可以实现多个Interface。D-Bus规范中标准化了一些接口，这些接口对于我们调用其他服务提供的D-Bus API非常有帮助。

我们主要来看其中的两个:

• org.freedesktop.DBus.Introspectable

它有一个方法:

1

org.freedesktop.DBus.Introspectable.Introspect (out STRING xml_data)

它会返回一个包含有对象(object), 接口(interface), 方法(methods), 信号(signals)，属性(properties)等信息的XML字符串。对象如果实现这个接口, 我们就可以通过调用该方法了解这个对象对外提供的所有信息。

XML字符串的解析方法可以参考官方文档:
https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format

D-Bus是Linux及其他类UNIX系统上的一种IPC(Interprocess communication)机制。相较于传统的管道(PIPE)、Socket等原生基于字节流的IPC方式，D-Bus提供了基于独立Message的传输方式，应用程序使用起来更加简单。D-Bus的设计初衷是为Linux桌面环境上的一系列应用程序提供通信方式，它的设计里保留了许多对上层框架设计考虑的元素。

D-Bus的常用架构与传统的Socket一对一通信模式不同，它基于中间消息路由转发的模式来实现, 如下图:

Meltdown漏洞暴发之后，各云厂商已陆陆续续升级宿主机，升级Guest是否有较大的性能影响, 是否应该升级Guest虚拟机等问题又困扰着云租户们。

本文基于实例来分析Guest虚拟机的性能影响。

首先来看Meltdown的原理。现代CPU架构在不同的安全等级运行指令。内核需要直接操作硬件，运行于最高权限，而几乎所有的应用程序都运行于各低权限上。用户态进程通过系统调用访问内核数据。一般情况下，CPU在执行时使用虚拟内存地址，内核使用页表来控制虚拟内存与物理内存的映射。用户态进程不能访问映射给内核的内存页。这些映射关系的计算较为耗时，因而CPU使用TLB(Translation lookaside buffer)来存储计算后的映射关系。从TLB中移除这些映射再重新计算并缓存会消耗性能，因而内核实现上会尽可能减少刷新TLB，于是内核将用户态和内核的数据都映射进用户态页表中。正常情况下，这不存在安全风险，页表的权限可以阻止用户态进程访问内核数据。

之前的文章<<VMware vSphere东西向网络防护>>介绍了在VMware vSphere平台上如何通过操作虚拟交换机及虚拟接口来实现二层网络的微隔离。本文通过代码实例来说明调用API实现其中涉及的相关操作。

我们使用VMware官方的Python SDK来实现，SDK地址如下:

• https://github.com/vmware/pyvmomi

首先使用pip安装pyvmomi, 这里我们使用支持vSphere6.5的版本:

1

pip install pyvmomi==6.5.0.2017.5-1

下面介绍使用Python SDK的基本流程。

之前的文章<<VMware vSphere平台端口镜像>>介绍了VMware vSphere环境下虚拟交换机的端口镜像机制，本文来介绍在OpenvSwitch环境中如何实现端口镜像。

OVS上实现端口镜像的基本流程如下:

• 创建mirror，在mirror中指定镜像数据源及镜像目的地
• 将创建的mirror应用到bridge中

镜像数据源可以通过下面几个选项来指定:

• select_all: 布尔值，设置为true时，进出该mirror所生效的bridge上的每个数据包都将被镜像
• select_dst_port: 从该port离开虚拟交换机的数据包将会被镜像，从Guest角度看是Guest网络接口的流入方向
• select_src_port: 从该port进入虚拟交换机的数据包将会被镜像，从Guest角度看是Guest网络接口的流出方向
• select_vlan: 指定特定VLAN做为数据源，整个VLAN的数据包都会镜像到目的地

镜像目的地可以用下面选项来指定:

• output_port: 将数据包镜像到特定的port
• output_vlan: 将数据包镜像到指定VLAN, 原始数据的VLAN tag会被剥掉。若镜像多个VLAN到同一个VLAN，没有办法区分镜像后的数据包来源于哪个VLAN。

在我们的QEMU/KVM虚拟化环境中，当所有的虚拟机启动时需要自动添加一个ivshmem设备，用于虚拟机与宿主机之间通信。为了添加该设备，我们需要在调用QEMU时，添加上ivshmem设备的相关参数，例如:

1

-device ivshmem,shm=fg_i3,size=8m,bus=pci.0,addr=0x1f

Libvirt使用XML文件来定义虚拟机配置，并根据XML文件来生成QEMU命令行参数，进而执行QEMU程序来启动虚拟机实例。我们可以在所有虚拟机的XML文件的<devices>节点中添加上<shmem>配置，如:

1
2
3
4
5

<shmem name="fg_i3">
    <model type="ivshmem" />
    <size unit='M'>8</size>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x0' />
</shmem>

这样，libvirt启用QEMU实例时，则会添加如下参数:

1

-device ivshmem,id=shmem0,size=8m,shm=fg_i3,bus=pci.0,addr=0x1f

Guest启动后，登录查看PCI设备，可以看到相应的ivshmem设备: