virtio-win-prewhql-0.1-29 is quite old and I was unable to reproduce with virtio-win-prewhql-0.1-64. It was possible to unplug the device.

(In reply to Gal Hammer from comment #2)
> virtio-win-prewhql-0.1-29 is quite old and I was unable to reproduce with
> virtio-win-prewhql-0.1-64. It was possible to unplug the device.

Sorry,my mistake,the version is virtio-win-prewhql-0.1-59,instead of virtio-win-prewhql-0.1-29.

And retest this issue in build 59 && build 64,this issue still exist;
But if I modify the host send script:let host sleep 1 second to execute next date transfer,the virtio-serial-pci can be removed successfully both in build59 and build 64.

Sounds it seems like bug949897:comment3 and comment4,https://bugzilla.redhat.com/show_bug.cgi?id=949897,is this behavior also by design?

Based on comment #3 ,Move status to assigned

(In reply to lijin from comment #3)

> Sounds it seems like bug949897:comment3 and
> comment4,https://bugzilla.redhat.com/show_bug.cgi?id=949897,is this behavior
> also by design?

No. If you remove a device from the guest the driver should handle the removal and exit.

lijin,pls retest it according to comment #5

Reproduced this issue on virtio-win-prewhql59 
verified this issue on virtio-win-1.6.5-5

Steps:
1.boot a win7-32 guest:
/usr/libexec/qemu-kvm -drive file=win7-32.qcow2,if=none,cache=writethrough,media=disk,format=qcow2,id=disk1 -device ide-drive,id=ide0-0-0,drive=disk1,bootindex=0 -device virtio-serial-pci,id=virtio-serial0,max_ports=31,bus=pci.0 -chardev socket,path=/tmp/tt0,server,nowait,id=chardev0 -device virtserialport,chardev=chardev0,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port0 -chardev socket,path=/tmp/tt1,server,nowait,id=chardev1 -device virtserialport,chardev=chardev1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1 -monitor stdio -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:06:7f:f9:56,bus=pci.0,addr=0x4 -boot menu=on -spice port=5900,disable-ticketing -vga qxl -chardev file,path=/root/console.log,id=serial1 -device isa-serial,chardev=serial1,id=s1 -usb -device usb-tablet,id=tablet1 -M rhel6.4.0 -smp 2,cores=2,threads=1,sockets=1 -m 3G -enable-kvm -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -cdrom /usr/share/virtio-win/virtio-win-1.6.5.iso

2.transfer data between host and guest in different loops at the same time:
2.1)transfer data from host to guest in a loop(200);
guest:
cmd:for /l %i in (1,1,200) do python VirtIoChannel_guest_recieve.py com.redhat.rhevm.vdsm

host:sh host-to-guest.sh 
cat host-to-guest.sh 
for ((j=1;j<=200;j++));
do
python serial-host-send.py /tmp/tt0;
done;


2.2)transfer data from host to guest in a loop(1000);
host:sh guest-to-host.sh
cat guest-to-host.sh 
for ((i=1;i<=1000;i++));
d0
python serial-host-receive.py /tmp/tt1;
done

guest:cmd:for /l %i in (1,1,200) do python VirtIoChannel_Guest_send.py com.redhat.rhevm.vdsm1


3.when host-to-guest.sh script finished,hotunplug virtio-serial-pci:
(qemu) device_del virtio-serial0 
or 
click “Safely remove Hardware and Eject Media” in the lower right corner,then click "Eject Virtio-serial Driver"

Actual Results:
on both build 59 and virito-win-1.6.5-5,windows prompt an error window as the attachment.

Based on above ,this issue has not been fixed.

Note:
if I add sleep 1 command to script host-to-guest.sh,neither build59 nor virtio-win-1.6.5-5 hit this issue.
cat host-to-guest-new.sh 
for ((j=1;j<=200;j++));
do
python serial-host-send.py /tmp/tt0;
sleep 1;
done;

Commit 3d6db65653029bba3c56f480397929d3517a4d22 seems to handle this bug as well.

*** Bug 967400 has been marked as a duplicate of this bug. ***

Reproduced this issue on virtio-win-prewhql-0.1-59
Verified this issue on virtio-win-prewhql-0.1-67

steps same as comment #0

Actual Results:
both on virtio-win-prewhql-0.1-59 and virtio-win-prewhql-0.1-67,cannot hotunplug virtio-serial-pci while one port is transferring data and the other has finished transfering.guest still prompt the same warning as the attachment displays.

Based on above ,this issue has not been fixed.

Hi, Gal

QE retested this issue in win7-32 with virtio-win-prewhql-0.1-67 on rhel6.5 host. There is no problem for "continuous hotunplug serial-bus/hotplug serial-bus&virtserialport in a loop during virtio serial in use". "continuous hotunplug/plug virtserialport in a loop during transferring data from guest to host" is also pass without error, But "continuous hotunplug/plug virtserialport in a loop during transferring data from host to guest" still hit this issue. QE found some other issue about "hibernate during virtio-serial in use", The following is my test and summary.

Package version:
  kernel-2.6.32-411.el6.x86_64
  qemu-kvm-rhev-0.12.1.2-2.386.el6.x86_64
  virtio-win-prewhql-0.1.67
  spice-server-0.12.4-2.el6.x86_64  
  seabios-0.6.1.2-28.el6.x86_64
  vgabios-0.6b-3.7.el6.noarch

Steps:

1.Boot guest with CLI:
/usr/libexec/qemu-kvm -M rhel6.5.0 -m 2G -smp 2,cores=2 -cpu cpu64-rhel6,+x2apic,family=0xf -usb -device usb-tablet -drive file=win7-32.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,rerror=stop,werror=stop,cache=none -device ide-drive,drive=drive-ide0-0-0,id=ide0-0-0-0,bootindex=1 -netdev tap,sndbuf=0,id=hostnet0,script=/etc/qemu-ifup,downscript=no -device e1000,netdev=hostnet0,mac=00:43:42:a1:22:31,id=net0 -uuid a8b4c1e5-3634-4426-a23d-c7b6288faa48 -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/monitor-win7-32-serial-67,server,nowait -mon chardev=111a,mode=readline -name win7-32-serial-67 -spice port=5931,disable-ticketing -vga qxl -rtc base=localtime,clock=host,driftfix=slew -device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev socket,id=channel0,path=/tmp/port0,server,nowait -chardev socket,id=channel1,path=/tmp/port1,server,nowait -device virtserialport,chardev=channel0,name=com.redhat.rhevm.vdsm0,bus=virtio-serial0.0,id=port0,nr=1 -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1,nr=2 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -monitor stdio

2 transfer date:
 2.1 transferring date from guest to host for port0
  on host:running loop-guest-send.sh
   for((i=1;i<=30000000;i++))
   do
     python serial-host-receive.py  /tmp/port0;
   done
  on guest:running script
   for /l %i in (1,1,30000000)do python VirtIoChannel_Guest_send.py com.redhat.rhevm.vdsm0
 2.2 transferring data from host to guest for port1
  on guest: running script
   for  /l %i in (1,1,1000)do python VirtIoChannel_guest_recieve.py com.redhat.rhevm.vdsm1
  on host:running loop-guest-recieve.sh
   for((i=1;i<=100;i++))
   do
     python serial-host-send.py /tmp/port1;
     sleep 3;
   done

3 Hotunplug/plug and hibernate test: 
 3.1 Continuous hotunplug/plug virtserialport in a loop during transferring data from guest to host
 3.2 Continuous hotunplug serial-bus/hotplug serial-bus&virtserialport in a loop during transferring data from guest to host
 3.3 Continuous hotunplug/plug virtserialport in a loop during transferring data from host to guest
 3.4 Continuous hotunplug serial-bus/hotplug serial-bus&virtserialport in a loop during transferring data from host to guest
 3.5 hibernate guest(s4)& resume during transferring data from guest to host
 3.6 hibernate guest(s4)& resume during transferring data from host to guest

Test results:
 
 Test 3.1&3.2
    result:The original scripts of both sides could still work. we could see del/add of port0 in "Devices and Printers". Guest and qemu monitor did not report any error.
 
 Test 3.3
   (1).Doing hotunplug virtserialport: (qemu)device_del port1 
   The host qemu monitor show error "(qemu) qemu-kvm: virtio-serial-bus: Unexpected port id 2 for device virtio-serial0.0",the original guest script is frozen and port1 disappeared from "Devices and Printers". 
   (2).Doing hotplug port1:(qemu) device_add virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1,nr=2
   The host qemu monitor show error "(qemu) qemu-kvm: virtio-serial-bus: Guest failure in adding port 2 for device virtio-serial0.0" and port1 still disappeared from "Devices and Printers".
   Note: If kill the original guest script after step(2), could hotplug port1.

 Test3.4
   (1).Hotunplug serial-bus: (qemu)device_del virtio-serial
   Could hotunplug serial-bus successfully, There is no error reported on both side.The two ports disappeared from "Devices and Printers".
   (2)Hotplug serial-bus&virtserialport
   Guest could receive data from host again(both scripts are original scripts).
  
 Test3.5.
    Guest could resume without BSOD
    The original host script is frozen, could not receive data from guest. if Kill it and restart again, host could receive data from the original guest script.
    
 Test3.6
    Test result:
    Guest could resume without BSOD
    The original guest script is frozen, could not receive data from host. if Kill it and restart again, guest could receive data from the original host script.

(In reply to guo jiang from comment #11)
> Hi, Gal
> 
> QE retested this issue in win7-32 with virtio-win-prewhql-0.1-67 on rhel6.5
> host. There is no problem for "continuous hotunplug serial-bus/hotplug
> serial-bus&virtserialport in a loop during virtio serial in use".
> "continuous hotunplug/plug virtserialport in a loop during transferring data
> from guest to host" is also pass without error, But "continuous
> hotunplug/plug virtserialport in a loop during transferring data from host
> to guest" still hit this issue. QE found some other issue about "hibernate
> during virtio-serial in use", The following is my test and summary.
> 
> 
Pls report new bugs if you find new issue and do not change bug status unless you verify it .

Based on comment #10.Re-Assigned this issue

Hi Gal,

   Windows 2012 guest has similar issue via build 67 ,the virtio-serial-pci cannot be removed from the guest while data is transferring via those ports ride on the bus.A minor difference,there wasn't any warning message in windows 2012 guest when try to remove the bus.
   Any issues please let me know,thanks in advance.

Best Regards,
Min

A simpler scenario to reproduce this bug:

1. Run a VM with one virtio-serial port.
2. On the guest start the listener (VirtIoChannel_guest_recieve.py).
3. On the host connect to the virtio's char device (for example /tmp/vport0) but do not send anything. I've used the "nc -U /tmp/vport0".
4. Remove the virtio-serial port.
5. Add the virtio-serial port.

A patch was posted and is waiting for a review.

Please note that the script which runs on the guest won't be able to recover after the device is restored. It needs to close and re-open the virtio port.

commit bc552e5619a976ebce666f2438f769925a3856e3

Reproduced this issue on virtio-win-prewhql-59
Retest this issue on virtio-win-prewhql-68

steps same as comment #14

Actual Results:
both on virtio-win-prewhql-59 and virtio-win-prewhql-68,guest can remove the virtioserialport correctly,but still cannot remove the virtio-serial-pci,it prompts the warning as the attachment.

Based on above ,this issue has not been fixed.

I only tested (and fixed) suprise removal of the ports.

I was able to reproduce the error message when the virtio-serial device is removed and I'm working on a solution.

Moving back to QE after clarifying this issue with Michael Tsirkin.

QEMU emulates a PCI bus which includes an electro-mechanical lock. The mean that a request to remove a device (monitor's command "device_del") is forwarded to the guest and doesn't handled by QEMU itself. In this case, where the serial port is in use, Windows refuse to eject the device and notify the user.

(In reply to Gal Hammer from comment #18)
> Moving back to QE after clarifying this issue with Michael Tsirkin.
> 
> QEMU emulates a PCI bus which includes an electro-mechanical lock. The mean
> that a request to remove a device (monitor's command "device_del") is
> forwarded to the guest and doesn't handled by QEMU itself. In this case,
> where the serial port is in use, Windows refuse to eject the device and
> notify the user.

Hi, Gal 

QE tried netkvm driver ,hit not hit this issue .Does it control by driver ?

(In reply to Mike Cao from comment #19)
> (In reply to Gal Hammer from comment #18)
> > Moving back to QE after clarifying this issue with Michael Tsirkin.
> > 
> > QEMU emulates a PCI bus which includes an electro-mechanical lock. The mean
> > that a request to remove a device (monitor's command "device_del") is
> > forwarded to the guest and doesn't handled by QEMU itself. In this case,
> > where the serial port is in use, Windows refuse to eject the device and
> > notify the user.
> 
> Hi, Gal 
> 
> QE tried netkvm driver ,hit not hit this issue .Does it control by driver ?

The driver can tell Windows that it support a surprise-removal. I assume that this will change the behavior that I described earlier.

Move status to VERIFIED based on comment #18 .Will report new bug to track it