Red Hat Bugzilla – Bug 543359
virtio nic hotplug (pci_add) causes the original nic failure
Last modified: 2013-01-09 17:05:14 EST
Description of problem: start vm with _non-virtio nic_, for example e1000 or rtl8139. after adding a new virtio nic by pci_add command in qemu command line, the original nic stops responsing, do not pong, and cannot get address by dhclient method. Version-Release number of selected component (if applicable): kvm-83-105.el5_4.10(z) and kvm-83-105.el5_4.13 and kvm-83-132.el5 How reproducible: 100% Steps to Reproduce: 1. start vm by: /usr/libexec/qemu-kvm -name 'vm0' -monitor stdio file=./Fedora-11-64.qcow2,media=disk,if=ide,cache=off,boot=on -net nic,vlan=0,macaddr=00:11:22:33:D2:00,model=e1000 -net tap,vlan=0,ifname=e1000_0_0SSw5,script=/etc/qemu-ifup-switch,downscript=no -m 2048 -usbdevice tablet -rtc-td-hack -no-hpet -no-kvm-pit-reinjection -smp 1 -vnc :0 2. hot_add virtio nic by "pci_add pci_addr=auto nic model=virtio" into the qemu command line. 3. check the working status of the original nic, by ping, ssh, or telnet, or "dhclient eth_orig" Actual results: the original nic stops working. Expected results: the original nic works good persistently. Additional info: 1. if starting vm with virtio_nic, hotplug works good. 2. dmesg from guest(Fedora11) after pci_add command: (eth0 is the name of newly added nic.) -- pci 0000:00:05.0: reg 10 io port: [0x00-0x1f] pci 0000:00:02.0: BAR 6: bogus alignment [0x0-0x0] flags 0x2 decode_hpp: Could not get hotplug parameters. Use defaults virtio-pci 0000:00:05.0: enabling device (0000 -> 0001) ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10 virtio-pci 0000:00:05.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, high) -> IRQ 10 eth0: bad gso type 29. eth0: bad gso type 29. eth0: bad gso type 29. eth0: no IPv6 routers present -- both nics do not work after pci_add, and after rebooting, the original nic cannot get ip address. 3. tested guest: MS Windows2008/vista/2003 - 64bit Fedora-11 - 64bit 4. kernel: 2.6.18-164.2.1.el5 (kvm-83-105.el5_4.10(z)) 2.6.18-175.el5 (kvm-83-132.el5)
I just tried this with kvm-83-164.el5 and it works fine. Can you re-test?
(In reply to comment #3) > I just tried this with kvm-83-164.el5 and it works fine. Can you re-test? I can still reproduce it, on # rpm -q kvm kvm-83-164.el5_5.23 # uname -r 2.6.18-194.14.1.el5 Guest RHEL-Server-6.0-64 dmesg in guest: -- pci 0000:00:06.0: reg 10 io port: [0x00-0x1f] pci 0000:00:02.0: BAR 6: bogus alignment [0x0-0x0] flags 0x2 pci 0000:00:00.0: no hotplug settings from platform pci 0000:00:00.0: using default PCI settings pci 0000:00:01.0: no hotplug settings from platform pci 0000:00:01.0: using default PCI settings ata_piix 0000:00:01.1: no hotplug settings from platform ata_piix 0000:00:01.1: using default PCI settings uhci_hcd 0000:00:01.2: no hotplug settings from platform uhci_hcd 0000:00:01.2: using default PCI settings piix4_smbus 0000:00:01.3: no hotplug settings from platform piix4_smbus 0000:00:01.3: using default PCI settings pci 0000:00:02.0: no hotplug settings from platform pci 0000:00:02.0: using default PCI settings 8139cp 0000:00:03.0: no hotplug settings from platform 8139cp 0000:00:03.0: using default PCI settings virtio-pci 0000:00:04.0: no hotplug settings from platform virtio-pci 0000:00:04.0: using default PCI settings virtio-pci 0000:00:05.0: no hotplug settings from platform virtio-pci 0000:00:05.0: using default PCI settings pci 0000:00:06.0: no hotplug settings from platform pci 0000:00:06.0: using default PCI settings virtio-pci 0000:00:06.0: enabling device (0000 -> 0001) ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 virtio-pci 0000:00:06.0: PCI INT A -> Link[LNKB] -> GSI 10 (level, high) -> IRQ 10 udev: renamed network interface eth0 to eth3 bad partial csum: csum=4352/13090 len=32 bad partial csum: csum=4352/13090 len=32 eth3: no IPv6 routers present bad partial csum: csum=4352/13090 len=32 bad partial csum: csum=4352/13090 len=32 bad partial csum: csum=4352/13090 len=32 bad partial csum: csum=4352/13090 len=32 bad partial csum: csum=4352/13090 len=32 bad partial csum: csum=4352/13090 len=32 bad partial csum: csum=4352/13090 len=32 pci info after hotplug: (qemu) info pci Bus 0, device 0, function 0: Host bridge: PCI device 8086:1237 Bus 0, device 1, function 0: ISA bridge: PCI device 8086:7000 Bus 0, device 1, function 1: IDE controller: PCI device 8086:7010 BAR4: I/O at 0xc000 [0xc00f]. Bus 0, device 1, function 2: USB controller: PCI device 8086:7020 IRQ 11. BAR4: I/O at 0xc020 [0xc03f]. Bus 0, device 1, function 3: Bridge: PCI device 8086:7113 IRQ 9. Bus 0, device 2, function 0: VGA controller: PCI device 1013:00b8 BAR0: 32 bit memory at 0xc2000000 [0xc3ffffff]. BAR1: 32 bit memory at 0xc4000000 [0xc4000fff]. Bus 0, device 3, function 0: Ethernet controller: PCI device 10ec:8139 IRQ 11. BAR0: I/O at 0xc100 [0xc1ff]. BAR1: 32 bit memory at 0xc4001000 [0xc40010ff]. Bus 0, device 4, function 0: SCSI controller: PCI device 1af4:1001 IRQ 11. BAR0: I/O at 0xc200 [0xc23f]. Bus 0, device 5, function 0: RAM controller: PCI device 1af4:1002 IRQ 10. BAR0: I/O at 0xc240 [0xc25f]. Bus 0, device 6, function 0: Ethernet controller: PCI device 1af4:1000 IRQ 0. BAR0: I/O at 0x1000 [0x101f].
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release.
Can you please re-test this? Something like this should've been caught by other tests as well, so I'm wondering if this is related to the environment you have. If you can reproduce it with the latest qemu-kvm and guest kernels, can you also let us know if doing this via libvirt reproduces the issue?
(In reply to comment #9) > Can you please re-test this? Something like this should've been caught by > other tests as well, so I'm wondering if this is related to the environment you > have. If you can reproduce it with the latest qemu-kvm and guest kernels, can > you also let us know if doing this via libvirt reproduces the issue? tried with the following env, can NOT reproduce any more. both nics are working good. # rpm -q kvm kvm-83-224.el5 # uname -r 2.6.18-238.1.1.el5 /usr/libexec/qemu-kvm -name 'vm0' -monitor stdio -drive file='RHEL-Server-6.0-64.qcow2',index=0,media=disk,if=ide,cache=off,boot=on,format=qcow2 -net nic,vlan=0,macaddr=00:11:22:33:D2:00,model=e1000 -net tap,vlan=0,ifname=e1000_0_0SSw5,script=./qemu-ifup-switch,downscript=no -m 2048 -usbdevice tablet -rtc-td-hack -no-hpet -no-kvm-pit-reinjection -smp 1 -vnc :0 (qemu) pci_add pci_addr=auto nic model=virtio
Thanks for testing this again. Closing.