Vmotion networking question

[cef2lion]

We have 4 ESX servers with 4 NICs per server. On each ESX server I have one NIC for the service console. One NIC for the the virtual machines. One NIC for Vmotion. All interfaces are running on the same VLAN. Wanting to go back now and clean things up a bit. From what I recall it is best to have Vmotion running on its own vlan? Correct? Can I just create a Vmotion vlan on our router and change the Vmotion interface on each ESX server to a private non routed IP. Assume this helps in flooding the other vlans that Vmotion is currenting running on.

[vmroyale]

You definitely want VMotion segmented either physically or with VLANs. Check this site for some good information about security and VLANs.

There is also some great info in this discussion.

[cef2lion]

Good info. Thanks. Some of those links show the service console and vmotion riding a pair of gig NICs. I was going to run my console on one NIC and Vmotion on another. Maybe this solution would be better. Pair some NICs and VLAN in the service console and Vmotion allowing a bigger pipe for Vmotion. Does the service console need much bandwidth? We have a physical VC. It only has one NIC. How does the VC play into this picture as far as isolating things? Is all Vmotion traffic just between the ESX boxes once the VC init the process?

[khughes]

Well the setup I was going for as you saw went through some modifications over the thread that was linked. You always always always want to have redundant pNICs on your service console, so just assigning one pNIC to the SC should never be an option.

What you might want to do, and what you really couldn't see from the diagrams, you have pnic1, pnic2, pnic3, pnic4:

Using 802.1q--

vswitch1 (pnic1, pnic2)

SC -> pnic1 / failover of pnic2

vMotion -> pnic2 / failover pnic1

vswitch2 (pnic3, pnic4)

production network -> pnic3/4

What this does is it keeps traffic on your SC and vmotion on different physical nics until you have a failure then it'll share one (using vlan tagging they'll still be separate), and the production network shares 2 at all times. Your vmotion traffic doesn't need to touch anything it just needs to be able to talk to the other hosts. VMotion traffic actually has the root password traveling with it in plain text so that is a security issue with having vmotion and production/sc traffic on the same network. We have a physical VC as well, it just needs to be able to communicate with the esx hosts on the network that hosts the SC I believe.

• Kyle

[cef2lion]

Good info to redesign things. The other thing I need to do is change the SC ip address. Given all four ESX boxes are up and talking to the VC. How would I go about changing SC ip addresses on each ESX sever? Don't want to mess up the VC and have it thinking a new ESX has joined and SQL data isn't matched to the ESX server. What happened when I first setup was give the ESC SC a public address. That is not needed. Want to switch that to a private IP. What I did was get a working model and now going back and making things right.

[Texiwill]

Hello,

As long as the name is the same it should not have a problem. But you may wish to run a test on that first.

With 4 pNICs khughes setup is your best setup for redundancy, security, and performance.

Before you do anything within VC, backup the database. Then do your change, if you see anything you did not expect, undo the SC IP change and then restore your backup. This may actually be one for your VMware Support Representative. You may also want to search the VI: VirtualCenter 2.x forum for a answer.

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 Blogs - http://www.itworld.com/ and http://www.networkworld.com/community/haletky

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization