Bug 697811 - Network connection crashes in virtual machine when trying to update
Network connection crashes in virtual machine when trying to update
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
15
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-19 07:00 EDT by Honza Horak
Modified: 2013-01-09 18:48 EST (History)
12 users (show)

See Also:
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:


Attachments (Terms of Use)
output of "virsh..." for the machine where I've noticed no failure (2.41 KB, application/octet-stream)
2011-07-14 12:20 EDT, Honza Horak
no flags Details
output of "virsh..." for the machine where I've noticed two failures (2.67 KB, application/octet-stream)
2011-07-14 12:21 EDT, Honza Horak
no flags Details
dmesg from guest after network crashed (13.84 KB, text/plain)
2011-07-21 04:55 EDT, Honza Horak
no flags Details
dmesg from physical machine after network crashed (3.43 KB, text/plain)
2011-07-21 04:56 EDT, Honza Horak
no flags Details

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.