It is accepted practice amongst most of the virtualization world that you can use a 100mb/s link for your Service Console port, because there is not much traffic that is flowing over that link.

Well in the majority of the cases that is true.

For example. vmnic0 is running the Service Console. This link is connected at 1000mb/s

As you can see in the screen shot there is nothing really running through the Service Console (vmnic0)

But how about this

Now you would (and should) most definitely ask what is running through vmnic0 that is causing that amount of traffic.

It is not a Backup agent, no VMkernel on vmnic0 either. It was a regular virtual machine import.

A bit more of an explanation. How often does it happen that you are asked to import a virtual machine from somewhere?  A virtual appliance? A new image that has to go onto the ESX?

When importing a virtual machine into an ESX host, the traffic goes directly through the service console and it's vmnic.

As you can see that amount of traffic can easily surpass 100mb/s.

But if you have the option of only running a SC on 100mb/s then you will have to take into account the virtual machine imports will take longer - they can take much.. much longer if you run multiple simultaneous imports. I do not know what impact it will have on the other traffic that has to run on the Service console. I do not know of any QOS on ESX that will ensure that some kind of traffic is more important than others.

Finding a 100mb/s NIC is something that you will have to go on a treasure hunt for - we are at the time and age that a 1Gb is default and soon 10Gb will become the norm. the issue here is not the NIC - it is the switchport. Not everything can run on 1Gb end-to-end, so here is your limitation.

Solutions?

1. Run your SC on 1Gb
2. Share your SC with other ESX Network components (Vmkernel / VM Traffic) and lower the level of security for your ESX
3. Create an aggregate to widen the "pipe"
4. Run your SC on 100mb/s and take into account that virtual machine imports will take longer

Thanks to Tom Howarth, Scott Lowe, Roger Lund, Dave Graham, Mike LaSpina and Tommy Hall for joining in on the discussion.