Red Hat Bugzilla – Bug 697811
Network connection crashes in virtual machine when trying to update
Last modified: 2013-01-09 18:48:47 EST
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
rpm -q libvirt
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
network connection fails, which interrupts update
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.
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?
(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.
Created attachment 513217 [details]
output of "virsh..." for the machine where I've noticed no failure
Created attachment 513218 [details]
output of "virsh..." for the machine where I've noticed two failures
(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.
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 ?
(In reply to comment #6)
> Any error messages in /var/log/libvirt/qemu/$vmname.log ?
There is no error nor warning.
Is there anything in dmesg after the guest network fails?
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.
Created attachment 514166 [details]
dmesg from physical machine after network crashed
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.