Bug 599460

Summary: virtio nic is hotpluged when hotplug rtl8139 nic to guest
Product: Red Hat Enterprise Linux 6 Reporter: Suqin Huang <shuang>
Component: qemu-kvmAssignee: Amit Shah <amit.shah>
Status: CLOSED WORKSFORME QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: akong, ehabkost, gyue, jkachuck, mjenner, ndai, qzhang, syeghiay, tao, tburke, virt-maint
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: qemu-kvm-0.12.1.2-2.76.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-05 05:36:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 589859    

Description Suqin Huang 2010-06-03 09:56:35 UTC
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:
qemu-kvm-0.12.1.2-2.68.el6.x86_64

Steps to Reproduce:
1. CLI:
/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/qemu -name 'vm1' -monitor tcp:0:6001,server,nowait -drive file=/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/images/winXP-32-virtio.qcow2,if=virtio,cache=none,boot=on -net nic,vlan=0,model=virtio,macaddr=02:30:0D:26:d9:6b -net tap,vlan=0,ifname=virtio_0_6001,script=/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/scripts/qemu-ifup-switch,downscript=no,vhost=on -m 4096 -smp 2 -drive file=/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/isos/windows/winutils.iso,index=2,media=cdrom -soundhw ac97 -redir tcp:5000::22 -vnc :0 -usbdevice tablet -rtc-td-hack -no-hpet -cpu qemu64,+sse2 -no-kvm-pit-reinjection -serial unix:/tmp/serial-20100602-222813-gjtn,server,nowait

2. Sending monitor command: pci_add pci_addr=auto nic model=rtl8139

3. info network 
VLAN 0 devices:
  tap.0: ifname=6001,script=/etc/qemu-ifup,downscript=no
  virtio-net-pci.0: model=virtio-net-pci,macaddr=02:30:0d:26:d9:6b
  virtio-net-pci.1: model=virtio-net-pci,macaddr=02:30:0d:26:d9:6b

  
Actual results:


Expected results:


Additional info:
1. guest: winXP-32

Comment 2 RHEL Program Management 2010-06-07 15:58:01 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Amos Kong 2010-06-08 10:45:20 UTC
This bug also exists when using other guest(both Linux and Windows)

And guest could not identify the added device.
check pci device cmd:
linux)# lspci
windows)# systeminfo

Comment 4 Dor Laor 2010-06-08 12:44:56 UTC
Does it happen when you're using QMP too?

Comment 5 Amit Shah 2010-06-08 13:16:14 UTC
Please use device_add. pci_add is the older way of doing it, it should be removed from the RHEL6 code.

Comment 7 Amit Shah 2010-06-09 05:00:25 UTC
*** Bug 589859 has been marked as a duplicate of this bug. ***

Comment 10 Qunfang Zhang 2010-06-12 03:37:39 UTC
Verified on qemu-kvm-0.12.1.2-2.73.el6, passed.

(qemu) info network 
VLAN 0 devices:
  tap.0: ifname=rtl8139_1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
  rtl8139.0: model=rtl8139,macaddr=00:1a:4e:9f:0b:6a
Devices not on any VLAN:

(qemu) pci_add pci_addr=auto nic
OK domain 0, bus 0, slot 4, function 0
(qemu) info network 
VLAN 0 devices:
  tap.0: ifname=rtl8139_1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
  rtl8139.0: model=rtl8139,macaddr=00:1a:4e:9f:0b:6a
  rtl8139.1: model=rtl8139,macaddr=52:54:00:12:34:57
Devices not on any VLAN:

(qemu) pci_add pci_addr=auto nic vlan=2,macaddr=00:1a:4e:9f:0b:6c,model=e1000
OK domain 0, bus 0, slot 5, function 0
(qemu) 
(qemu) 
(qemu) info network 
VLAN 0 devices:
  tap.0: ifname=rtl8139_1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
  rtl8139.0: model=rtl8139,macaddr=00:1a:4e:9f:0b:6a
  rtl8139.1: model=rtl8139,macaddr=52:54:00:12:34:57
VLAN 2 devices:
  e1000.0: model=e1000,macaddr=00:1a:4e:9f:0b:6c

(qemu) device_add rtl8139,mac=10:20:1a:4a:10:8f,vlan=3
(qemu) info network 
VLAN 0 devices:
  tap.0: ifname=rtl8139_1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
  rtl8139.0: model=rtl8139,macaddr=00:1a:4e:9f:0b:6a
  rtl8139.1: model=rtl8139,macaddr=52:54:00:12:34:57
VLAN 2 devices:
  e1000.0: model=e1000,macaddr=00:1a:4e:9f:0b:6c
VLAN 3 devices:
  rtl8139.2: model=rtl8139,macaddr=10:20:1a:4a:10:8f

Comment 11 Qunfang Zhang 2010-06-12 05:26:46 UTC
I will change the status back from close because there's not an available tree including qemu-kvm-0.12.1.2-2.73.el6.

Comment 12 Eduardo Habkost 2010-06-15 19:08:00 UTC
Original fix had an issue and an additional fix was submitted. Reopening.

Comment 16 Amit Shah 2010-06-24 13:55:06 UTC
*** Bug 607621 has been marked as a duplicate of this bug. ***

Comment 18 Qunfang Zhang 2010-07-02 07:13:42 UTC
Close the bug according to Comment 10.

Comment 19 Issue Tracker 2010-08-04 14:41:27 UTC
Event posted on 07-27-2010 12:54pm EDT by Glen Johnson

------- Comment From anantyog.com 2010-07-27 12:44 EDT-------
This problem is reproducible with 'device_add' and without using vlans
too,
Step followed to recreate the issue
1)started the guest with net "user" interface
/usr/libexec/qemu-kvm -drive file=/root/sdb/images/win7-32.qcow2 -smp 2 
-m 6144 --monitor stdio -net nic,model=virtio,netdev=kuser1 -netdev
user,id=kuser1  -vnc :10

2)Hotpluged   a "rtl8139" card using the commands below
(qemu) netdev_add tap,id=tap1,script=br
(qemu) device_add rtl8139,netdev=tap1
Hotpluged "rtl8139" was not able to get ip from the dhcp server

3)Hotpluged a "e1000" card using the commands below
(qemu) netdev_add tap,id=tap2,script=br
(qemu) device_add e1000,netdev=tap2
which results in error "device cannot start(code 10) in windows device
manager.

I tried hotpluging using virsh, using both "default" network and bridge
interface.
command used to hotplug the network device was :"attach-device win7
attach1.xml"

steps and xml files used are below
1)default network
<interface type='network'>
<source network='default'/>
<mac address='52:54:00:72:51:2e'/>
<model type='virtio'/>
</interface>

2)bridge network
<interface type='bridge'>
<source bridge='kvmbr0'/>
<model type='e1000'/>
</interface>

The error still occurred with virsh, there was no change in results. Only
hotplugging of "virtio" nic seems to work.

Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech

This event sent from IssueTracker by jkachuck 
 issue 910133

Comment 20 Issue Tracker 2010-08-04 14:41:31 UTC
Event posted on 07-29-2010 06:54am EDT by Glen Johnson

File uploaded:
sosreport-anantyogin.ibm.com.63594-20100729104344-7d62.tar.xz

This event sent from IssueTracker by jkachuck 
 issue 910133
it_file 911153

Comment 21 Issue Tracker 2010-08-04 14:41:33 UTC
Event posted on 07-29-2010 06:54am EDT by Glen Johnson

<cde:attachment>
Comment on attachment:
sosreport-anantyogin.ibm.com.63594-20100729104344-7d62.tar.xz

------- Comment on attachment From anantyog.com 2010-07-29 06:40
EDT-------


RHEL Kernel version: 
Linux phx1.in.ibm.com 2.6.32-44.el6.x86_64 #1 SMP Wed Jul 7 15:47:50 EDT
2010
x86_64 x86_64 x86_64 GNU/Linux

Qemu version:
QEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2), Copyright (c)
2003-2008
Fabrice Bellard

KVM version: 
filename:      
/lib/modules/2.6.32-44.el6.x86_64/kernel/arch/x86/kvm/kvm.ko
license:        GPL
author:         Qumranet
srcversion:     1028E7AE30746E420FE4092
depends:        
vermagic:       2.6.32-44.el6.x86_64 SMP mod_unload modversions 
parm:           oos_shadow:bool
parm:           ignore_msrs:bool
</cde:attachment>


This event sent from IssueTracker by jkachuck 
 issue 910133

Comment 22 Issue Tracker 2010-08-04 14:41:36 UTC
Event posted on 07-29-2010 10:18am EDT by jkachuck

Hello,
If you start the vm with "-net none" does it correct this issue?

Thank You
Joe Kachuck

Internal Status set to 'Waiting on Customer'
Status set to: Waiting on Client

This event sent from IssueTracker by jkachuck 
 issue 910133

Comment 23 Issue Tracker 2010-08-04 14:41:38 UTC
Event posted on 08-04-2010 07:02am EDT by Glen Johnson

------- Comment From anantyog.com 2010-08-04 06:59 EDT-------
There was no change in results when starting VM with -net none. The bug
still occurs.

Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech

This event sent from IssueTracker by jkachuck 
 issue 910133

Comment 24 Dor Laor 2010-08-04 22:41:33 UTC
What's the qemu version that you use?

A new BZ 607611 is soon to be build and probably solve it.

Comment 25 Amit Shah 2010-08-05 05:36:12 UTC
I just checked that the fix for bug 607611 does fix this issue.

This issue was separate for the one that this bug was opened for, which was hot-plugging of a particular nic card got a different nic card hotplugged. So I'll close this bug as 'worksforme' and you can use bug 607611 to track the problem of hotplugged nic not working in guests.

Comment 26 Issue Tracker 2010-08-24 18:14:29 UTC
Event posted on 08-24-2010 11:05am EDT by Glen Johnson

------- Comment From anantyog.com 2010-08-24 10:57 EDT-------
The bug does not occur with Rhel6 snap12.

Thanks
yogi


This event sent from IssueTracker by jkachuck 
 issue 910133