What’s your physical NIC capacity on the KVM host and that of your network
switch connecting your hosts? It may be possible that you need some other
settings or correct bridge configuration or nicAdapter for your VMs.
Regards.
________________________________
From: m...@swen.io <m...@swen.io>
Sent: Tuesday, August 13, 2024 4:07:02 PM
To: users@cloudstack.apache.org <users@cloudstack.apache.org>
Subject: AW: vm nic speed on kvm host
Hi Jayanth,
Iperf3 shows the full 2 Gbit bandwith when testing, still scp just can utilize
2 Gbit. How can we troubleshoot virtio?
Regards,
Swen
-----Ursprüngliche Nachricht-----
Von: Jayanth Babu A <jayanth.b...@nxtgen.com.INVALID>
Gesendet: Montag, 12. August 2024 18:16
An: users@cloudstack.apache.org
Betreff: Re: vm nic speed on kvm host
Then 2 * 25 GbE shouldn’t matter if they’re running on the same host. Please
try running iperf3 on instances. I see that the device driver is also “virtio”
so the issue may lie somewhere else.
Regards,
Jayanth Reddy
From: m...@swen.io <m...@swen.io>
Date: Monday, 12 August 2024 at 9:40 PM
To: users@cloudstack.apache.org <users@cloudstack.apache.org>
Subject: AW: vm nic speed on kvm host
Yes, both instances have 256000 KB/s defined. Physical link between hosts is
2x25G NIC as LACP bond. But both instances are running on the same kvm host.
You want to to use iperf3 on instances or kvm host?
Regards,
Swen
-----Ursprüngliche Nachricht-----
Von: Jayanth Babu A <jayanth.b...@nxtgen.com.INVALID>
Gesendet: Montag, 12. August 2024 17:59
An: users@cloudstack.apache.org
Betreff: Re: vm nic speed on kvm host
Do both instances have 256000 KB/s defined on their XML? Just asking, what’s
your physical link speed?
Can you also try with iperf3 to gain some insights?
Regards,
Jayanth Reddy
From: m...@swen.io <m...@swen.io>
Date: Monday, 12 August 2024 at 9:22 PM
To: users@cloudstack.apache.org <users@cloudstack.apache.org>
Subject: vm nic speed on kvm host
Hi all,
we are testing some settings on our ACS installation to get bandwidth up on vm
level. But it looks like we are stuck at 1Gbit.
Here is our test workflow:
* Create 2 instances within the same network
* Create a 20G file on one of the instances
* Scp the file from 1 instance to the other
* Overserve bandwidth via nload
We are using global setting vm.network.throttling.rate with value of 1000 and
virsh dumpxml looks like this:
<interface type='bridge'>
<mac address=''/>
<source bridge='brbond1-673'/>
<bandwidth>
<inbound average='128000' peak='128000'/>
<outbound average='128000' peak='128000'/>
</bandwidth>
<target dev='vnet13'/>
<model type='virtio'/>
<link state='up'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03'
function='0x0'/>
</interface>
Which looks okay to us and we are able to get near max 1 Gbit bandwidth during
scp. (128000 kbyte/s = 1 Gbit)
When altering vm.network.throttling.rate to 2000 virsh dumpxml looks like
this:
<interface type='bridge'>
<mac address='02:01:00:d4:00:3e'/>
<source bridge='brbond1-811'/>
<bandwidth>
<inbound average='256000' peak='256000'/>
<outbound average='256000' peak='256000'/>
</bandwidth>
<target dev='vnet14'/>
<model type='virtio'/>
<link state='up'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03'
function='0x0'/>
</interface>
Which should be okay, it is double the size. But scp still maxes out near 1Gbit.
Any idea where to look for the bottleneck to get a 2 Gbit connection running
between 2 instances in the same network?
Regards,
Swen
Disclaimer *** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION
intended solely for the use of the addressee(s). If you are not the intended
recipient, please notify the sender by e-mail and delete the original message.
Further, you are not authorised to copy, disclose, or distribute this e-mail or
its contents to any other person and any such actions are unlawful and strictly
prohibited. This e-mail may contain viruses. NxtGen Datacenter & Cloud
Technologies Private Ltd (“NxtGen”) has taken every reasonable precaution to
minimize this risk but is not liable for any damage you may sustain as a result
of any virus in this e-mail. You should carry out your own virus checks before
opening the e-mail or attachment. NxtGen reserves the right to monitor and
review the content of all messages sent to or from this e-mail address.
Messages sent to or from this e-mail address may be stored on the NxtGen e-mail
system. *** End of Disclaimer ***NXTGEN***
Disclaimer *** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION
intended solely for the use of the addressee(s). If you are not the intended
recipient, please notify the sender by e-mail and delete the original message.
Further, you are not authorised to copy, disclose, or distribute this e-mail or
its contents to any other person and any such actions are unlawful and strictly
prohibited. This e-mail may contain viruses. NxtGen Datacenter & Cloud
Technologies Private Ltd (“NxtGen”) has taken every reasonable precaution to
minimize this risk but is not liable for any damage you may sustain as a result
of any virus in this e-mail. You should carry out your own virus checks before
opening the e-mail or attachment. NxtGen reserves the right to monitor and
review the content of all messages sent to or from this e-mail address.
Messages sent to or from this e-mail address may be stored on the NxtGen e-mail
system. *** End of Disclaimer ***NXTGEN***
