Epyc VM to VM networking slow
-
@olivierlambert OK, won't comment any more... You can delete my comment at your leisure.
-
That's not what I meant either. I was just answering initially about the theoretical concern, mostly following @planedrop logical question, in other words "before fearing something, test it for real and see the real impact toward your requirements".
We already know you are affected, it's like you were afraid we wouldn't care about your use case while we are already deeply invested into getting a solution to a tricky problem that could affect some people in some situations.
-
@olivierlambert Nope, that was not on my mind! I KNOW you are taking care of this.
I just wanted to add my practical experience to someone asking theoretically if there is an issue. And for us there is one during backups, not during normal operations.
Backups taking 2-3 times longer on EPYC than on Intel might be an issue for someone thinking on deploying on "fairly large multi-datacenter environment".
No harm meant and no finger was pointed. Just a honest my 2 cents.
-
@olivierlambert Yeah and on this note I can say my entire lab is Threadripper, so suffers from the same issue, and it hasn't created any real world problems for me.
-
@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.
-
@linuxmoose Yeah testing it is definitely the way to go here, I don't think you'll see very many issues TBH.
It's worth noting that the speeds being seen were still multi gigabit, so again it's not like things are dead slow.
-
In the mean time, we'll keep you posted in here on our patches to test. So far, it's likely a patch in the guest (ie the Linux kernel) that might improve nicely the performance. And if you need very high NIC perf, you can use SR-IOV and enjoy native NIC perf, even if there's a some extra constraints.
-
@olivierlambert That's a good point about SR-IOV, would be a good workaround if super fast NIC speeds are needed in a guest specifically.
-
Would sr-iov with xoa help backup speeds?
-
@Forza said in Epyc VM to VM networking slow:
Would sr-iov with xoa help backup speeds?
If you specify the SR-IOV NIC, it will be wire-speed.
-
@Forza The XOA backup performance is more related to processing and not network, at least as I understand it and have tested.
So I don't think you'll see much of a change there.
-
On Intel, the biggest bottleneck ATM is the export speed capability of the Dom0. On AMD, the backup speed is also affected by the lack if equivalent of iPAT in Intel, but it might depends also on other factors (backup repo speed etc.)
-
@olivierlambert Yeah so far backups have been fast enough to not pose some huge issue though.
IMO if you have a huge VM (many TB) it should just be dealt with on a NAS or something instead of a VHD.
Still glad that qcow2 is coming though!
