Re: debugging vio issue?
On Fri, Jun 6, 2014 at 12:27 PM, Giancarlo Razzolini wrote: > Em 06-06-2014 13:18, Christoph Borsbach escreveu: >> Hi, >> sorry, I don't know that, it's a VM at a hoster. I have no acces to the >> underlying host. > So, it could be a problem with the qemu/kvm version being a old one. > Mine is 2.0.0. > > Cheers, > > -- > Giancarlo Razzolini > GPG: 4096R/77B981BC > So i wanted to try the workaround ukc> change 199 199 vio* at virtio* flags 0x0 change [n] y flags [0] ? 2 on the previously broken : # uname -a # Linux raid 2.6.32-27-pve #1 SMP Tue Feb 11 16:18:29 CET 2014 x86_64 GNU/Linux # kvm --version # QEMU emulator version 1.7.0, Copyright (c) 2003-2008 Fabrice Bellard with last snapshot # uname -a OpenBSD bsd64.my.domain 5.5 GENERIC#167 amd64 i pkg_add iperf and if i used -d i encounter transfer problem between host and vm , yet my previous statement is somewhat true: host: Client connecting to 192.168.10.129, TCP port 5001 TCP window size: 57.1 KByte (default) [ 5] local 192.168.10.104 port 49871 connected with 192.168.10.129 port 5001 [ ID] Interval Transfer Bandwidth [ 5] 0.0-60.0 sec 0.00 ▒ ▒▒s 2459345519135549440 Bytes/sec best os ever: [ 9] 0.0-64.9 sec 17179869184 GBytes 2273912692 Gbits/sec [ 14] local 192.168.10.129 port 5001 connected with 192.168.10.104 port 49905 Waiting for server threads to complete. Interrupt again to force quit. [ 14] 0.0- 1.5 sec 48.1 KBytes 258 Kbits/sec -- - () ascii ribbon campaign - against html e-mail /\
Re: debugging vio issue?
Em 06-06-2014 13:18, Christoph Borsbach escreveu: > Hi, > sorry, I don't know that, it's a VM at a hoster. I have no acces to the > underlying host. So, it could be a problem with the qemu/kvm version being a old one. Mine is 2.0.0. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: debugging vio issue?
On Fri, Jun 06, 2014 at 11:23:12 -0300, Giancarlo Razzolini wrote: > Em 06-06-2014 09:31, Christoph Borsbach escreveu: > > Hello everyone, > > I just wanted to report that I too had this problem (sporadic hangs of the > > vio0-Interface) with 5.5-stable/amd64 in a KVM-VM. I tried the solution > > described by Philip Guenther and voilá, the problems are gone. I did no > > tests > > with regard to the performance, it seems alright. > > > > $ dmesg |grep vio > > vio0 at virtio0: RingEventIdx disabled by UKC: address > What is your underlying network in QEMU/KVM. I never had issues with vio > and I'm running 5.5 stable/amd64. I use it with macvtap on the host. And > some of them are isolated networks, where there is no hardware > interaction, it's all software based. I guess I'm lucky. Hi, sorry, I don't know that, it's a VM at a hoster. I have no acces to the underlying host. Regards, Christoph
Re: debugging vio issue?
On 06/06/2014 06:23 PM, Giancarlo Razzolini wrote: Em 06-06-2014 09:31, Christoph Borsbach escreveu: Hello everyone, I just wanted to report that I too had this problem (sporadic hangs of the vio0-Interface) with 5.5-stable/amd64 in a KVM-VM. I tried the solution described by Philip Guenther and voilá, the problems are gone. I did no tests with regard to the performance, it seems alright. $ dmesg |grep vio vio0 at virtio0: RingEventIdx disabled by UKC: address What is your underlying network in QEMU/KVM. I never had issues with vio and I'm running 5.5 stable/amd64. I use it with macvtap on the host. And some of them are isolated networks, where there is no hardware interaction, it's all software based. I guess I'm lucky. Cheers, QEMU/KVM Hi! In KVM-VM ( snapshot - 5 june) vio now can create vlans but they don't work properly. With e1000 driver in QEMU/KVM vlans works ok. Anyway thanks for vio ! Alex
Re: debugging vio issue?
On Fri, Jun 6, 2014 at 10:23 AM, Giancarlo Razzolini wrote: > Em 06-06-2014 09:31, Christoph Borsbach escreveu: >> Hello everyone, >> I just wanted to report that I too had this problem (sporadic hangs of the >> vio0-Interface) with 5.5-stable/amd64 in a KVM-VM. I tried the solution >> described by Philip Guenther and voilá, the problems are gone. I did no tests >> with regard to the performance, it seems alright. >> >> $ dmesg |grep vio >> vio0 at virtio0: RingEventIdx disabled by UKC: address > What is your underlying network in QEMU/KVM. I never had issues with vio > and I'm running 5.5 stable/amd64. I use it with macvtap on the host. And > some of them are isolated networks, where there is no hardware > interaction, it's all software based. I guess I'm lucky. > > Cheers, > > -- > Giancarlo Razzolini > GPG: 4096R/77B981BC > with proxmox 3 , if you load the link it stops working quickly. but the perf are amazing. -- - () ascii ribbon campaign - against html e-mail /\
Re: debugging vio issue?
Em 06-06-2014 09:31, Christoph Borsbach escreveu: > Hello everyone, > I just wanted to report that I too had this problem (sporadic hangs of the > vio0-Interface) with 5.5-stable/amd64 in a KVM-VM. I tried the solution > described by Philip Guenther and voilá, the problems are gone. I did no tests > with regard to the performance, it seems alright. > > $ dmesg |grep vio > vio0 at virtio0: RingEventIdx disabled by UKC: address What is your underlying network in QEMU/KVM. I never had issues with vio and I'm running 5.5 stable/amd64. I use it with macvtap on the host. And some of them are isolated networks, where there is no hardware interaction, it's all software based. I guess I'm lucky. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: debugging vio issue?
On Wed, May 28, 2014 at 11:37:54 -0700, Philip Guenther wrote: > On Wed, May 28, 2014 at 11:26 AM, Adam Thompson wrote: > > > Don't have a good answer for you, but I have similar problems with vio(4). > > Switching to e1000 on the KVM side solved my random hangs completely. > > > > The vio(4) manpage mentions > Setting flags to 0x02 disables the RingEventIndex feature. This can be > tried as a workaround for possible bugs in host implementations or vio > at > the cost of slightly reduced performance. > > Have any of you tested that to see whether it improves the situation? Hello everyone, I just wanted to report that I too had this problem (sporadic hangs of the vio0-Interface) with 5.5-stable/amd64 in a KVM-VM. I tried the solution described by Philip Guenther and voilá, the problems are gone. I did no tests with regard to the performance, it seems alright. $ dmesg |grep vio vio0 at virtio0: RingEventIdx disabled by UKC: address Thanks and have a nice day, Christoph
Re: debugging vio issue?
On Wed, May 28, 2014 at 11:37:54AM -0700, Philip Guenther wrote: >On Wed, May 28, 2014 at 11:26 AM, Adam Thompson ><[1]athom...@athompso.net> wrote: > > Don't have a good answer for you, but I have similar problems with > vio(4). > Switching to e1000 on the KVM side solved my random hangs > completely. > >The vio(4) manpage mentions >? ? ? Setting flags to 0x02 disables the RingEventIndex feature. >? This can be >? ? ? tried as a workaround for possible bugs in host implementations >or vio at >? ? ? the cost of slightly reduced performance. >Have any of you tested that to see whether it improves the situation? I'll try that. The man page isn't exactly clear on when to use the flags, but I suppose you don't want to say "If the driver hangs, try this" in the man page. ==ml -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Re: debugging vio issue?
On Wed May 28 2014 11:37, Philip Guenther wrote: > On Wed, May 28, 2014 at 11:26 AM, Adam Thompson wrote: > > > Don't have a good answer for you, but I have similar problems with vio(4). > > Switching to e1000 on the KVM side solved my random hangs completely. Same behaviour with RHEV 3.3. > The vio(4) manpage mentions > Setting flags to 0x02 disables the RingEventIndex feature. This can be > tried as a workaround for possible bugs in host implementations or vio > at > the cost of slightly reduced performance. > > Have any of you tested that to see whether it improves the situation? Thank you, Philip. I'll try that out. Norman
Re: debugging vio issue?
Em 28-05-2014 15:26, Adam Thompson escreveu: > Don't have a good answer for you, but I have similar problems with vio(4). > Switching to e1000 on the KVM side solved my random hangs completely. > -Adam I don't run current, but I have a 5.5-stable firewall that works perfectly using vio(4). But, I'm not using bridge on the linux host. I use macvtap. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: debugging vio issue?
On Wed, May 28, 2014 at 11:26 AM, Adam Thompson wrote: > Don't have a good answer for you, but I have similar problems with vio(4). > Switching to e1000 on the KVM side solved my random hangs completely. > The vio(4) manpage mentions Setting flags to 0x02 disables the RingEventIndex feature. This can be tried as a workaround for possible bugs in host implementations or vio at the cost of slightly reduced performance. Have any of you tested that to see whether it improves the situation? : morgaine; config -e -f /bsd OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Enter 'help' for information ukc> find vio 199 vio* at virtio* flags 0x0 ukc> change 199 199 vio* at virtio* flags 0x0 change [n] y flags [0] ? 2 199 vio* changed 199 vio* at virtio* flags 0x2 ukc> quit Saving modified kernel. config: /bsd.mp: Permission denied : morgaine;
Re: debugging vio issue?
Don't have a good answer for you, but I have similar problems with vio(4). Switching to e1000 on the KVM side solved my random hangs completely. -Adam -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: debugging vio issue?
We've seen this exact issue on 5.3 and 5.4 in the same scenario (KVM VM) and I was actually going to pose the same question you did after testing 5.5 later today. Our VMs are running as routers in an openstack cluster and it appeared to us that it was a lack of activity that caused the network failures because the moment I put some monitoring in place (which simply runs a ping from inside the VM at a regular interval), the problem seems to have gone away. That's obviously not a great solution... On Wed, May 28, 2014 at 10:55 AM, Michael W. Lucas wrote: > Hi, > > I have a 5.5/amd64 KVM VM running Ansible. Most of the time, it works > great. It's running the amd64 snapshot dated 27 May, from > ftp3.usa.openbsd.org. > > When I attempt to use the squid proxy to download large files from the > Internet, however, I occasionally get stalls. > > This is most easily reproduced when doing an upgrade. During my last > couple of upgrades, I've repeatedly done ^Z and "ifconfig vio0 down && > ifconfig vio0 up && fg" to make the download resume mid-set. > > Very occasionally, it happens during normal use. > > tcpdump on the proxy shows the proxy sending packets, but the OpenBSD > box not responding. My other terminal sessions hang, and I can no > longer SSH to the OpenBSD box. > > This doesn't happen on any of my other systems, so I'm inclined to > think it's vio(4) related. > > Any suggestions on how to debug this? > > Thanks, > ==ml > > -- > Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor > http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
debugging vio issue?
Hi, I have a 5.5/amd64 KVM VM running Ansible. Most of the time, it works great. It's running the amd64 snapshot dated 27 May, from ftp3.usa.openbsd.org. When I attempt to use the squid proxy to download large files from the Internet, however, I occasionally get stalls. This is most easily reproduced when doing an upgrade. During my last couple of upgrades, I've repeatedly done ^Z and "ifconfig vio0 down && ifconfig vio0 up && fg" to make the download resume mid-set. Very occasionally, it happens during normal use. tcpdump on the proxy shows the proxy sending packets, but the OpenBSD box not responding. My other terminal sessions hang, and I can no longer SSH to the OpenBSD box. This doesn't happen on any of my other systems, so I'm inclined to think it's vio(4) related. Any suggestions on how to debug this? Thanks, ==ml -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
