Virtual Center Bandwidth

[hardingp]

How much Traffic is travelling between Virtual Center and the ESX hosts?

So far I can only see is:

1. Accessing servers and querying their status inside VIC

2. Configuration changes via VIC

3. Opening a Console through VIC directly to the virtuals on the target ESX host would generate bandwidth

This Traffic would be faily minima, no?

Is anyone aware of additional traffic that would flow the Service Console lines?

[mcowger]

4) usage of a client connected ISO

5) Uploading files from your desk to a datastore (via the API or SCP).

--Matt

[RParker]

> This Traffic would be faily minima, no?

There is a decent amount of traffic depending on the number of ESX hosts / VM's you have. This could become VERY saturated given that users would access the VC (for web access or VIC) also.

So if you have a good sized environment and users with console access, that could generate more traffic than you think.

[mcowger]

In our env, our VC server maintains around 60kbit. We have 24 hosts running 200 VMs.

--Matt

[RParker]

> In our env, our VC server maintains around 60kbit. We have 24 hosts running 200 VMs.

Well thanks for that, I thought traffic would be much higher. Maybe they made it more efficient, but I heard from other groups that VC was quite "chatty".

[hardingp]

Excellent...

Does anyone have any data on how much b/w the consoles are consuming?

[Texiwill]

Hello,

Moved to the VI: VirtualCenter 2.x forum.

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

[DeeJay]

There's also the VM performance stats that virtualcentre collates and stores.

We have relatively low bandwidth MPLS connections between VC and ESX hosts and it presents no issues for using VC. The only issue we've had is accessing the console of a VM over a WAN (though the traffic is of course between the VC client (not the VC server) and the ESX server. Bandwidth utilisation is pretty high and the VC client does drop the console session when large amounts of changes are made on the console of the machine.

In terms of working out how much bandwidth is required for this, it's effectively a VNC server and metrics for VNC are pretty readily available.