@olivierlambert said in Epyc VM to VM networking slow:

I feel that this is going to be a much larger issue for us.

Before that I would strongly encourage to test if it's really a problem, because it's really not in 90% of the use cases we've seen.

Thanks @olivierlambert - that is definitely the plan. I still see XCP-ng as the best alternative we've considered so far.

@planedrop It is a mix of anything and everything one would find in an enterprise datacenter. Lots of application server to database server connections, and we are also running Rancher with Longhorn storage, which is particularly sensitive to latency, but mostly of the storage type - not networking latency. We will just have to test and see if it is indeed an issue. If I understand correctly, the main issue is with performance between VMs on the same virtualization host. In that case, we can use rules to place application and db servers on separate hosts for better performance. Ironically, that is the opposite of the configuration we currently use with VMware.
Anyway, we will just have to do some testing to see if it is an issue worth stressing over for us.
Thanks.

@olivierlambert said in Epyc VM to VM networking slow:

I feel that this is going to be a much larger issue for us.

Before that I would strongly encourage to test if it's really a problem, because it's really not in 90% of the use cases we've seen.

Thanks @olivierlambert - that is definitely the plan. I still see XCP-ng as the best alternative we've considered so far.

@planedrop It is a mix of anything and everything one would find in an enterprise datacenter. Lots of application server to database server connections, and we are also running Rancher with Longhorn storage, which is particularly sensitive to latency, but mostly of the storage type - not networking latency. We will just have to test and see if it is indeed an issue. If I understand correctly, the main issue is with performance between VMs on the same virtualization host. In that case, we can use rules to place application and db servers on separate hosts for better performance. Ironically, that is the opposite of the configuration we currently use with VMware.
Anyway, we will just have to do some testing to see if it is an issue worth stressing over for us.
Thanks.

@olivierlambert I know that I am late to this thread, but I would like to ask if there is any realistic time estimate for a workable fix, or even for a temporary patch or workaround?
We have been trialing XCP-ng with the compiled version of Xen Orchestra as a potential replacement for VMware in a fairly large multi-datacenter environment, before doing an "official" proof of concept. My concern is that we've done all of our testing on our freshly retired older Intel virtualization hosts - as we've just completed replacing everything with AMD EPYC-based servers. Until now, our only matter of concern has been the 2TB virtual disk limit. I feel that this is going to be a much larger issue for us. It sounds as if I need to pull in a pool of EPYC systems to expand our testing.
Thanks in advance for any input or guesstimates that you may be able to provide.