Port Group Issue

[pravin2650]

I am not really sure if it is port group issue or something..

I have a vSwitch on my ESX ,

i have created a normal Virtual Machine Port group on it.. and other Port group is Server Console Port on same switch. (This is not the real Service Console Port i.e. the actual Service console Port is placed separately on other vSwitch to access from outside world).

I have placed VM Port group and Service Port on same vSwitch because I want my virtual machine (guest) to talk with ESX but keep it out of reach from outside world.. i.e. tried to create a internal vSwitch that will keep the traffic limited to VMkernels TCP/IP stack. and will not send traffic outside for security reasons as well my Guest and ESX are on different subnets.

I connected one vNic/interface of my guest to this vSwicth during configuration.. and also entered IP to the new Service Console (on that vSwitch) similar in the range that of my Guest OS is,.. Problem is that i am not able to ping between ESX and my Guest and vice versa on same vSwicth.. though TCPdump shows me correct ARP packets on both the ends.

First i thought that it must me due to no assignment of pNIC to the vSwicth.. but it is showing same behaviour after I connect pNIc to the vSwicth.

Can anyone please help me out.. Please let me know if anymore information is needed..

[Yattong]

I have placed VM Port group and Service Port on same vSwitch because I want my virtual machine (guest) to talk with ESX but keep it out of reach from outside world.. i.e. tried to create a internal vSwitch that will keep the traffic limited to VMkernels TCP/IP stack. and will not send traffic outside for security reasons as well my Guest and ESX are on different subnets.

To keep IP traffic internally, you do not need to have a Service Console portgroup on the same vSwitch. All you have to do is create a vSwitch without a physical nic attached.

This is called 'an internal only vSwitch'

I connected one vNic/interface of my guest to this vSwicth during configuration.. and also entered IP to the new Service Console (on that vSwitch) similar in the range that of my Guest OS is,.. Problem is that i am not able to ping between ESX and my Guest and vice versa on same vSwicth.. though TCPdump shows me correct ARP packets on both the ends.

Are they on different subnets? are the default gateways setup properly?

From my first comment, you should be able to set up an internal only network.

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

~y

[pravin2650]

Thnx Yattong for the reply.. But would your suggestion for creating Internal Swicth solve my problem.. i.e. will my Guest machine be able to talk with ESX?

The ultimate goal I want to achieve is that my Guest machine (on ESX server) should be able to communicate with the ESX server, One possible way is to communicate via external way i.e. i will assign my Guest vSwicth to pNIC that will take the traffic to ESX server, But this will add security risk as my traffic will be on network and also my geust machine needs to be in same network as ESX server (i want to keep mgmt network different from production network).

So i was thinking of a way to communicate with ESX internally.. hope so you got the prob..

Please let me know..

Pravin

[Yattong]

Why do the VM's need to talk to ESX?

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

~y

[Texiwill]

Hello,

The service console and any VMs that talk to it should be on a private management network that is properly firewalled, etc. If you need a VM to speak to the SC such as vCenter Server, then it should also be on the management network. Either by adding a new portgroup to the vSwitch that hosts your REAL service console or some other networking mechanism.

Having something like vCenter in your 'production network' and SC in a management network is not a great idea IMHO as it is really a management tool more than a production tool like AD, etc.

But still as Yattong is asking what is the need to talk to the SC?

Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
Blue Gears and SearchVMware Pro Blogs -- Top Virtualization Security Links -- Virtualization Security Round Table Podcast

[pravin2650]

Hi Yattong,Texiwill,

Actually my application on Guest OS (VM) needs to detect the status of pNIC, and there is no way I can do that on Guest OS programatically or by any means as it is limited to the virtual adapter provided by VMware Kernel to my application/OS.

Please see my previous discussion for it..

http://communities.vmware.com/message/1166877#1166877

so i thought of getting an workaround like executing a script from my OS that will be able to communicate with ESX and give expected result (output of esxcfg-nics -l command) but i wanted to keep this traffic limited to TCP/IP stack in VMKernel so thought of a way doing it using internel vSwitch.. hence this discussion thread..

Please let me know your concerns!

Pravin

[Texiwill]

Hello,

What you propose would be a major security issue to implement. I.e. Seriously not recommended. But if you must then use the RCLI within the VM to talk to the ESX host on the administrative network AND NOT on any other network. In effect your VM now becomes an ESX Management tool and must live on the appropriate network and not cross security zones, etc.

Again, I read through the other post and you may wish to keep this there, but why do you need to know if the pNIC is up since all traffic, regardless of its origin comes through the vNIC to the VM. If you instead wish to sniff the pNIC traffic only this approach will not work.

There is no driver within the VM that you can implement to get the data you want (again it is a security issue). But there are tools (such as the RCLI) to gain this information.

Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
Blue Gears and SearchVMware Pro Blogs -- Top Virtualization Security Links -- Virtualization Security Round Table Podcast

[pravin2650]

Thanks Edward, for the information..