But, resource pools are specifically for CPU/RAM resources. For network resources, you can only use the vSwitch for doing this, and that is also at the host level. You can create VLANs and assign a specific NIC to a vSwitch.

Traffic shaping can be performed on the vSwitches (virtual switches), but the vSwitch are after the HOST NIC interfaces, if you wanted to throttle the host interfacaes you would have to throttle on the physical switch, that they are connected to.

I have 4 physical NICs on the ESX Hosts, 4 virtual switches. No network redundancy is deployed. Each switch represents a physically segrated network segment. One of those segments, vSwitch3 in this instance, is my LAN segment that hosts a lot of servers. I want to prioritise, or limit, the network usage from specific hosts on my LAN, without limiting in any way the total throughput of the vSwitch.

I'm not running VLANs on any of this and not deploying QOS across the LAN just to deliver this functionality.

Ideally, I want to configure the NICs on the VM's to behave themselves (be thottled or capped), but if I can't do that, I'll have to look at guest OS-Level implementations, which will be complicated.

Is your VM PortGroup things an option? I"m not sure what that refers to in relation my current environment. But then, I wasn't all that clear on my current environment I guess. ;)

Why can they not simply have resource pooling for network resources the same way they have for most other things? :)

By what I can see, there is a link between a vSwitch and a physical NIC, so the same physical NIC cannot be present on multiple vSwitches? If there is a way to make this work, then I can probably do the throttling at a vSwitch level and simply deploy my "throttled" hosts to that vSwitch.

VMs use the VM Network Portgroup for their traffic from the virtual NIC they use through the physical NIC of the host. Not all the NIC bandwidth is used solely for VMs...potentially. It's just whatever you have configured for the phys NIC on the vSwitch (could be Mgmt traffic, vKernel traffic for VMotion, etc.). But, it sounds like in your case, vSwitch 3 may be used solely for the VMs? If that is true, then configuring the VM Network portgroup on vSwitch3 would limit the traffic for the VMs that use that vSwitch, and thus the traffic passing through the NIC assigned to vSwitch3. Yes, the same phys NIC canNOT be assigned to multiple vSwitches. But a vSwitch can have multiple phys NICs...for redundancy, etc.

At the ESX HOST Level
- the physical servers have 4 physical NICs, each allocated to a seperate vSwitch. Each physical NIC is connected to a segregated PHYSICAL network.

At the GUEST OS Level
- I want to rate-limit the network traffic to/from specific hosts
- the guest os in question has 2 virtual nics, connected to 2 different vswitches
- i want to rate-limit the virtual nic connected to vswitch3

The "problem I'm trying to solve" is that the nature of the network is such that some machines ip traffic communicate entirely within the cluster, even when crossing physical network boundaries, without their packets "hitting the wire" and being limited to wirespeed, which esx delivers/sends at full speed. This causes flow-on affects as my guests try to write data to disks, deliver that data out the physical wire etc.

Basically, an FTP session from a box on vSwitch3 to the DMZ (vSwitch2), has data delivered via IP at a rate faster than its disks can keep up, leading to disk congestion on OTHER requests to access the guests disks. This issue has cropped up due to the deployment of a collapsed network environment using a virtual firewall, meaning that this traffic now never actually hits a physical wire/speed limit. In fact, esx reports network speeds of >35,000Kb/s on send/receive to this particular guest in this situation.

Without affecting the other virtual machines, I merely want to "slow down" the rate at which 2 of my hosts can generate IP packets, which obviously isn't something ESX is overly concerned about (SLOWER? YOU WANT SLOWER? ARE YOU MAD?!?!?!) and dont seem to make easy.

From what I can see with PortGroups, this again targets the transmission of packets onto the physical wire/NIC, not the virtual NIC.