VMware vSphere的很多高级特性都依赖于共享存储, 如vMotion, HA: High Availability, DRS: Distributed Resource Schedule等, 它们要生效都需要虚拟机的存储位于共享存储中. vSphere支持的共享存储除了自家的vSAN, 还包括: NFS, iSCSI, 光纤通道: Fibre Channel等.

iSCSI是一个标准协议, 全称为:Internet Small Computer System Interface, 它在以太网上基于TCP/IP协议来传输SCSI协议. SCSI协议是计算机上的I/O传输协议, SCSI控制器通过SCSI总线与硬盘等设备以块为单位传输数据. iSCSI服务器称为target, 客户端称为initiator. iSCSI initiator能够以纯软件实现运行在标准网络适配器上, 也可以以硬件形式实现为专用的HBA卡:(Host Bus Adaptor), 也有带有iSCSCI offload硬件支持的网卡可以来加速iSCSI协议处理.

iSCSI协议层次如图(来自: https://www.snia.org/education/what-is-iscsi):

在VMware NSX-T网络构建中，有两个地方需要配置VLAN, 分别是:

• 逻辑交换机/分段中的VLAN, 如图:

  

• Uplink Profile中的传输VLAN(Transport VLAN), 如图:

  

逻辑交换机的VLAN决定了逻辑交换机上的端口类型，表示access或者trunk类型的端口。逻辑交换机又分为基于VLAN类型和Overlay类型两种。
对于VLAN类型的逻辑交换机, 如果配置的VLAN为单一VLAN时，表示端口为access类型。这时逻辑交换机与所连接的虚拟接口间的数据是不携带VLAN tag的，但发送到ESXi主机外部的物理网络的报文会携带有所配置的VLAN tag。VLAN 0则比较特殊，在NSX-T以及vSphere体系里都表示不携带VLAN tag。而如果配置多个VLAN后，表示端口为trunk类型。这种情况下，发送到逻辑交换机的报文则必须携带有配置范围内的VLAN tag。而该tag也会透传到外部物理网络。因而使用VLAN类型的逻辑交换机需要底层物理网络做相应的配置允许相应的VLAN通行。
而对于Overlay类型的逻辑交换机, 可以不配置VLAN, 这种情况下，逻辑交换机的端口为access类型。当设置VLAN时，即使设置的是单一VLAN，也会自动修改为trunk类型。这种情况下，逻辑交换机与虚拟接口间的报文则必须携带配置范围内的VLAN tag。

整体逻辑可以梳理为:

首先介绍NSX-T的基本概念。

参与构建NSX-T网络的节点叫做传输节点(Transport Node), 包括ESXi主机、KVM主机和EDGE节点。传输节点上需要配置构建NSX-T网络所需的NSX虚拟交换机，可以新建N-VDS类型的交换机，也可以复用vCenter上所创建的VDS, 如图：

逻辑交换机(logical switch)也叫分段(segment)为虚拟机提供网络接入点，它需要附着于NSX虚拟交换机之上。有些场景下，逻辑交换机并不需要在所有传输节点上都存在，NSX-T使用传输区域来表示传输节点的范围。NSX虚拟交换机在创建时，需要配置所关联的传输区域。

在程序中, 时间一般有两种表示方法:

• UNIX时间戳(UNIX timestamp): 表示的是从UTC时间1970年1月1日0时0分0秒起至现在的总秒数, 它也叫做epoch，UNIX时间，POSIX时间等等。在同一时刻，全球所有地方的UNIX时间戳都相同。

• 本地时间: 是以人类可读的格式表示的时间，比如2022-9-24 00:00:00。由于时区概念的存在，在同一UNIX时间戳所表示的时间点，各时区的本地时间是不同的，如下图:

CST(China Standard Time)时区中时间为2022-09-24 00:00:00的时刻，UTC时间为2022-09-23 16:00:00。

以虚拟机镜像或者自带操作系统形式交付的产品往往需要对系统进行各种各样的配置，如IP设置、DNS设置等等。为了提升用户体验，提供更简化的使用方式，往往会在console界面提供GUI/TUI的交互方式, 如XenServer的console界面:

本文介绍在CentOS7系统上增加GUI界面的方法。

Linux系统的终端输入/输出设备一般称为TTY，是TeleTypewriter的缩写, 它的历史可以参考这两篇文章:

• https://itsfoss.com/what-is-tty-in-linux/
• https://www.linusakesson.net/programming/tty/index.php

getty是管理物理或者虚拟终端(ttys)程序的通用名称，表示get tty，用于防止非授权访问系统。当getty检测到终端连接时，它获取用户输入用户名, 然后执行login程序获取用户输入密码来进行登录校验。

从终端登录的一般过程是:

• 系统内核启动完成后，会启动init进程，它是一号进程。
• init进程会在特定的tty启动getty进程获取用户名。
• 调用exec执行login程序处理登录过程
• login登录校验成功后，执行相应用户指定的shell程序

在C/S架构中，Server端需要依赖ID来唯一标识Client，而客户端相关数据都由这个唯一标识来索引。

这个标识可以由服务端分配，也可以由客户端自行生成再注册到服务端。

服务端分配是一种中心化生成方式，可以保证唯一性。客户端自行生成方式可以采用UUID标准来生成，也可以保证唯一性。

尽管在生成方式可以保证唯一性，但是由于客户端某些特性的改变，服务端依然会出现ID冲突的场景。

流量控制Traffic Control简称TC，表示网络设备接收和发送数据包的排队机制。比如，数据包的接收速率、发送速率、多个数据包的发送顺序等。

Linux实现了流量控制子系统，它包括两部分：

• 内核部分的traffic control框架
• 用户态的规则配置工具：iproute2软件包中的tc程序

它们有些类似于内核态的netfilter框架和用户态的iptables程序。但相较于netfilter, 关于tc的资料非常少，并且也较为古老，彻底理解它的机制还是需要对照源码。

Traffic Control的作用包括以下几种:

• 调整(Shaping): 通过推迟数据包发送来控制发送速率，只用于网络出方向(egress)
• 时序(Scheduling)：调度不同类型数据包发送顺序，比如在交互流量和批量下载类型数据包之间进行发送顺序的调整。只用于网络出方向(egress)
• 监督(Policing): 根据到达速率决策接收还是丢弃数据包，用于网络入方向(ingress)
• 丢弃(Dropping): 根据带宽丢弃数据包，可以用于出入两个方向

在一些业务环境的VMware Guest虚拟机上安装我们的内核模块后，偶尔虚拟机会变成无响应的状态。重启后登录系统查看，处于无响应状态的那段时间在/var/log/messages中却没有任何信息，完全没有分析问题原因的头绪。

经过调研，找到两种方法可以帮助排查定位这类系统失去响应的问题，分别是:

• 发送NMI: Non-Maskable Interupt给虚拟机
• VMware内存快照

最近CentOS7服务器上遇到一个系统崩溃:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

[92957.332974] BUG: unable to handle kernel NULL pointer dereference at 0000000000000a30
[92957.332981] IP: [<ffffffffc086077d>] nf_ct_deliver_cached_events+0x2d/0x110 [nf_conntrack]

......

[92957.333112] CPU: 1 PID: 5027 Comm: Verdict3 Kdump: loaded Tainted: G           OE  ------------ T 3.10.0-1160.el7.x86_64 #1
[92957.333114] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018
[92957.333116] task: ffff893cad135280 ti: ffff893c4f524000 task.ti: ffff893c4f524000
[92957.333118] RIP: 0010:[<ffffffffc086077d>]  [<ffffffffc086077d>] nf_ct_deliver_cached_events+0x2d/0x110 [nf_conntrack]
[92957.333125] RSP: 0018:ffff893c4f527810  EFLAGS: 00010246
[92957.333127] RAX: 0000000000000000 RBX: ffff893ca41e5140 RCX: ffffffffa035de80
[92957.333128] RDX: ffff893c4f527fd8 RSI: 0000000000000200 RDI: ffff893ca41e5140
[92957.333130] RBP: ffff893c4f527850 R08: 0000000000000000 R09: ffff893ca41e5178
[92957.333131] R10: 0000000000000001 R11: ffff893ca41e5140 R12: ffff893ca41e5140
[92957.333132] R13: ffff893c9491a500 R14: ffffffffa0367e40 R15: 0000000000000000
[92957.333135] FS:  00007fbda1d78700(0000) GS:ffff893d3fd00000(0000) knlGS:0000000000000000
[92957.333137] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[92957.333138] CR2: 0000000000000a30 CR3: 000000007fda4000 CR4: 00000000001607e0
[92957.333202] Call Trace:
[92957.333221]  [<ffffffffc08372ce>] ipv4_confirm+0x4e/0x100 [nf_conntrack_ipv4]
[92957.333227]  [<ffffffff9fc94e38>] nf_iterate+0x98/0xe0
[92957.333231]  [<ffffffff9fc96240>] nf_reinject+0x160/0x1b0
[92957.333239]  [<ffffffffc0a48566>] nfqnl_recv_verdict+0x216/0x310 [nfnetlink_queue]
[92957.333244]  [<ffffffff9f9b4716>] ? nla_parse+0xb6/0x120
[92957.333247]  [<ffffffffc09b03a2>] nfnetlink_rcv_msg+0x162/0x270 [nfnetlink]
[92957.333251]  [<ffffffffc09b0240>] ? nfnetlink_net_exit_batch+0x70/0x70 [nfnetlink]
[92957.333254]  [<ffffffff9fc9249b>] netlink_rcv_skb+0xab/0xc0
[92957.333257]  [<ffffffffc09b089f>] nfnetlink_rcv+0x28f/0x575 [nfnetlink]
[92957.333260]  [<ffffffff9fc90773>] ? __netlink_lookup+0xd3/0x130
[92957.333263]  [<ffffffff9fc91e20>] netlink_unicast+0x170/0x210
[92957.333267]  [<ffffffff9f99ca72>] ? memcpy_fromiovec+0x62/0xb0
[92957.333269]  [<ffffffff9fc921c8>] netlink_sendmsg+0x308/0x420
[92957.333272]  [<ffffffff9fc343a6>] sock_sendmsg+0xb6/0xf0
[92957.333277]  [<ffffffff9fd86c8f>] ? __schedule+0x3af/0x860
[92957.333279]  [<ffffffff9fc35269>] ___sys_sendmsg+0x3e9/0x400
[92957.333284]  [<ffffffff9f712040>] ? futex_wake+0x90/0x180
[92957.333287]  [<ffffffff9f714d2a>] ? do_futex+0x12a/0x5a0
[92957.333289]  [<ffffffff9fc36921>] __sys_sendmsg+0x51/0x90
[92957.333292]  [<ffffffff9fc36972>] SyS_sendmsg+0x12/0x20
[92957.333296]  [<ffffffff9fd93f92>] system_call_fastpath+0x25/0x2a

SSH不仅可以使用远程管理主机，还可以利用SSH客户端和SSH服务器之间的加密连接为其他服务实际中继服务，这一般称为SSH隧道(SSH Tunneling)或者SSH端口转发。

SSH端口转发分为三种类型:

• 动态端口转发
• 本地端口转发
• 远程端口转发

无论是哪种端口转发，整个过程都涉及四个角色:

• 业务客户端
• SSH客户端
• SSH服务器
• 业务服务端

这些角色进程并不要求都位于独立主机上，它们可以位于同一台主机上，使用localhost或者127.0.0.1进行网络访问。

本文基于这4种角色来简要说明这三种端口转发的过程。三种端口转发都依赖SSH客户端和SSH服务器建立一个加密连接在二者之间转发数据。