Why is the virtual machine network connection on a nested VMware VSPHERE/ESXI installed on the default configuration fail?

VMware Vsphere/esxi allows for nested installations. The so-called nested installation, as shown, installs the Vsphere/esxi virtualization software in the Vsphere/esxi virtual machine. Virtual machines can also be deployed on such nested VSPHERE/ESXI virtual machines, but in the default configuration, these virtual machine network connections fail. This article will introduce the mechanism and the solution.

650) this.width=650; "Src=" http://img.blog.csdn.net/20141120233849375?watermark/2/text/ ahr0cdovl2jsb2cuy3nkbi5uzxqvd2lsbglzx3jlbg==/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/gravity/ Center "alt=" nested Vsphere/esxi "align=" Middle "title=" click the image to open "style=" line-height:normal;border:none in a new window; "/>

so, in the default configuration, why are the virtual machines on these nested vsphere/esxi not networking? This is done from the working principle of the VSPHERE/ESXI virtual network switch. The Virtual Switch Although it is called a switch but there are some differences in how it works with physical switches, We know that one of the main functions of a real physical switch is to maintain a map of the network physical address mac and switch ports so that when a message goes into the switch port, it can be delivered to the switch port where the physical address of the destination network is located without broadcasting. So how did this magical map form? That's because the switch has the intelligence to learn features. However, the VSPHERE/ESXI virtual Switch does not have this learning mechanism, because it does not need such a technology to establish such a map table, because the virtual machine's network adapter and the virtual exchange of the port directly connected to the software implementation without simulating the real tedious learning process and directly formed.

if we thoroughly understand why Vsphere/esxi's virtual does not require the learning process of mapping tables, Then we comprehend by analogy easily understand why nested VSPHERE/ESXI virtual machine networks are different. Because the virtual switch on the lower-level vsphere/esxi has only a mapping table for the virtual machine that is directly connected to it, such as the physical address mapping of the nested VSPHERE/ESXI uplink in this example, without the Physical Address mapping table for all other virtual machines on the nested VSPHERE/ESXI , their mapping tables exist in a virtual switch with nested Vsphere/esxi, and these two-tier switches do not exchange information through the uplink between them, because they are different from physical switches to learn from each other.

So how do we solve the limitations of this design mechanism? Fortunately, the Vsphere/esxi security policy on the virtual switch provides a "promiscuous mode" feature. Have to admire the ingenuity of VMware Design, a feature that plays a different role in this application scenario. The promiscuous mode port works by means that all data packets flowing through the virtual switch are copied for transmission on such a port. Based on this principle, the ports connected to all nested VSPHERE/ESXI are configured as "promiscuous mode" on the underlying VSPHERE/ESX virtual switch so that the messages in the underlying virtual switch are sent to a copy of the network port of the nested Vsphere/esxi. The virtual switch is further transmitted to the nested VSPHERE/ESXI, and the virtual Switch maintains all the physical address mapping tables for the virtual machines on the nested Vsphere/esxi. Therefore, it realizes the network communication between the virtual machine on the nested VSPHERE/ESXI and the outside world through this technique.

This article is from the "Technology is Life" blog, make sure to keep this source http://itaal.blog.51cto.com/5004122/1581099

Why is the virtual machine network connection on a nested VMware VSPHERE/ESXI installed on the default configuration fail?