又一个WordPress站点
Community NVMe Driver for ESXi | VMware Flings 最近更新，支持到了ESXi 7.0，支持了三款NVMe设备：
| Vendor | VendorID | ProductID |
| ADATA | 0x1cc1 | 8201 |
| Micro/Crucial | 0xc0a9 | 0x2263 |
| Silicon Motion | 0x126f | 0x2262 |
也就是说能匹配以上vid，pid的NVMe设备就可以通过此驱动在ESXi上识别并使用。（在6.7U2更新时，由于ESXi遵照了NVMe 1.3 规范去识别和支持设备，某些消费级别的NVMe因为不支持该规范而无法被ESXi识别并使用，虽说也有用ESXi6.5的某些文件进行替换的变通办法，但还是很麻烦。）
可以下载此驱动，封装到ESXi安装镜像，也可以在已安装好的ESXi系统中离线安装此驱动。
esxcli software vib install -d /xxxxxx/nvme-community-driver_1.0.1.0-2vmw.700.1.0.15843807-component-18290856.zip
USB Network Native Driver for ESXi 更新到1.8版本，增加了ESXi 7.0 Update2的支持。
从changelog来看，这次更新还修复了使用多个USB网卡时的PSOD紫屏问题。
最近flings.vmware.com上，社区版的ESXi网卡驱动再次更新。
https://flings.vmware.com/community-networking-driver-for-esxi#summary
从changelog看，最近两次更新内容如下：
May 19, 2021 – v1.2
Net-Community-Driver_1.2.0.0-1vmw.700.1.0.15843807_18028830.zip
md5: fc3b23201d78d3b0d75c8a4fcad759f3
What’s New:
Support for Jumbo Frames (MTU up to 9000)
Support for Wake-on-LAN (WOL) for Intel i225 NIC
April 08, 2021 – v1.1
Net-Community-Driver_1.1.0.0-1vmw.700.1.0.15843807_17858744.zip
md5: 587d7d408184c90f6baf4204bb309171
What’s New:
Resolve issue when using Intel vPro which can cause ESXi PSOD
最近 VMware的flings网站里新增加了Community Networking Driver for ESXi | VMware Flings.
此驱动旨在对一些官方安装包里不支持的网卡提供一个相对稳定的网卡驱动,可以通过封装到安装镜像或者在现有的ESXi主机上安装来使用.
从requirements一页中可以看到此驱动支持了哪些网卡.
看了下NUC8和NUC11 Pro and Performance的网卡都属于这个驱动可以支持的.
PS: 此前也有一个类似的社区版网卡驱动,之前已经集成到了ESXi7.0.1里.
前些天从公司采购了M1芯片的Macbook Pro，到手后发现系统初始化设置时被设置了Remote Management，等于系统镜像被出厂时预设成公司的企业设备管理了。而我是用来做开发测试用的，被Remote Management不方便，需要移除该管理。
咨询公司IT后，他们先把我的设备序列号从Apple Business Manager中移除掉。
如图
此时，如果通过长按电源键进入Recovery后重新安装Big Sur，安装完毕重启初始化时，还会出现Remote Management。
从苹果官方找到如下文档，在另一台mac电脑上利用Apple Configurator 2，通过Type-c将该电脑与需要修复的电脑连接，需要修复的电脑这边需要将Type-c插入离屏幕近的这个口。https://support.apple.com/zh-cn/guide/apple-configurator-2/apdd5f3c75ad/mac
然后打开Apple Configurator 2， 需要修复的电脑保持关机。然后同时按下电源，左Option，左Ctrl，右Shift，保持10秒，松开三个按键继续按住电源键7秒。松开电源键。然后稍等几秒，Apple Configurator 2里，该需要修复的电脑就进入DFU模式了，此时选择设备，右键，高级，修复。漫长的等待之后，就修复完了。重启，我用电脑创建了一个Big Sur最新版的启动U盘，长按电源键进入启动选项，选择启动U盘，安装Big Sur。完成重启后，Remote Management就不见了。
本周VMware发布了ESXi 7.0 Update 1c更新,查看Release notes,发现有一段比较有意思.
With ESXi 7.0 Update 1c, you can use the installer boot option systemMediaSize to limit the size of system storage partitions on the boot media. If your system has a small footprint that does not require the maximum 138 GB system-storage size, you can limit it to the minimum of 33 GB. The systemMediaSize parameter accepts the following values:
The selected value must fit the purpose of your system. For example, a system with 1TB of memory must use the minimum of 69 GB for system storage. To set the boot option at install time, for example systemMediaSize=small, refer to Enter Boot Options to Start an Installation or Upgrade Script. For more information, see VMware knowledge base article 81166.
对于这个启动选项,我的理解是之前ESXi 7.0默认最大会占用138GB左右硬盘,就是上文中提到的default(其中包括BOOTBANK1, BOOTBANK2, 还有OSDATA, 当硬盘为HDD时,OSDATA不会被当作虚拟闪存使用,此时OSDATA类型为VMFS-L. 当硬盘为SSD时,OSDATA会被同时当作虚拟闪存,此时OSDATA类型为VFFS.) 之前写过我们可以通过设置autoPartitionOSDataSize来调整OSDATA的大小. https://virtualtips.info/?p=42 ,但该方法并非官方提供的解决方案.
此次systemMediaSize参数可以理解官方为此提供了几种预设值(min, small, default, max). 我们可以在安装启动前Shift+O来加上参数systemMediaSize=min,或者在安装介质的boot.cfg文件中的kernelopt=runweasel这行后面加上诸如systemMediaSize=min的参数,让此安装程序自动设置参数.
kernelopt=runweasel systemMediaSize=min
此时,安装好以后的硬盘空间大致情况如下图,系统空间占用大概是33GB.
还是不支持更新，只能全新安装选择保留VMFS，然后重新注册虚拟机。我暂时先不更新了，changelog如下：
November 30, 2020 – v1.2
Note: Upgrade is NOT possible, only fresh installation is supported. If you select “Preserve VMFS” option, you can re-register your existing Virtual Machines.
UI: Disable datastore browsing when no datastores are present
PSCI: Fix missing context_id argument for CPU_ON calls
GICv2: Always enable SGIs, as GIC-500
arm64: Support for big-endian guests
Remove requirements/restrictions on initrd for UEFI-less VMs
苹果发布M1芯片的新Mac设备以后，许多用户想要PD或者Fusion运行在Apple Silicon上，并虚拟x86 windows（准确说是模拟）。
从PD的博客看到https://www.parallels.com/blogs/parallels-desktop-apple-silicon-mac/，模拟x86 windows并未在计划中。其中提到了在虚拟的windows on Arm中利用微软的支持来模拟运行x86 windows程序 https://blogs.windows.com/windowsexperience/2020/09/30/now-more-essential-than-ever-the-role-of-the-windows-pc-has-changed/
所以模拟x86 windows OS并未在PD的计划中，同理去模拟其它AMD64 Linux或者x86 macOS也不在计划。
而Fusion并未在博客或者官网中提到类似计划，只在官方twitter和论坛中有所提及会去支持Apple Silicon。
对此，我谨慎做些猜测：
欢迎PD和Fusion来打脸。
在传统的x86服务器上，ESXi可以监控该服务器的cpu温度，如图：
我们平时玩树莓派时，是可以获取到cpu温度，并且可以通过程序来联动启停风扇的。（网络上教程很多）
当ESXi on Arm安装在树莓派4b以后,默认肯定是获取不到这个温度的。
前几天一位网友在https://github.com/thebel1/thpimon中提供了thpimon-0.1.0-1OEM.701.1.0.40650718.aarch64.vib 这一驱动，在ESXi on Arm上安装这一vib驱动以后，就可以通过python脚本来获取相应数据了。具体步骤在上述项目的说明中已经包含了。这里就不演示步骤了。看下python脚本的显示结果：
这里虽然解决了数据的采集问题，但是还不能形成时间序列数据，那么就需要接着改造python脚本来实现，恰好有另一个https://github.com/fgrehl/esxi-raspi，在前者基础上实现了时间序列数据的生成。
设定interval抓取：
运行结果：
仅仅是在Console里打印时间序列数据，显然达不到“监控”级别，于是又加入了将数据发送至Graphite主机的CARBON端口，这样就可以在Graphite前端来图形化显示时间序列数据了。
设定发送主机：
因为涉及到从ESXi向外（CARBON）发送数据，可以尝试关闭防火墙：esxcli network firewall set –enabled false，在重要环境中，请单独为此行为设定防火墙规则，不要整体关掉。
看下运行时Console的显示：
Graphite主机的搭建不详细说明了，可以参照https://graphite.readthedocs.io/en/latest/install.html通过Docker安装并运行，我就是在一台虚拟机Photon OS中运行的此Docker，这里顺便安利下Photon OS，很适合玩Docker。
访问Graphite webui:
可以从树形结构的Metrics下找到我们发送过来的数据。
双击cputemp即可在右侧显示图形，并可自定义图形的一些属性。
除此之外，我们还可以在Dashboard中添加该指标，如果有多台机器或者多项指标，就可以定义出我们自己想要的Dashboard：
保存后，该访问地址http://192.168.1.235/dashboard/ESXi-pi2%20cputemp%20Dashboard可以之后随时访问查看。
从图中看，这段时间该ESXi on Arm所运行的树莓派4b的cpu温度基本在46-48.5度之间。
在之前的 vSphere虚拟网络01中，提到了vSphere中的两种虚拟交换机类型：标准交换机和分布式交换机。这篇里就虚拟交换机的知识进行一些深入的了解。
首先，虚拟交换机就是从软件层面来模拟一个Layer2的交换机。在物理网络中，交换机在Layer2利用它维护的CAM表来做点到点的数据包传输。在虚拟网络中，虚拟交换机检测到连接到它的虚拟端口的虚拟机，然后用MAC来转发流量到正确的目的地（点到点）。虚拟交换机基本上是用来在虚拟网络和物理网络之间建立连接的。
这里可以再看一下上一篇中用到的示意图
在ESXi安装之后，默认的配置有一个标准虚拟交换机，一个叫VM Network的端口组和一个作为ESXi管理口的叫vmk0的VMkernel port。这个默认配置可以用来实现基本的虚拟网络和物理网络的连通，如果你有更复杂的虚拟网络需求，我们就要自己来创建额外的VMkernel port，端口组或者虚拟交换机。
那么我们来查看下vSphere7版本的虚拟网络的一些限制https://configmax.vmware.com/guest?vmwareproduct=vSphere&release=vSphere%207.0&categories=2-0
从中我们能看到，ESXi主机支持最多4096个端口，其中8个作为预留口，但是最多活动端口是1024，其中8个作为预留口，那么最多可用并且活动端口就是1016。
在之前的vSphere虚拟网络01中提到了虚拟网络中的隔离，可以通过一个虚拟交换机的不同端口组设置不同VLAN ID来隔离，如下图
那么也可以通过多个虚拟交换机来直接做“物理隔离”，如下图
两种方式都可以做到隔离，但有什么不同呢？
首先，虚拟交换机是通过软件来模拟物理交换机的行为。那么在ESXi上创建越多的虚拟交换机就应该需要越多的资源来做交换功能。
其次，如果我们想做流量隔离，在单虚拟交换机上就需要配置VLAN，或者不用VLAN，用多虚拟交换机来“物理隔离”。因为在很多网络中，可能物理网络中也没有配置VLAN来做隔离，比如部门1连接物理交换机01，部门2连接物理交换机02，这样的物理隔离，那么我们就可以把部门1要用的虚拟资源连在虚拟交换机01上并且通过上行链路->物理网卡连接到物理交换机01上，然后部门2要用的虚拟资源连在虚拟交换机02上并且通过上行链路->物理网卡连接到物理交换机02上，这样部门1和部门2所需要的虚拟资源就“物理隔离”了，同时，Management和vMotion连接不同的物理交换机也可以实现管理和迁移的“物理隔离”。从整体上来说，我们也做到了业务部门的流量（部门1和部门2）和IT管理的流量（Management和vMotion)隔离。
最后我们看到图中每个虚拟交换机我们都设置了2个上行链路（冗余），这样单虚拟交换机需要2个物理网卡，4个虚拟交换机就需要8个物理网卡，这时候我们就要考量这台服务器是否有能力通过PCI插槽来接入这么多网卡了，因为PCI插槽还可能有连接阵列卡等设备的需求。
Tips:
不要因为你能创建多个虚拟交换机就去创建，要根据实际需求和硬件设备来具体分析，建议通过尽量少的虚拟交换机来实现需求。
标准交换机是通过ESXi主机来创建和管理的，这就意味着当你有多台ESXi主机时，你就要分别去每一台ESXi上创建标准交换机里的端口组等设置，可能这个工作量还不算什么，但是当一年之后你要去修改端口组，或者扩展端口组呢？（这种需求应该可以叫做Day2 operation吧)。
因为标准交换机不能集中管理，也许我们可以通过一些自动化脚本来实现，但自动化脚本也要适应上面提到的Day2 operation， 所以管理员的开销还是挺大的。
通过创建或者编辑标准交换机的操作界面，我们大致能了解到一些它的功能：
Layer2交换
IPv6
VLAN
网卡绑定
出口流量整形
安全策略
绑定和故障切换策略
总的来说，标准交换机可以解决大部分小型部署中的虚拟网络需求，我们应该避免在中型或大型部署中使用标准交换机，或者可以保留的使用有限的功能。更多的虚拟网络需求通过分布式交换机或者NSX来实现。
分布式交换机在标准交换机的基础上，增加了一些额外的功能，而且提供了集中管理的接口。
比如：
入口流量整形
网卡绑定和故障切换策略中基于负载的绑定
端口洪泛控制
私有VLANs
以端口为单位的策略设置
端口镜像
NetFlow监控
端口状态监控
如图是个基于2台ESXi主机设置的分布式交换机示意图
所谓的集中管理，分布式交换机不是在ESXi主机上创建的，而是vCenter。在vCenter中在数据中心的Actions菜单中可以选择分布式交换机，然后创建或者导入。分布式交换机上的流量并不会通过vCenter来转发，来看一个分布式交换机的架构图。
从图中我们可以看到，vCenter上是分布式交换机的一个模板，设定了端口组，上行链路的个数。需要把ESXi主机加入分布式交换机，这时候就把交换机的模板推送到了加入的ESXi主机上，并且可以指定ESXi上的哪个物理网卡为分布式交换机的上行链路使用。ESXi主机上有一个Host proxy switch，它用来接收vCenter推送的模板，这样交换功能其实还是在ESXi主机上实现的。Day2 operation需要的设置可以在vCenter的模板上修改，就会推送到各个连接该分布式交换机的ESXi主机上，这就是集中管理。
这种架构，在vCenter上的分布式交换机实例被叫做控制平面/Control plane，交换机的管理是在这里实现的。在ESXi上的Host proxy switch被叫做数据平面/Data plane,交换机的数据交换是在这里发生的。
最后，来看一个多台ESXi所连接的分布式交换机的拓扑图吧。
左侧为端口组，我把vCenter自己单独放了一个端口组，把VMkernel放在一个端口组，剩余VM放在一个端口组。因为没有设置VLAN，实际上这几个端口组是可以互通的。
右侧为上行链路，这里我每个ESXi主机只设置了一个上行链路，对应一个ESXi上的vmnic。
如果win10这台虚拟机在esxi01这台主机上，u2004这台虚拟机在esxi02这台主机上，两台同在一个端口组的虚拟机，从拓扑图看来，直接在虚拟交换机就能交换数据，实际上，还是要通过各自的上行链路走到物理交换机才能交换数据的。