Red Hat Bugzilla – Bug 811143
[RHEL6.3 guest] Network can not get the ip after s3 with NetworkManager service start
Last modified: 2015-05-24 20:06:54 EDT
Description of problem:
Similar with bug 807967, suspend guest to mem and wakeup it after 5 minutes. Guest failed to get the IP address. If I stop NetworkManager service, can not reproduce any more.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot a guest (without virtio device to avoid bug 803187)
/usr/libexec/qemu-kvm -M rhel6.3.0 -cpu Conroe -enable-kvm -m 2G -smp 2,sockets=1,cores=2,threads=1 -name rhel6.3 -uuid c1392688-189d-4b8b-a170-a8939dad2d18 -rtc base=localtime,driftfix=slew -drive file=/home/rhel6.3-64.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,werror=stop,rerror=stop,aio=native -device ide-drive,bus=ide.0,unit=1,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device e1000,netdev=hostnet0,id=net0,mac=00:1a:2a:28:18:22,bus=pci.0 -usb -device usb-tablet,id=input0 -boot c -monitor stdio -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -vnc :10 -qmp tcp:0:4444,server,nowait -chardev socket,path=/tmp/qzhang-test,server,nowait,id=isa1 -device isa-serial,chardev=isa1,id=isa-serial1
2. Inside guest:
3. Wait for 5 minutes.
4. Wakeup guest:
Guest failed to get IP address.
Guest should work well and all the devices including NIC device should work.
Stop NetworkManager service and re-test, this issue does not exist.
Update for more clear:
(1) When 'service NetworkManager stop', the guest still has networking because
the 'network' service is up. So in this condition, guest network is always
available. Suspend guest to memory and wakeup it after 5 minutes, guest network
is accessible as well.
(2) When 'NetworkManager' service starts, will hit this bug.
I know this sounds a bit odd, but please confirm that this bug doesn't happen on a non virt (real hardware) rhel6.3 machine (you can probably test this by suspending the host itself).
I have this exact problem on one of my old fedora boxes (a netbook), so this might be a problem unrelated to qemu.
(In reply to comment #3)
> I know this sounds a bit odd, but please confirm that this bug doesn't happen
> on a non virt (real hardware) rhel6.3 machine (you can probably test this by
> suspending the host itself).
> I have this exact problem on one of my old fedora boxes (a netbook), so this
> might be a problem unrelated to qemu.
Just test on host which is installed with the following packages, and this issue does not happen on a host.
install tree: RHEL6.3-20120329.0/
kernel version: 2.6.32-262.el6.x86_64
1. Install the host with the above tree.
2. Check the network. It is available and can ping other host.
And the 'NetworkManager' service is starting.
4. Wait for 8 minutes.
5. Wakeup host by press the power button. The power button is blinking during suspending to mem. And press it to wakeup system.
Result: Host resumes from S3 and comes back to the screen before it suspended.
Wait for few seconds the network will come back.
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Talked with mst, reassign this to me.
I think this is specific to the network adapters -- I believe this doesn't happen with virtio devices, is that correct? If so, please adjust summary to note it only happens with e1000.
I can not reproduce it now on the latest rhel6.4 host even with the same command line in comment 0. Tried all virtio/e1000/rtl8139 nics. Guest can get ip address again after resume with NetworkManager started.
Install tree: RHEL6.4-20121212.1/
OK - so looks like this one got fixed, then!
Amos, might be worthwhile to check recent commits to e1000 device emulation to see what could've caused this.
Thanks for testing again, closing.