Vmotion, eterchannel and VLAN

[Sangokan]

Hi,

If i'd configure a vmotion switch with two NICS and make an eterchannel with those two nics on the physical switches, would that give vmotion twice available bandwidth or not?

Is it abest practice to create a dedicated VLAN for esx hosts?

Thanks in advance.

[Texiwill]

Hello,

Etherchannel or 802.3ad is supported by ESX but only the failover modes, not the bandwidth aggregation. Since NIC Teaming Load balancing within the vSwitch is based on the source mac/ip/port number and vMotion only uses one source mac/ip/port number vMotion can only use the failover modes of NIC Teaming. You get no benefit from having two live (load balanced) network interfaces for vMotion. You only can setup failover.

It is strongly recommended that vMotion have its own VLAN and be protected using physical security.

Best regards,

Edward

[Sangokan]

Hello,

Well too bad there is no bandwidth aggregation, thanks anyway for the clarification.

Now i am creating a new vlan on my Cisco Stack, i run most of my VMs on vswitch in a 10.1.x.x/16 network (VLAN 1) so do i for the service console and vmotion. As you are advising, the new VLAN i am creating will be a 10.5.x.x/16 network and will be dedicated to vmotion (i have already configured the routing between the two subnets), any considerations i should take into account?

Should i also place the service console ports on a different VLAN (or the same as the VMotion ones maybe)?

[uber_ms]

Why are you routing between VLAN1 and your VMotion VLAN?

BP states you should have an isolated Service console VLAN, as well as a VMotion VLAN with a redundant Service Console Port.

[etieseler]

You should be safe using the same physical ports for the Service Console and VMotion, however I would recommend keeping them on separate VLANs. It is best practice to keep these two separated from each other, as well as separated from your VM's network(s). For example, 2 ports in an etherchannel for your VM's production network, and 2 ports in another etherchannel with 2 VLAN's, 1 for Service Console, the other for VMotion.

-Ed

[Sangokan]

Ok there is no need for routing so better not enable it you are right.

THe reason why i'd like to keep vmotion and service console on a same VLAN is because i dont have so much nics on the hosts that i can use redundancy on three different vlans. If i do so i'll need 2 nics for vmotion 2 nics for service console and two nics VMS. I have only 5 ports so...

NOw if i have two service console ports on two different VLANs ( one dedicated and one shared with vmotion ) i wonder what amount and type of traffic is going through the service console port.

Can someone also explain what is the benefit of etherchannel with vmware (i thought it was bandwidth aggregation but obviously it is not)?

Thanks

[etieseler]

Etherchannel is good because of the redundancy it provides. If you have only 1 NIC assigned to the service console and it fails somehow then the cluster will consider the ESX server as down and the default host isolation policy will be to shutdown all the VM's on this ESX server. Likewise if you have only 1 port for VMotion and it fails you will loose this capability.

You can mix the vmotion and the service console ports, just seperate them in different VLANs. In otherwords, in your etherchannel enable trunking so you can have multiple VLANs using the same physical ports. This provides isolation for the VLANs but does not waste physical ports. Then use the remaining for your production networks.

In the Cisco world use trunking and dot1q encapsulation. Search their website for instructions to set it up. I'd give you a link but I don't know what hardware you have.

[smithg001]

Why are you routing between VLAN1 and your VMotion VLAN?

BP states you should have an isolated Service console VLAN, as well as a VMotion VLAN with a redundant Service Console Port.

I seem to catch a lot of people by surprise with this, but your VMkernel vLan can not be completely isolated if you plan to use iSCSI. At this point both the service console and VMkernel have to be able to reach an iSCSI target unless you are using a hardware iSCSI HBA. This is one reason why an isolated VMkernel network doesn't work in all cases.

When I brought this up during the TA57 breakout session at VMworld, I got a dumbfounded look from the presenters... and then a uh... you are right. Once they fix the iSCSI portion, yes a provate vLan is best.

-

---

Gregory Smith

greg@virtualsmith.net

www.virtualsmith.net

[depping]

Wouldn't adding a Service Console Portgroup to the ISCSI vSwitch provide you with an isolated network?

Duncan