关于这个问题,主要以文字描述为主,最终解决方法其实就一个步骤。

   问题描述:

  某客户需要部署某企业的云平台,但是由于年前没有足够的物理机资源,所以提供的资源均为虚拟机,现在让我们做技术评估。

  其实观察整个环境,没有什么好做技术评估的,平时一般情况下面,除了主机我们使用物理机外,其他的所有服务都没有必要使用物理机资源,所以现在只要验证虚拟机中创建虚拟机是否可以成功即可。关于我们使用VMWare Workstation ,实现嵌套虚拟化没有一点问题,相应的配置可以参考博主这篇文章:在VMWare Workstation 9 实现嵌套虚拟化设置【虚拟机再虚拟化】

http://clovemfong.blog.51cto.com/3297559/1198184

   那么现在客户的用的是ESXI5.0,给我们使用的虚拟机自然也是从ESXI5.0主机上面划出来的,于是乎,本人就在内部进行了测试。大部分步骤都是一样的,仅仅把新建的虚拟机CPU配置支持虚拟化。

由CloudStack项目引起的ESXI嵌套虚拟化引起的二级虚拟机无法被访问_第1张图片

按照相同的步骤创建好ESXI或者KVM虚拟机,叫做也成功通过CloudStack管理节点将其进行纳管,启动Zone,最后发现两个系统VM全部启动成功,也显示Running状态,但是,问题出现了,两个系统VM只能在KVM虚拟机上面ping通,登录两个系统VM,也不能访问网关,只能访问虚拟化过的ESXI跟KVM系统。

几个系统的关系是:

物理机    --- ESXI5.0   IP: 192.168.153.6  Netmask: 255.255.255.0  Gateway: 192.168.153.1

一级虚拟机:---ESXI5.0  IP: 192.168.153.40 Netmask: 255.255.255.0  Gateway: 192.168.153.1

二级虚拟机:---linux    IP:192.168.153.107 Netmask: 255.255.255.0  Gateway: 192.168.153.1

状态:

IP为192.168.153.40跟192.168.153.6可以正常互通。

IP为192.168.153.107跟192.168.153.40可以正常互通,但是跟192.168.153.6无法互通,也无法ping通网关192.168.153.1。


问题分析:

这个问题一开始真的无从下手。

1. 防火墙的原因?

通过 VSphere Client登录VCenter 检测防火墙,发现没有作严格的防火墙策略限制。

2. 难道是因为两个二级虚拟机【两个系统VM】是由CloudStack调用接口创建的?所以才会产生这样的问题?

验证: 手动通过vsphere client 连接ESXI或者VCenter创建虚拟机,选择同样的网卡,然后配置好IP地址,结果发现结果是一样的, 所以排除了CloudStack引起的问题。

但是在本人机器上面通过VMWare Workstation创建一个虚拟机作为Agent节点,然后纳管资源,系统创建系统VM,实例,网络访问都是没有问题的。

最终定位到是ESXI跟VMWare Workstation的网络配置不同,VMWare Workstation用的是桥接模式,而ESXI上面的网络模式是没有选择的,应该默认也是桥接模式,也排除了网卡连接模式的问题,那最后定位到ESXI跟VMWare Workstation网卡配置的其他不同上面,最终点击ESXI主机网卡VM Network的编辑按钮,点击安全标签,发现有几个策略异常选项:

混杂模式

MAC地址更改

伪传

本人对网络不是非常精通,于是搜索了下”混杂模式“的含义,度娘说:是指一台机器能够接收所有经过它的数据流,而不论其目的地址是否是他。

看解释好像有点像哦,如果默认设置为拒绝的话,那么也就是:是指一台机器不能够接收所有经过它的数据流,而不论其目的地址是否是他。把这个混杂模式设置为接受?

由CloudStack项目引起的ESXI嵌套虚拟化引起的二级虚拟机无法被访问_第2张图片

然后再次登录两个系统VM,Ping网关,ping物理主机,OK了!通过其他子网里面其他IP地址的系统Ping这两台系统VM,都成功了!

至此,问题解决!