最近在项目中，有不少客户都在咨询VMware NSX DC Guest Introspection及其衍生功能的内容。所以今天，我们换个口味，从NSX-T的内容连载回到NSX-V的介绍，来谈谈NSX DC的GI功能原理。
其实，在众多虚拟化项目中，用户通常会采用部署“无代理防病毒”解决方案来保障虚拟机的操作系统安全，无代理防病毒是NSX DC产品GI功能与第三方防病毒软件共同实现的。
如下图所示，在我的演示环境中，部署了VMware NSX DC，并启用了GI功能：
这里有一个特别需要需要注意的地方：
想要实现基于GI的无代理防病毒，必须要求有NSX DC环境，但是不需要任何的许可授权；换言之，在完成NSX DC Manager安装后，默认就可以与第三方防病毒解决方案集成。
这里要特别感谢好友，来自安渡神州的任伟，提供了测试许可，支持我完成整个测试环境的搭建工作。
以卡巴斯基无代理防病毒解决方案为例，我在一个群集，共计两台ESXi主机上激活了无代理防病毒。
===================演示分割线====================
举个简单的例子，如果虚拟桌面用户在浏览网站或者使用U盘拷贝单项拷贝数据过程中，下载或者上传了一个病毒文件到虚拟桌面操作系统；如下图中我尝试从Internet下载一个被人添加了恶意代码的Word文档。
那么，虽然用户可能尝试将文件保存到虚拟桌面的“桌面”文件夹，但结果是该文件并没有被保存，而是被无代理防病毒直接查杀了。
这就是用户在部署了基于NSX DC的GI后，与安全厂商防病毒产品结合，保护虚拟化环境操作系统安全的用例；那么从技术角度来看，NSX DC GI和无代理防病毒如何实现对操作系统的安全防护的呢？
首先：
在Guest Introspection架构中，没有任何需要vsfw或者netcpa参与的交互，因此不需要对集群内的ESXi主机进行“主机准备”，不需要安装ESX-NSX.vib（这解释了为什么GI不需要NSX DC任何授权的原因），并且与Network Introspection架构相类似，没有任何控制层面的组件；如下图所示：
其次：
NSX Manager包含Guest Introspection虚拟机的OVF文件和EPSEC-MUX-VIB软件包；
NSX Manager通过vCenter的EAM（ESXi Agent Manager），以群集为单位，在ESXi的内核空间安装EPSEC-MUX-VIB（这解释了为什么一定要部署NSX DC Manager），该操作会自动在每一台ESXi主机上生成一个没有任何VMNIC上联链路的标准交换机，该标准交换机有一个IP地址为169.254.1.1的vmkernel端口；同时在ESXi的用户空间部署一台Guest Introspection虚拟机，该虚拟机拥有两个vNIC，其中一个vNIC连接到标准交换机的VMNetwork端口组，并分配一个内部IP，169.254.1.24，另一个vNIC一般连接
到上联管理网络的虚拟交换机，分配一个三层可达的IP，与NSX Manager通信。
同样地：
第三方杀毒软件Anti-Virus Deep Security管理器内含Anti-Virus虚拟机的OVF（一般更多的是利用HTTPS提供vCenter进行下载）；
第三方杀毒软件Anti-Virus Deep Security管理器注册在vCenter上，通过vCenter的EAM，以群集为单位，在每一台ESXi主机的用户空间部署一台Anti-Virus虚拟机，该虚拟机同样拥有两个vNIC，其中一个vNIC连接到标准交换机的VMNetwork端口组，并分配一个内部IP，如卡巴斯基的169.254.1.60，另一个vNIC一般连接到上联管理网络的虚拟交换机，分配一个三层可达的IP，与Anti-Virus Deep Securiy管理器通信。
我们再来回头看整个架构图：
可以看到GI本质上是通过VMTools中的VMCI Driver下的GI Driver实现。因此，Guest Introspection和Anti-Virus解决方案要求受保护的虚拟机必须“完整安装 VMTools”。
整个无代理防病毒实现的路程如下：
1.Anti-Virus Deep Security管理器通过管理网络，将病毒库等数据信息下载到每一台Anti-Virus虚拟机
2.GI Driver收集受保护的虚拟机文件活动，并且通过VMCI传输给169.254.1.1
3.Guest Introspection虚拟机内部有个LIB库，通过该LIB库从169.254.1.1获取受保护的虚拟机文件活动信息
4.如果NSX Manager开启了用户收集文件活动功能，Guest Introspection虚拟机将通过管理网络将这些信息报告给NSX Manager
5.同时，Anti-Virus虚拟机内部也有个LIB库，该LIB库与Guest Introspection虚拟机的LIB库处于相同的169.254.1.0/24子网，可以相互通信，Guest Introspection虚拟机将收集到的文件活动信息报告给Anti-Virus虚拟机
6.Anti-Virus虚拟机有病毒库等信息，会将Guest Introspection报告的用户文件活动与病毒库特征匹配
当GI报告的用户文件活动与病毒库特征匹配，那么无代理防病毒引擎会执行查杀操作，我曾请教过好友任伟，验证了我对查杀流的猜想：
1.Anti-Virus虚拟机通过LIB库与169.254.1.1通信，下达查杀操作指令
2.169.254.1.1通过VMCI与受保护虚拟机的GIDriver通信
3.虚拟机的GIDriver进行查杀操作
在对整个GI与安全软件结合实现“无代理防病毒”进行了详细解析后，我们可以归纳出部署无代理防病毒的几个要点：
1.必须安装NSX DC Manager，但是不需要执行主机准备，因此不需要任何授权
2.必须安装vCenter，作为虚拟化平台统一的管理平面控制台（其中NSX-V Manager必须与VC1:1集成）
3.受保护的虚拟机必须“完整安装”VMware Tools
4.基于GI的无代理防病毒与NSX DC的分布式防火墙无关，且不需要受保护的虚拟机连接到网络中，是一种针对文件活动的安全防护
上述讨论都是针对NSX DC产品中的NSX-V的，现在华讯的不少用户都已经部署NSX-T作为网络与安全解决方案，那么在NSX-T架构中，GI的架构是否得到了沿用呢？我们来看一下下面两张图：
首先是NSX-V的架构图：
其次是NSX-T的架构图：
通过上面两张图的对比，我们至少可以得出以下几个结论：
1.NSX-T同样支持基于GI，与安全产品集成实现无代理防病毒
2.NSX-T虽然支持包括KVM在内的异构化Hypervisor，但是GI目前只能在vSphere环境中应用
3.NSX-T架构中的GIVM不再是一台虚拟机，而是ESXi内的一个进程，但是原理上并没有太大的变化
NSX DC的Guest Introspection解析基本到这里了，下一篇还是继续我们的NSX-T连载。
