I think it’s time to stop using the term “network function virtualization”. Why? Because it doesn’t exist, at least not in the way the term suggests. The term is a category error, and when people try to make sense of the term, confusion and frustration ensue. Think of it like this: what’s the difference between a “virtual network function” and a “non-virtual network function”? For example, how is “virtual IP forwarding” different than “non-virtual IP forwarding?
If you have a home lab and don’t need vCenter, thee ESXi Embedded Host Client gives you web-based access to hidden features of your standalone ESXi host… without having to spin up a real vCenter server. As most everyone knows, the old VMware vSphere C# client has been on its way out for years. One of the things keeping it alive is the fact that not everyone has a vCenter Server, and even those who do don’t necessarily use the Web Client.
If you are running XenServer 5.6 FP1 or later, there is a little trick you can use to improve network throughput on the host. By default, XenServer uses the netback process to process network traffic, and each host is limited to four instances of netback, with one instance running on each of dom0’s vCPUs. When a VM starts, each of its VIFs (Virtual InterFaces) is assigned to a netback instance in a round-robin fashion.
Citrix Provisioning Services is very nice, but it does come with a slightly annoying quirk: All of your provisioned XenApp servers end up with the same STA ID! This will cause all sorts of problems for Citrix Access Gateway, Citrix Receiver, and anything else that may depend on having unique STA IDs. The good news is that fixing this little problem is easier than you might think. To resolve the duplicate STA ID issue, we’ll do the following: