Bug 697811 - Network connection crashes in virtual machine when trying to update
Summary: Network connection crashes in virtual machine when trying to update
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-19 11:00 UTC by Honza Horak
Modified: 2013-01-09 23:48 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-29 00:08:52 UTC
Type: ---


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 16:20 UTC, 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 16:21 UTC, Honza Horak
no flags Details
dmesg from guest after network crashed (13.84 KB, text/plain)
2011-07-21 08:55 UTC, Honza Horak
no flags Details
dmesg from physical machine after network crashed (3.43 KB, text/plain)
2011-07-21 08:56 UTC, Honza Horak
no flags Details

Description Honza Horak 2011-04-19 11:00:26 UTC
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 22:41:48 UTC
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 16:18:37 UTC
(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 16:20:33 UTC
Created attachment 513217 [details]
output of "virsh..." for the machine where I've noticed no failure

Comment 4 Honza Horak 2011-07-14 16:21:11 UTC
Created attachment 513218 [details]
output of "virsh..." for the machine where I've noticed two failures

Comment 5 Honza Horak 2011-07-14 16:26:34 UTC
(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 21:32:16 UTC
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 06:24:11 UTC
(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 20:52:22 UTC
Is there anything in dmesg after the guest network fails?

Comment 9 Honza Horak 2011-07-21 08:55:09 UTC
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 08:56:15 UTC
Created attachment 514166 [details]
dmesg from physical machine after network crashed

Comment 11 Fedora Admin XMLRPC Client 2012-03-15 17:55:15 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 12 Cole Robinson 2012-05-29 00:08:52 UTC
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.