[9.000][ANSWERED] vmware - Suggested settings?

Hmmm, don't know that I agree with that.  Giving more than one vCPU to a guest can cause all kinds of scheduling anomalies (according to the vmware engineers I know, not just my opinion.)  You're better off with either a single core/thread on a faster CPU or go bare metal.  Preferably a xeon 1230 or somesuch.

Hmmm, don't know that I agree with that.  Giving more than one vCPU to a guest can cause all kinds of scheduling anomalies (according to the vmware engineers I know, not just my opinion.)  You're better off with either a single core/thread on a faster CPU or go bare metal.  Preferably a xeon 1230 or somesuch.

Yeah, I've read once a whitepaper concernig SMP operation in ESXi in the past too. If I remember right it has something to do with the fact, that the scheduler for some reason has to lock the physical resources for all vCPUs in a SMP VM in the same timeslot, which can lead to delays, until the required resources are available at the same time. But as long as the host system is performant enough, it shouldn't affect operation too much unless your (shared) VM hostsystem has high load.

I've seen many SMP ASGs/SophosUTMs on VMWare/ESXi shared with other VMs (and I'm running my own ASGs since years this way) and have never personally experienced or heard about an real impact with SMP operation of a virtualized ASG. So I guess this is a overrated, theoretical issue. 

I also have seen virtualized SMP ASGs easily handling 200...300MBit throughput with FullUTM without issues, So I assume virtualized ASGs can be scaled in real life up to a few hundred MBit throughput through the ASG (which is usually sufficient for many SMB enviroments) beyond that I'd recommend Hardware Appliances or Software on bare metal...

I absolutely agree with the recommendation to go with bare metal if possible for performance reasons, but virtualization can be a good way to work around the ASG HCL restrictions....

Wer Schreibfehler findet, darf sie behalten. Wenn ich via IPad poste, sind Verschreiber und grammatikalische Aussetzer irgendwie an der Tagesordnung.

Hmmm, don't know that I agree with that.  Giving more than one vCPU to a guest can cause all kinds of scheduling anomalies (according to the vmware engineers I know, not just my opinion.)  You're better off with either a single core/thread on a faster CPU or go bare metal.  Preferably a xeon 1230 or somesuch.

Yeah, I've read once a whitepaper concernig SMP operation in ESXi in the past too. If I remember right it has something to do with the fact, that the scheduler for some reason has to lock the physical resources for all vCPUs in a SMP VM in the same timeslot, which can lead to delays, until the required resources are available at the same time. But as long as the host system is performant enough, it shouldn't affect operation too much unless your (shared) VM hostsystem has high load.

I've seen many SMP ASGs/SophosUTMs on VMWare/ESXi shared with other VMs (and I'm running my own ASGs since years this way) and have never personally experienced or heard about an real impact with SMP operation of a virtualized ASG. So I guess this is a overrated, theoretical issue. 

I also have seen virtualized SMP ASGs easily handling 200...300MBit throughput with FullUTM without issues, So I assume virtualized ASGs can be scaled in real life up to a few hundred MBit throughput through the ASG (which is usually sufficient for many SMB enviroments) beyond that I'd recommend Hardware Appliances or Software on bare metal...

I absolutely agree with the recommendation to go with bare metal if possible for performance reasons, but virtualization can be a good way to work around the ASG HCL restrictions....

Wer Schreibfehler findet, darf sie behalten. Wenn ich via IPad poste, sind Verschreiber und grammatikalische Aussetzer irgendwie an der Tagesordnung.