Bug 596014

Summary: hot add virtio-blk-pci via device_add lead to virtio network lost
Product: Red Hat Enterprise Linux 6 Reporter: juzhang <juzhang>
Component: qemu-kvmAssignee: Alex Williamson <alex.williamson>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: michen, mjenner, mst, tburke, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: qemu-kvm-0.12.1.2-2.78.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-07-08 06:59:44 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: 581963    
Bug Blocks:    

Description juzhang 2010-05-26 06:34:43 UTC 
Description of problem:
hot add virtio-blk-pci via device_add lead to virtio network lost.

Version-Release number of selected component (if applicable):
#uname -r
2.6.32-25.el6.x86_64
#rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.62.el6.x86_64
guest: rhel6.0

How reproducible:


Steps to Reproduce:
1.boot guest
/usr/libexec/qemu-kvm  -no-hpet -usbdevice tablet -rtc-td-hack -m 2G -smp 2 -drive file=/root/zhangjunyi/RHEL-Server-6.0-64-virtio.qcow2,if=virtio,boot=on,id=test,cache=none,werror=stop,rerror=stop -net nic,vlan=0,macaddr=22:11:22:45:66:22,model=virtio -net tap,vlan=0,script=/etc/qemu-ifup -uuid `uuidgen` -cpu qemu64,+sse2 -balloon none -boot c -monitor stdio -vnc :10
2. hot add drive
(qemu) drive_add bus file=/root/zhangjunyi/test1.qcow2,format=qcow2,if=none,id=test1
3. hot add  virtio-blk-pci
(qemu) device_add virtio-blk-pci,drive=test1
  
Actual results:
before step 3, guest's network is ok and can ssh to guest.

ping guest
PING 10.66.83.63 (10.66.83.63) 56(84) bytes of data.
64 bytes from 10.66.83.63: icmp_seq=1 ttl=64 time=1.96 ms
64 bytes from 10.66.83.63: icmp_seq=2 ttl=64 time=0.491 ms

after step 3,guest's network was lost.

ping guest
PING 10.66.83.63 (10.66.83.63) 56(84) bytes of data.
From 10.66.83.199 icmp_seq=1 Destination Host Unreachable
From 10.66.83.199 icmp_seq=2 Destination Host Unreachable
From 10.66.83.199 icmp_seq=3 Destination Host Unreachable

Expected results:
virtio network is not reflected when hot add virtio-blk-pci.

Additional info:
Pleas NOTE:
hot add virtio-blk-pci via device_add only lead to virtio network lost.
for e1000 and rtl8139 are not reflected.
Comment 2 RHEL Program Management 2010-05-28 10:55:37 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 Alex Williamson 2010-06-16 05:20:39 UTC 
Already fixed upstream
Comment 7 juzhang 2010-07-08 06:58:29 UTC 
Verified on qemu-kvm-0.12.1.2-2.91.el6
Because of drive_add was disabled,using __com.redhat_drive_add instead of drive_add.

steps1:

1.boot guest
/usr/libexec/qemu-kvm -m 4G -smp 4 -drive file=/root/zhangjunyi/rhel6.64.qcow2,if=none,id=drive-virtio-disk0,boot=on,cache=none,format=qcow2 -device virtio-blk-pci,bus=pci.0,drive=drive-virtio-disk0,id=virtio-disk0  -device virtio-balloon-pci -cpu qemu64,+sse2,+x2apic -monitor stdio -vnc :10 -qmp tcp:0:4445,server,nowait -drive file=/root/zhangjunyi/boot.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,drive=drive-ide0-1-0 -boot order=dcn,menu=on -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=22:11:22:45:66:97

2. hot add drive
{"execute":"__com.redhat_drive_add", "arguments": {"file":"/root/zhangjunyi/test1.qcow2","format":"qcow2","id":"test1"}}

3.hot add  virtio-blk-pci
{"execute":"device_add","arguments":{"driver":"virtio-blk-pci","drive":"test1","id":"zhang"}}


network is still ok.
Comment 8 juzhang 2010-07-08 06:59:44 UTC 
according to comment7,close this issue.