Bug 697811

Summary: Network connection crashes in virtual machine when trying to update
Product: [Fedora] Fedora Reporter: Honza Horak <hhorak>
Component: qemuAssignee: Fedora Virtualization Maintainers <virt-maint>
Status: CLOSED DEFERRED QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: amit.shah, berrange, dwmw2, ehabkost, hbrock, itamar, jaswinder, jforbes, knoel, scottt.tw, tburke, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-28 20:08:52 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
output of "virsh..." for the machine where I've noticed no failure
none
output of "virsh..." for the machine where I've noticed two failures
none
dmesg from guest after network crashed
none
dmesg from physical machine after network crashed none

Description Honza Horak 2011-04-19 07:00:26 EDT
Description of problem:
When I'm using RHEL5 on my virtual machine and trying to update packages from beaker repository, network connection crashes during downloading packages. It fails unexpectedly in the middle of downloading (not in the same place, however).

I'm using NetworkManager on my local machine together with NAT and default virtual network in virtual manager. 

Some info from Virtual Network Interface:
Source device: Virtual network 'default': NAT
Device model: Hypervisor default

Version-Release number of selected component (if applicable):
rpm -q virt-manager
virt-manager-0.8.7-3.fc15.noarch
rpm -q libvirt
libvirt-0.8.8-4.fc15.x86_64

How reproducible:
always

Steps to Reproduce:
1. Install RHEL5 from DVD on virtual machine
2. Add beaker repos if not already done (baseurl=http://lab.rhts.englab.brq.redhat.com/distros/pub/rhel/rel-eng/RHEL5.6-Server-20110106.0/5/x86_64/os/Server)
3. try network connection - it works
4. run yum update
5. watch update process stops because of network has crashed
6. try network connection in virtual machine or ping the virtual machine - both don't work any more
7. run ifdown eth0 && ifup eth0 in virtual machine
8. try network connection in virtual machine or ping the virtual machine - both work again
  
Actual results:
network connection fails, which interrupts update

Expected results:
update proceeds

Additional info:
The network connection outside virtual machine is not influenced and I don't see any problems when using network in other way than updating packages. 
If you need any additional info or some logs, please, let me know.
Comment 1 Cole Robinson 2011-07-12 18:41:48 EDT
As root, please provide the output of

virsh dumpxml $vmname

Is any specific package being installed at when the network crash? Where exactly in the yum command do things go strange?
Comment 2 Honza Horak 2011-07-14 12:18:37 EDT
(In reply to comment #1)
> Is any specific package being installed at when the network crash? Where
> exactly in the yum command do things go strange?

It happens during downloading packages, but by different package every-time, not by a specific one.

What's more, I've tried to reproduce this failure again on repository http://lab.rhts.englab.brq.redhat.com/distros/pub/rhel/rel-eng/latest-RHEL-5-Server/tree-x86_64/ (because the previous one exists no more) and it failed twice on one virtual machine, but succeeded on the second machine. I will attach outputs of "virsh dumpxml $vmname" of both machines in the next comment.
Comment 3 Honza Horak 2011-07-14 12:20:33 EDT
Created attachment 513217 [details]
output of "virsh..." for the machine where I've noticed no failure
Comment 4 Honza Horak 2011-07-14 12:21:11 EDT
Created attachment 513218 [details]
output of "virsh..." for the machine where I've noticed two failures
Comment 5 Honza Horak 2011-07-14 12:26:34 EDT
(In reply to comment #2)
> (because the previous one exists no more) and it failed twice on one virtual
> machine, but succeeded on the second machine. I will attach outputs of "virsh
> dumpxml $vmname" of both machines in the next comment.

I've forgot to mention that internet connection crashed during downloading package approx. 230/480 the first time, but the "yum update" succeeded the third time (I don't remember details about the second try).

It seems like the connection crashed after some time every-time, but the third attempt didn't last long enough, because many packages had been already downloaded from previous attempts -- so "yum update" finished successfully.
Comment 6 Cole Robinson 2011-07-14 17:32:16 EDT
Hmm, really not sure what could cause your network connection to just go down. Whatever it is, probably outside the scope of virt-manager or libvirt, so reassigning to qemu.

Any error messages in /var/log/libvirt/qemu/$vmname.log ?
Comment 7 Honza Horak 2011-07-15 02:24:11 EDT
(In reply to comment #6)
> Any error messages in /var/log/libvirt/qemu/$vmname.log ?

There is no error nor warning.
Comment 8 Justin M. Forbes 2011-07-20 16:52:22 EDT
Is there anything in dmesg after the guest network fails?
Comment 9 Honza Horak 2011-07-21 04:55:09 EDT
Created attachment 514164 [details]
dmesg from guest after network crashed

(In reply to comment #8)
> Is there anything in dmesg after the guest network fails?

I don't understand the messages very much, so I'm attaching dmesg output from guest now and the last part of dmesg from my physical machine will follow.
Comment 10 Honza Horak 2011-07-21 04:56:15 EDT
Created attachment 514166 [details]
dmesg from physical machine after network crashed
Comment 11 Fedora Admin XMLRPC Client 2012-03-15 13:55:15 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Cole Robinson 2012-05-28 20:08:52 EDT
Given that F15 is end of life in less than a month, it's unlikely this will get fixed before hand. Honza, if you can reproduce this issue with a later Fedora version, please reopen and we can go from there.