VMware Cloud Community
wilson94t
Enthusiast
Enthusiast

Share ESX Console NIC with VM Backup Network. Good/Bad?

Over the years, (since ESX 1.5 actually) I've become quite confortable with dedicating a NIC to the console. With ESX 3.5, I am at a crossroads.

The annoying message about my console network not being redundant has gotten the best of me an I am considering 3 actions.

1. Do nothing. I've been using this configuration quite happily with ESX 3.0.x. My virtual machines stay powered on during isolation response.

2. Find some way to disable the message. Anyone know how to do this?

3. Create a vswich using two network ports and sharing the COS with my virtual machine "backup network" to create a redundant vswitch. This backup network can recieve a fair amount of traffic during the backup period,but is otherwise fairly idle. There has been a standing concern for years about bonding the console port with a virtual machine network, has anything changed? Is this now a recommended proceedure? Is it considered reliable? Are there any concerns putting the console and vm networks on the same vswitch?

Assume a busy 4 socket, 16Cores 128GB box, running 25-35 VM's, 75% Memory and 45-60% CPU utilziation. Networks are 1Gb/Ethernet.

0 Kudos
6 Replies
weinstein5
Immortal
Immortal

or a 3' - just add a service console port to an existing vswitch it will do noting more than be an extra port for the HA heart beat to go out -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful
0 Kudos
wilson94t
Enthusiast
Enthusiast

... and would using a my vm-backup network be a problem? let's consider the others to be more busy.

0 Kudos
weinstein5
Immortal
Immortal

No that should be fine

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful
0 Kudos
Texiwill
Leadership
Leadership

Hello,

Actually, if it is a vm-backup network that the VMs itself do not use and only sits on the SC (ala esXpress, Vizioncore, VISBU, etc) then this is fine, it is really just another Service Console port anyways.

However, if this is a vm backup network in the more traditional sense where the VMs can see this network then I would definitely NOT do this. It would make the VM-backup network an attack point to gain access to the SC portgroup.

You never want your Production VMs to see any part of your Administrative network.


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.

CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354

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

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
wilson94t
Enthusiast
Enthusiast

The question is really a technical question about ESX and the COS.

The vm-backup network is for the VM's to communicate with the backup server. Backups are not done from within the ESX Console.

The ESX console in my case, runs on this administrative network. I will spare you the details, but suffice it to say that there are sufficient controls such that my information security department finds the configuration to be approved.

The technical question is, if I have a shared vswitch between my ESX console and the VM-Backup network (where by the VM's transfer data to the backup servers), is there any stability concern for ESX? the VSwitch?

0 Kudos
wilson94t
Enthusiast
Enthusiast

There seems to be sufficeint evidence or conern elsewhere that combining the COS port with something moving prod/backup/admin traffic is not ideal, either from a security standpoint or from an ESX stability standpoint. The latter is the most concerning to me. Our current plan is therefore to keep COS seperate and add a second with the previously dedicated vmotion port.

0 Kudos