Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1065294 - [virtio-win][vioscsi]win7-32 cannot detect the new disk when system_reset guest after hotplug a scsi-hd
Summary: [virtio-win][vioscsi]win7-32 cannot detect the new disk when system_reset gue...
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virtio-win
Version: 8.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.1
Assignee: Vadim Rozenfeld
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1682882
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-14 09:51 UTC by lijin
Modified: 2019-03-16 08:10 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
win7-32 error message screenshot (deleted)
2014-02-14 09:51 UTC, lijin
no flags Details
step2 (deleted)
2014-02-17 10:10 UTC, lijin
no flags Details

Description lijin 2014-02-14 09:51:50 UTC
Created attachment 863189 [details]
win7-32 error message screenshot

Description of problem:
after system_reset guest after hotplug a scsi-hd disk,guest can not detect the hotplugged disk in "Computer".
The new disk can be seen in "disk management",but has no drive letter

Version-Release number of selected component (if applicable):
kernel-3.10.0-86.el7.x86_64
qemu-kvm-rhev-1.5.3-47.el7.x86_64
virtio-win-1.6.8-4.el6.noarch
seabios-1.7.2.2-11.el7.x86_64
guest:en_windows_7_ultimate_with_sp1_x86_dvd_u_677460.iso

How reproducible:
100%

Steps to Reproduce:
1.boot a win7.32 guest with:
/usr/libexec/qemu-kvm -M pc -m 2G -smp 2,cores=2 -drive file=win7-32.qcow2v3,format=qcow2,media=disk,if=none,cache=none,id=drive-blk,serial=blk1 -device virtio-scsi-pci,id=scsi0 -device scsi-hd,bus=scsi0.0,drive=drive-blk,id=ide-blk-pci1,bootindex=1 -rtc base=localtime,clock=host,driftfix=slew -no-kvm-pit-reinjection -name win7-32-scsi -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -usb -device usb-tablet -monitor stdio -spice disable-ticketing,port=5901 -vga qxl -global qxl-vga.revision=3 -netdev tap,id=hostnet1,script=/etc/qemu-ifup,downscript=no -device e1000,netdev=hostnet1,id=net1,mac=00:52:22:16:54:48,bus=pci.0 -cdrom /usr/share/virtio-win/virtio-win.iso

2.hotplug scsi disk with:
(qemu) __com.redhat_drive_add file=data.raw,id=drive
(qemu) device_add virtio-scsi-pci,id=scsi2
(qemu) device_add scsi-hd,drive=drive,id=scsi-disk,bus=scsi2.0

3.initialize and format the new disk 
4.(qemu) system_reset

Actual results:
after step 4,no new disk can be seen in "Computer",it showed in "disk management" with no driver letter,click "change driver letter xxx",guest prompt an error message "The operation failed to complete because the Disk Management console view is not up-to-date. Refresh the view by using the refresh task. If the problem persists close the Disk Management console, then restart Disk Management or restart the computer."(as the attachment)
 
Expected results:
new scsi disk can be seen correctly after hotplug and system_rest 

Additional info:

Comment 2 Ronen Hod 2014-02-16 10:22:55 UTC
I think that a QEMU "system-reset" should keep all the (virtual) hardware exactly as it was prior to the reset, and it seems like reset behaves like restart, so the hardware changes.
I wonder if the issue can be reproduced using Libvirt, since Libvirt should always specify where exactly to locate the hot-plugged hardware.
In any case, scan-for-new-hardware in the guest should solve the problem temporarily.

Comment 3 lijin 2014-02-17 08:54:24 UTC
(In reply to Ronen Hod from comment #2)
> I think that a QEMU "system-reset" should keep all the (virtual) hardware
> exactly as it was prior to the reset, and it seems like reset behaves like
> restart, so the hardware changes.
> I wonder if the issue can be reproduced using Libvirt, since Libvirt should
> always specify where exactly to locate the hot-plugged hardware.
> In any case, scan-for-new-hardware in the guest should solve the problem
> temporarily.

this bug is not the same with https://bugzilla.redhat.com/show_bug.cgi?id=929084
,rescan disks does not solve this problem.
Try a few more times,sometimes this issue also happened while initializing the data disk(attached in qemu command,not hotplugged).

Comment 4 Vadim Rozenfeld 2014-02-17 09:09:06 UTC
(In reply to lijin from comment #3)
> (In reply to Ronen Hod from comment #2)
> > I think that a QEMU "system-reset" should keep all the (virtual) hardware
> > exactly as it was prior to the reset, and it seems like reset behaves like
> > restart, so the hardware changes.
> > I wonder if the issue can be reproduced using Libvirt, since Libvirt should
> > always specify where exactly to locate the hot-plugged hardware.
> > In any case, scan-for-new-hardware in the guest should solve the problem
> > temporarily.
> 
> this bug is not the same with
> https://bugzilla.redhat.com/show_bug.cgi?id=929084
> ,rescan disks does not solve this problem.
> Try a few more times,sometimes this issue also happened while initializing
> the data disk(attached in qemu command,not hotplugged).

Can you please post the output from "info pci" before and after system_reset?
Thanks,
Vadim.

Comment 5 lijin 2014-02-17 10:10:18 UTC
(In reply to Vadim Rozenfeld from comment #4)
> (In reply to lijin from comment #3)
> > (In reply to Ronen Hod from comment #2)
> > > I think that a QEMU "system-reset" should keep all the (virtual) hardware
> > > exactly as it was prior to the reset, and it seems like reset behaves like
> > > restart, so the hardware changes.
> > > I wonder if the issue can be reproduced using Libvirt, since Libvirt should
> > > always specify where exactly to locate the hot-plugged hardware.
> > > In any case, scan-for-new-hardware in the guest should solve the problem
> > > temporarily.
> > 
> > this bug is not the same with
> > https://bugzilla.redhat.com/show_bug.cgi?id=929084
> > ,rescan disks does not solve this problem.
> > Try a few more times,sometimes this issue also happened while initializing
> > the data disk(attached in qemu command,not hotplugged).
> 
> Can you please post the output from "info pci" before and after system_reset?
> Thanks,
> Vadim.

1.hotplug 3 scsi-hd(all disk image were create by "qemu-img create -f raw data.raw 3G")
(qemu) __com.redhat_drive_add file=data1.raw,id=drive1
(qemu) device_add virtio-scsi-pci,id=scsi1
(qemu) device_add scsi-hd,drive=drive1,id=scsi-disk,bus=scsi1.0
(qemu) __com.redhat_drive_add file=data2.raw,id=drive2
(qemu) device_add virtio-scsi-pci,id=scsi2
(qemu) device_add scsi-hd,drive=drive2,id=scsi-disk2,bus=scsi2.0
(qemu) __com.redhat_drive_add file=data3.raw,id=drive3
(qemu) device_add virtio-scsi-pci,id=scsi3
(qemu) device_add scsi-hd,drive=drive3,id=scsi-disk3,bus=scsi3.0
2.initialize three hotplugged disk
3.info pci
4.system_reset
5.info pci

Result:
1.After step 2,only the second disk can be formatted correctly,the first and third disk didinot finish the formatting,both disks get no driver letter and the error messageprompted again(As the attachment "step2").

2.pci info in step 3:
(qemu) info pci
  Bus  0, device   0, function 0:
    Host bridge: PCI device 8086:1237
      id ""
  Bus  0, device   1, function 0:
    ISA bridge: PCI device 8086:7000
      id ""
  Bus  0, device   1, function 1:
    IDE controller: PCI device 8086:7010
      BAR4: I/O at 0xc0c0 [0xc0cf].
      id ""
  Bus  0, device   1, function 2:
    USB controller: PCI device 8086:7020
      IRQ 11.
      BAR4: I/O at 0xc080 [0xc09f].
      id ""
  Bus  0, device   1, function 3:
    Bridge: PCI device 8086:7113
      IRQ 9.
      id ""
  Bus  0, device   2, function 0:
    VGA controller: PCI device 1b36:0100
      IRQ 5.
      BAR0: 32 bit memory at 0xf4000000 [0xf7ffffff].
      BAR1: 32 bit memory at 0xf8000000 [0xfbffffff].
      BAR2: 32 bit memory at 0xfc070000 [0xfc071fff].
      BAR3: I/O at 0xc0a0 [0xc0bf].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
      id ""
  Bus  0, device   3, function 0:
    SCSI controller: PCI device 1af4:1004
      IRQ 10.
      BAR0: I/O at 0xc000 [0xc03f].
      BAR1: 32 bit memory at 0xfc072000 [0xfc072fff].
      id "scsi0"
  Bus  0, device   4, function 0:
    Ethernet controller: PCI device 8086:100e
      IRQ 11.
      BAR0: 32 bit memory at 0xfc040000 [0xfc05ffff].
      BAR1: I/O at 0xc040 [0xc07f].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe].
      id "net1"
  Bus  0, device   5, function 0:
    SCSI controller: PCI device 1af4:1004
      IRQ 11.
      BAR0: I/O at 0xffc0 [0xffff].
      BAR1: 32 bit memory at 0xfebff000 [0xfebfffff].
      id "scsi1"
  Bus  0, device   6, function 0:
    SCSI controller: PCI device 1af4:1004
      IRQ 5.
      BAR0: I/O at 0xff80 [0xffbf].
      BAR1: 32 bit memory at 0xfebfe000 [0xfebfefff].
      id "scsi2"
  Bus  0, device   7, function 0:
    SCSI controller: PCI device 1af4:1004
      IRQ 10.
      BAR0: I/O at 0xff40 [0xff7f].
      BAR1: 32 bit memory at 0xfebfd000 [0xfebfdfff].
      id "scsi3"
(qemu) 

3.pci info in step 5:
(qemu) info pci
  Bus  0, device   0, function 0:
    Host bridge: PCI device 8086:1237
      id ""
  Bus  0, device   1, function 0:
    ISA bridge: PCI device 8086:7000
      id ""
  Bus  0, device   1, function 1:
    IDE controller: PCI device 8086:7010
      BAR4: I/O at 0xc180 [0xc18f].
      id ""
  Bus  0, device   1, function 2:
    USB controller: PCI device 8086:7020
      IRQ 11.
      BAR4: I/O at 0xc140 [0xc15f].
      id ""
  Bus  0, device   1, function 3:
    Bridge: PCI device 8086:7113
      IRQ 9.
      id ""
  Bus  0, device   2, function 0:
    VGA controller: PCI device 1b36:0100
      IRQ 5.
      BAR0: 32 bit memory at 0xf4000000 [0xf7ffffff].
      BAR1: 32 bit memory at 0xf8000000 [0xfbffffff].
      BAR2: 32 bit memory at 0xfc070000 [0xfc071fff].
      BAR3: I/O at 0xc160 [0xc17f].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
      id ""
  Bus  0, device   3, function 0:
    SCSI controller: PCI device 1af4:1004
      IRQ 10.
      BAR0: I/O at 0xc000 [0xc03f].
      BAR1: 32 bit memory at 0xfc072000 [0xfc072fff].
      id "scsi0"
  Bus  0, device   4, function 0:
    Ethernet controller: PCI device 8086:100e
      IRQ 11.
      BAR0: 32 bit memory at 0xfc040000 [0xfc05ffff].
      BAR1: I/O at 0xc040 [0xc07f].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe].
      id "net1"
  Bus  0, device   5, function 0:
    SCSI controller: PCI device 1af4:1004
      IRQ 11.
      BAR0: I/O at 0xc080 [0xc0bf].
      BAR1: 32 bit memory at 0xfc073000 [0xfc073fff].
      id "scsi1"
  Bus  0, device   6, function 0:
    SCSI controller: PCI device 1af4:1004
      IRQ 5.
      BAR0: I/O at 0xc0c0 [0xc0ff].
      BAR1: 32 bit memory at 0xfc074000 [0xfc074fff].
      id "scsi2"
  Bus  0, device   7, function 0:
    SCSI controller: PCI device 1af4:1004
      IRQ 10.
      BAR0: I/O at 0xc100 [0xc13f].
      BAR1: 32 bit memory at 0xfc075000 [0xfc075fff].
      id "scsi3"
(qemu) 

4.after step 5,only one data disk can be seen in "Computer",disk management keeps state as step2.

Comment 6 lijin 2014-02-17 10:10:52 UTC
Created attachment 864050 [details]
step2

Comment 12 Peixiu Hou 2018-07-12 09:33:32 UTC
1. Reproduced this issue on rhel7.6 host, with virtio-win-1.6.8-4.el6.noarch on win2008-r2 guest.

Steps as comment#5, hot-pluged 3 disks, then initialize and format three hotplugged disks, all normally till there, do system_reset next, there 2 disks shown normally, but the third disk not get the disk letter, try to change its disk letter, report error message as attachment in this bug.

Checked device management, virtio-scsi device shown as unknown device.

2. Also reproduced this issue with virtio-win-prewhql-156 on win2008-r2, hit the same situation with upper result 1.

Best Regards~
Peixiu

Comment 13 Peixiu Hou 2018-07-12 09:40:10 UTC
Used other version:
kernel-3.10.0-916.el7.x86_64
qemu-img-rhev-2.12.0-5.el7.x86_64
seabios-1.10.2-3.el7_4.1.x86_64

Thanks~
Peixiu


Note You need to log in before you can comment on or make changes to this bug.