CentOS virt - Sep 2014 - Issues with Ubuntu 14 as a guest VM, and network throughput..

I have a CentOS 6.5 server running as a host for about a dozen other VM's,
and all were running just fine.   I had a mix of CentOS, Ubuntu, and FreeBSD
VM's running, no problem at all.   

 I then updated the Ubuntu VM's to the newer 14.x release, and that
installed a 3.13 linux kernel, and after that (which I didn't notice right
at the start) the network throughput outbound was abysmal at best.   Where
before I could move an ISO image in just moments, trying to send out an
image from the VM now took forever, with constant timeouts.   I tried it on
multiple Ubuntu VM's and all have the exact same issue.   I thought this is
strange, the older 12.x stuff ran just fine, so I thought well the
networking is in the kernel so let's back up the kernel.   

 So I grabbed a 3.11 kernel and loaded it, and that was a good improvement,
but still no winner, so then I backed off to a 3.8.13 kernel which seemed to
be the newest of the 3.8's, and bingo everything started working fine.  I
then tried a couple Ubuntu machines that were standalone boxes (not VM's)
with the newer 3.13 it loads by default, and running independent like that
throughput is great, so it's some interaction with the qemu/kvm host.   

 Has anyone run into this, or have any idea, or know of any tunable changes
I can make that would make the VM play nice with the newer recommended
kernel?   I was actually stunned changing kernels made the diff between
getting hundreds of megs of throughput on the host, to getting a meg or two
if lucky, with constant pauses.    At the same time, my other CentOS and
FBSD VM's seem to run fine, but then again CentOS sticks with an older
kernel it seems.  



---
Howard

On 30/09/14 00:50, Howard Leadmon wrote:
>  I have a CentOS 6.5 server running as a host for about a dozen other
VM's,
> and all were running just fine.   I had a mix of CentOS, Ubuntu, and
FreeBSD
> VM's running, no problem at all.   
> 
>  I then updated the Ubuntu VM's to the newer 14.x release, and that
> installed a 3.13 linux kernel, and after that (which I didn't notice
right
> at the start) the network throughput outbound was abysmal at best.
Hi,

as you already figured out, this seems to be an ubuntu or kernel issue
(maybe virtio drivers are missing in these kernels?).
So it would be best to contact canonical or kernel folks about it.
Furthermore you didn't bother to say if you are running kvm or xen
or something completely different?

HTH

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Gesch?ftsf?hrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/30/2014 01:50 AM, Howard Leadmon wrote:
> Has anyone run into this, or have any idea, or know of any tunable
> changes I can make that would make the VM play nice with the newer
> recommended kernel?   I was actually stunned changing kernels made
> the diff between getting hundreds of megs of throughput on the
> host, to getting a meg or two if lucky, with constant pauses.    At
> the same time, my other CentOS and FBSD VM's seem to run fine, but
> then again CentOS sticks with an older kernel it seems.
> 
There is an open bug regarding the hypervisor low performance in 14.04.
This is probably a kernel issue and they had a patch for it as far as
I can remember hat tested the issue.

You can try to contact the mailing list of ubuntu servers and lookup
the bug at the bugzilla.

Eliezer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUKtbGAAoJENxnfXtQ8ZQUToIH/2rTY0B/x45eOUxlp30S77H/
VKqebsAZWPM5zcP9SDWYWsLssRHzbmXxZJ5DmIU/wMLJai5wKF2bl0gGWoB6e44i
VO1n0L2d5dgyqOh/2ll6oyg3tqbIsPs+Un4WWJYj3EOjHPmLpDiM5bTQeZeu46x4
mM+dlqCyqWUo4Hk/gglLmI4x+/htKW+sxBcF6Wv58pPd89AWmoQSEqcNBkLcptMn
pcm5px3Jp/meaovMu8IfiDdYY3K1iC6XjTC6frvTC8RqqSDom3sM4E1jUaZwtgOn
lf8qI4KrFrUqHa35KhC0CdyRFxSbCUAw4KODWjy4FydEBE907hkfP6TTQQqHuq4=vjfP
-----END PGP SIGNATURE-----