In a lab you can use a single physical network and also a single logical network... no big problem.
But in a real environment it's a better choice to have different networks:
VMotion traffic is not encrypted and burstiness -> so is better to isolate it
iSCSI traffic is not encrypted, could be high, and is better that has low latency -> so is better to isolate it
NFS traffic is not encrypted, could be high, and is better that has low latency -> so is better to isolate it
Thanks Andre!
We don't use iSCIS and NFS in our production environment.
In fact the guys from network team told us it is hard to configure them in different VLANs. If so the communications to servers will experience outrage.
So if it OK to configure them in the same network and any other influence?
If there is any solution for such situation?
So if it OK to configure them in the same network and any other influence?
It works
If there is any solution for such situation?
There are a lot of solutions... but all depends on how many NIC do you have and if you want/can use VLANs.
But always consider availability of network... that means at least 2 NIC for each vSwitches...
With few NIC have COS and VMotion on the same vSwitch is a reasonable choice.
Do you mean 'vMotion' instead of 'vmkernel'? Remember the vmkernel networks are used for iSCSI, NFS, vMotion, and within ESXi, vmkernel also implies the management console.
So which network are we actually discussing? Let's assume this is vMotion as you mentioned you do not use iSCSI or NFS and we are talking about ESXi.
I would give my Blue Gears -- Networking posts a read, specifically this one on Combining Networks. The key things to consider are redundancy, performance, and security. It is also to realize that VLANs are a TRUST issue and not a physical 'security protocol'.
Combining Service COnsole and vMotion on the same pair of pNICS is fine depending on whether you have to adhere to PCI or other regulations, then it really is not a great thing to do. However, for general usage it is accepted and you either have to use VLANs, or subnets. Your vMotion IP address cannot be within the same subnet as your service console. This is enforced by ESX itself.
For us, everyone that has access to the SC networks also has full administrative access to every VM running on the relevant hosts, so there's no value in protecting the VMkernel differently than the SC.
"Your vMotion IP address cannot be within the same subnet as your service console. This is enforced by ESX itself."
Are you sure? We have used vMotion and Service Console in the same subnet for several months without problems.
-Asko-