From: Gregory Haskins <gregory.haskins@gmail.com>
To: dbareiro@gmx.net, KVM General <kvm@vger.kernel.org>
Subject: Re: Bandwith limitation with KVM VMs
Date: Mon, 03 Aug 2009 23:01:30 -0400 [thread overview]
Message-ID: <4A77A48A.1060606@gmail.com> (raw)
In-Reply-To: <20090804011742.GL23503@defiant.freesoftware.org>
[-- Attachment #1: Type: text/plain, Size: 2892 bytes --]
Daniel Bareiro wrote:
> Hi Gregory.
>
> On Monday, 03 August 2009 12:52:28 -0400,
> Gregory Haskins wrote:
>
>>> I have a KVM VM that it has installed a MRTG on the network
>>> interface and that it doesn't register more than 10 Mbps, seeming
>>> that per moments it is saturated in this value.
>>>
>>> Has KVM some bandwidth limitation of the virtualized network
>>> interfaces? In such case, exists some way to increase that
>>> limitation?
>
>> There is no set artificial limit afaict, though there are a large
>> number of factors that can affect performance. Of course, everything
>> has an ultimate ceiling (KVM included) but I have found this limit in
>> KVM to be orders of magnitude faster than 10Mbps. Properly tuned,
>> you should easily be able to saturate a GE link at line rate, or even
>> 4Gbps-5Gpbs of a 10GE link.
>
>> However, since you are only hitting 10Mb/s now, there is ton of
>> headroom left even on upstream KVM so you might find it to be
>> satisfactory as is, once you address the current bottleneck in your
>> setup.
>>
>> Things to check: What linkspeed does the host see to the next hop?
>> How much bandwidth does the host see to the same end-point? What is
>> your overall topology, especially for the VM (are you using -net tap,
>> etc). What MTU are you using. Etc.
>
> It draws attention that when executing 'cfgmaker' from MRTG server
> against the IP of the VM, it returns max speed of 1250 kBytes/s, that
> is to say 10 Mbps:
>
> sparky:~# /usr/bin/cfgmaker --global 'WorkDir: /tmp' --global \
> 'Options[_]: bits,growright' xxxxxxxxxxxxxx@10.1.0.42
> [...]
> MaxBytes[10.1.0.42_2]: 1250000
>
>
> But nevertheless from within of the VM I see the following thing:
>
> aps2:~# ethtool eth0
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Supports auto-negotiation: Yes
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Advertised auto-negotiation: Yes
> Speed: 100Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 32
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: pumbg
> Wake-on: d
> Current message level: 0x00000007 (7)
> Link detected: yes
>
>
> do you think that can give some indication?
Hmm.. I am not familiar with MRTG/cfgmaker, but from your ethtool output
I suspect you are not using virtio. How do you launch the guest?
Have you actually run something like netperf or an rsync to see what
type of bandwidth you actually get? Perhaps this is just the mrtg tool
getting confused about the actual interface capabilities.
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
next prev parent reply other threads:[~2009-08-04 3:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-03 16:32 Bandwith limitation with KVM VMs Daniel Bareiro
2009-08-03 16:52 ` Gregory Haskins
2009-08-04 1:17 ` Daniel Bareiro
2009-08-04 3:01 ` Gregory Haskins [this message]
2009-08-04 9:48 ` Daniel Bareiro
2009-08-04 10:05 ` Kai Zimmer
2009-08-04 9:25 ` Kai Zimmer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A77A48A.1060606@gmail.com \
--to=gregory.haskins@gmail.com \
--cc=dbareiro@gmx.net \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox