RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 811841 - [virtio-win][viostor] Resume failed after S4 after hot-pluging/unpluging virtio block device.
Summary: [virtio-win][viostor] Resume failed after S4 after hot-pluging/unpluging virt...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virtio-win
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 7.0
Assignee: Vadim Rozenfeld
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 846202 Virt-S3/S4-7.0
TreeView+ depends on / blocked
 
Reported: 2012-04-12 05:38 UTC by dawu
Modified: 2014-08-14 16:24 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 846202 (view as bug list)
Environment:
Last Closed: 2014-08-14 16:24:33 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
win7-32-S4AfterHotUnplugOrPlug-Fail1.png (20.11 KB, image/png)
2012-04-12 05:38 UTC, dawu 		no flags Details
win7-32-S4AfterHotUnplugOrPlug-Fail2 (13.78 KB, image/png)
2012-04-12 05:38 UTC, dawu 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 846202 0 high CLOSED [virtio-win][scsi] Resume failed after S4 after hot-pluging/unpluging virtio scsi device. 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 847226 0 unspecified CLOSED [virtio-win][viostor]Guest 2008-32bit BSOD during resume from s4 after hot plug virtio block disk 2021-02-22 00:41:40 UTC

Internal Links: 846202 847226

Description dawu 2012-04-12 05:38:04 UTC 
Created attachment 576948 [details]
win7-32-S4AfterHotUnplugOrPlug-Fail1.png

Description of problem:
S4 after hot-plug/unplug virtio block device on win7-32, resume failed after S4.

Version-Release number of selected component (if applicable):
kernel-2.6.32-259.el6.x86_64
qemu-kvm-0.12.1.2-2.270.el6.x86_64
virtio-win-rewhql-0.1-25
seabios-0.6.1.2-16.el6.x86_64 

How reproducible:
always

Steps to Reproduce:
1.Start win7-32 guest with CLI:
/usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic,family=0xf -usb -device usb-tablet -drive file=win7-32-blk-fun.raw,format=raw,if=none,id=drive-virtio0,boot=on,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio0,id=virtio-blk-pci0,bootindex=1 -netdev tap,sndbuf=0,id=hostnet0,script=/etc/qemu-ifup0,downscript=no -device e1000,netdev=hostnet0,mac=00:10:1a:01:78:26,bus=pci.0,addr=0x4  -uuid b35f00e9-c93d-4c14-883e-0451a4331d2c -rtc base=localtime,clock=host,driftfix=slew -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/win7-32,server,nowait -mon chardev=111a,mode=readline -monitor stdio  -spice disable-ticketing,port=5931 -vga qxl -drive file=disk1.raw,if=none,id=drive-virtio1,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio1,id=virtio-blk-pci1

2.Hot unplug virtio-blk-pci1 with command from qemu:
  (qemu) device_del virtio-blk-pci1

3.S4 after hot-unplug complete.
  
Actual results:
 Resume failed after S4,please refer to the attached screens for details. (win7-32-S4AfterHotUnplugOrPlug-Fail1.png and win7-32-S4AfterHotUnplugOrPlug-Fail2.png)

Expected results:
Resume can be successfully after S4.

Additional info:
This issue also reproduce for hot-plug.
Comment 1 dawu 2012-04-12 05:38:56 UTC 
Created attachment 576949 [details]
win7-32-S4AfterHotUnplugOrPlug-Fail2
Comment 4 Mike Cao 2012-04-16 09:46:46 UTC 
Hi, Vadim 

more info for this bug ,(might be related to MSFT) 


I also tried following steps:

1.start guests w/ 2 virito disks 
<CLI>
-drive file=/home/win2k8R2,if=none,id=drive-ide0-0-0,format=qcow2,cache=none 
-device virtio-blk-pci,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-drive file=/home/hotadd.img,format=qcow2,if=none,werror=stop,rerror=stop,cache=none,id=driver_hotadd 
-device virtio-blk-pci,id=hotadd,drive=driver_hotadd,addr=0xa

2.hot-unplug virtio disk named hotadd 
3.s4 guest
4
*if* start guest w/o the hot-unplug disk ,will hit the issue described in comment #0 ,guest also complains "your system's firmware did not preserve the system memory map across the hibernate transition " 

*if* start guest commandLine exactly same as steps 1 ,guest could resume successfully.


Additional info :
Tried w/ win2k8R2
Comment 5 dawu 2012-04-16 10:13:37 UTC 
(In reply to comment #4)
> Hi, Vadim 
> 
> more info for this bug ,(might be related to MSFT) 
> 
> 
> I also tried following steps:
> 
> 1.start guests w/ 2 virito disks 
> <CLI>
> -drive file=/home/win2k8R2,if=none,id=drive-ide0-0-0,format=qcow2,cache=none 
> -device virtio-blk-pci,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
> -drive
> file=/home/hotadd.img,format=qcow2,if=none,werror=stop,rerror=stop,cache=none,id=driver_hotadd 
> -device virtio-blk-pci,id=hotadd,drive=driver_hotadd,addr=0xa
> 
> 2.hot-unplug virtio disk named hotadd 
> 3.s4 guest
> 4
> *if* start guest w/o the hot-unplug disk ,will hit the issue described in
> comment #0 ,guest also complains "your system's firmware did not preserve the
> system memory map across the hibernate transition " 
> 
> *if* start guest commandLine exactly same as steps 1 ,guest could resume
> successfully.
> 
> 
> Additional info :
> Tried w/ win2k8R2

This interesting thing also happened on win7-32.
Comment 6 Ronen Hod 2012-04-17 09:06:29 UTC 
The issue seems to be unrelated to the Unplug itself.
The issue is that the hardware should not change during S4 (controllers and devices should not be added/deleted).
If Windows detects that the hardware changed, it warns the user exactly as seen in the attached screen dump.
Since the management software should take care of this, I believe that both virt-manager and RHEV-M, will survive this scenario, and resume properly after S4 without the unplugged device. Worth verifying.
Anyhow, this is not a QEMU/virtio-win bug, so I am closing it.
Comment 7 Vadim Rozenfeld 2012-04-17 10:42:18 UTC 
(In reply to comment #4)
> Hi, Vadim 
> 
> more info for this bug ,(might be related to MSFT) 
> 
> 
> I also tried following steps:
> 
> 1.start guests w/ 2 virito disks 
> <CLI>
> -drive file=/home/win2k8R2,if=none,id=drive-ide0-0-0,format=qcow2,cache=none 
> -device virtio-blk-pci,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
> -drive
> file=/home/hotadd.img,format=qcow2,if=none,werror=stop,rerror=stop,cache=none,id=driver_hotadd 
> -device virtio-blk-pci,id=hotadd,drive=driver_hotadd,addr=0xa
> 
> 2.hot-unplug virtio disk named hotadd 
> 3.s4 guest
> 4
> *if* start guest w/o the hot-unplug disk ,will hit the issue described in
> comment #0 ,guest also complains "your system's firmware did not preserve the
> system memory map across the hibernate transition " 

Hi Mike, I missed this point. I will take a more precise look into this issue,
but in any case, it is not a viostor but a QEMU problem.
Thank you,
Vadim.

> 
> *if* start guest commandLine exactly same as steps 1 ,guest could resume
> successfully.
> 
> 
> Additional info :
> Tried w/ win2k8R2
Comment 8 Mike Cao 2012-04-17 15:22:14 UTC 
(In reply to comment #7)
> (In reply to comment #4)
> > Hi, Vadim 
> > 
> > more info for this bug ,(might be related to MSFT) 
> > 
> > 
> > I also tried following steps:
> > 
> > 1.start guests w/ 2 virito disks 
> > <CLI>
> > -drive file=/home/win2k8R2,if=none,id=drive-ide0-0-0,format=qcow2,cache=none 
> > -device virtio-blk-pci,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
> > -drive
> > file=/home/hotadd.img,format=qcow2,if=none,werror=stop,rerror=stop,cache=none,id=driver_hotadd 
> > -device virtio-blk-pci,id=hotadd,drive=driver_hotadd,addr=0xa
> > 
> > 2.hot-unplug virtio disk named hotadd 
> > 3.s4 guest
> > 4
> > *if* start guest w/o the hot-unplug disk ,will hit the issue described in
> > comment #0 ,guest also complains "your system's firmware did not preserve the
> > system memory map across the hibernate transition " 
> 
> Hi Mike, I missed this point. I will take a more precise look into this issue,
> but in any case, it is not a viostor but a QEMU problem.
> Thank you,
> Vadim.
> 

Hi ,Vadim

I talked with Amit about this bug  .he think this is a windows guest bug instead of qemu one  .I did not re-open this bug now because I want to check whether netkvm and balloon has such ab-normal behaviour 

more info about this bug :

If I reboot guest after hot-unplug device (step 2 in comment  #0) and before hibernate guest (step 3 in comment #0)  ,then I will not hit this bug 

Mike
Comment 9 Mike Cao 2012-04-18 03:16:01 UTC 
dawu also tried netkvm and balloon driver ,did not hit issue

Based on above and comment #8 ,this should be a block driver bug .re-open it

And since s4 will not support during rhel6.3 ,I strongly suggest we can move this bug to rhel6.4.0 


Mike
Comment 10 Ronen Hod 2012-04-19 16:29:10 UTC 
Mike,
Thanks for reopening. Vadim and I mistakenly thought that the unplugged disk were present at "resume".
Anyhow, Since it is not a regression, at this stage, we better move it to 6.4. Vadim will continue to look at it, so there is a chance that it will make it to 6.3.
Comment 13 Mike Cao 2012-04-23 06:26:36 UTC 
I try balloon again
after guest hibernate ,guest could resume successfully both w/ -device virtio-balloon-pci,id=balloon.0 and w/o -device virtio-balloon-pci
Comment 18 Vadim Rozenfeld 2013-03-19 12:36:05 UTC 
Mike, Dawn
Can we try the following scenario:
- start qemu with "-no-shutdown" flag
- do hot plug or unplug
- hibernate the VM
- resume VM ('system reset', 'cont' from the qemu monitor)

Thank you,
Vadim.
Comment 19 Mike Cao 2013-03-20 03:36:59 UTC 
(In reply to comment #18)
> Mike, Dawn
> Can we try the following scenario:
> - start qemu with "-no-shutdown" flag
> - do hot plug or unplug
> - hibernate the VM
> - resume VM ('system reset', 'cont' from the qemu monitor)
> 
> Thank you,
> Vadim.

Hi, Vadim

Tried on windows server 2008R2
Steps as your desbribed 
1.start VM w/ --no-shutdown
2.hot-unplug the virtio data disk 
3.s4 guest 
4.system_reset
5.cont 

Actual Results:
hit the exactly same issue
Comment 20 Vadim Rozenfeld 2013-03-20 09:47:41 UTC 
(In reply to comment #19)
> (In reply to comment #18)
> > Mike, Dawn
> > Can we try the following scenario:
> > - start qemu with "-no-shutdown" flag
> > - do hot plug or unplug
> > - hibernate the VM
> > - resume VM ('system reset', 'cont' from the qemu monitor)
> > 
> > Thank you,
> > Vadim.
> 
> Hi, Vadim
> 
> Tried on windows server 2008R2
> Steps as your desbribed 
> 1.start VM w/ --no-shutdown
> 2.hot-unplug the virtio data disk 
> 3.s4 guest 
> 4.system_reset
> 5.cont 
> 
> Actual Results:
> hit the exactly same issue

Hi Mike,
Could you please post pci resources ('info pci') before and hibernation and after resume?
Thank you,
Vadim.
Comment 21 Mike Cao 2013-03-20 09:52:59 UTC 
Before hibernation
(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 0xc000 [0xc00f].
      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 10.
      BAR0: 32 bit memory at 0xf0000000 [0xf3ffffff].
      BAR1: 32 bit memory at 0xffffffffffffffff [0x03fffffe].
      BAR2: 32 bit memory at 0xf4000000 [0xf4003fff].
      BAR3: I/O at 0xc020 [0xc03f].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
      id ""
  Bus  0, device   3, function 0:
    SCSI controller: PCI device 1af4:1001
      IRQ 11.
      BAR0: I/O at 0xc040 [0xc07f].
      BAR1: 32 bit memory at 0xf4020000 [0xf4020fff].
      id "ide0-0-0"
  Bus  0, device   4, function 0:
    SCSI controller: PCI device 1af4:1001
      IRQ 11.
      BAR0: I/O at 0xc080 [0xc0bf].
      BAR1: 32 bit memory at 0xf4021000 [0xf4021fff].
      id "ide0-1-0"
  Bus  0, device   5, function 0:
    Class 0403: PCI device 8086:2668
      IRQ 10.
      BAR0: 32 bit memory at 0xf4024000 [0xf4027fff].
      id "sound0"
  Bus  0, device   6, function 0:
    RAM controller: PCI device 1af4:1002
      IRQ 10.
      BAR0: I/O at 0xc0c0 [0xc0df].
      id "balloon"
  Bus  0, device   9, function 0:
    Ethernet controller: PCI device 8086:100e
      IRQ 10.
      BAR0: 32 bit memory at 0xf4040000 [0xf405ffff].
      BAR1: I/O at 0xc100 [0xc13f].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0001fffe].
      id "net0"
Comment 22 Mike Cao 2013-03-20 09:56:10 UTC 
After Device_del
(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 0xc000 [0xc00f].
      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 0xf0000000 [0xf3ffffff].
      BAR1: 32 bit memory at 0xf8000000 [0xfbffffff].
      BAR2: 32 bit memory at 0xf4000000 [0xf4003fff].
      BAR3: I/O at 0xc020 [0xc03f].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
      id ""
  Bus  0, device   3, function 0:
    SCSI controller: PCI device 1af4:1001
      IRQ 0.
      BAR0: I/O at 0xc040 [0xc07f].
      BAR1: 32 bit memory at 0xf4020000 [0xf4020fff].
      id "ide0-0-0"
  Bus  0, device   5, function 0:
    Class 0403: PCI device 8086:2668
      IRQ 11.
      BAR0: 32 bit memory at 0xf4024000 [0xf4027fff].
      id "sound0"
  Bus  0, device   6, function 0:
    RAM controller: PCI device 1af4:1002
      IRQ 5.
      BAR0: I/O at 0xc0c0 [0xc0df].
      id "balloon"
  Bus  0, device   9, function 0:
    Ethernet controller: PCI device 8086:100e
      IRQ 11.
      BAR0: 32 bit memory at 0xf4040000 [0xf405ffff].
      BAR1: I/O at 0xc100 [0xc13f].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0001fffe].
      id "net0"
Comment 23 Mike Cao 2013-03-20 09:56:57 UTC 
hibernate the VM
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 0xc000 [0xc00f].
      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 0xf0000000 [0xf3ffffff].
      BAR1: 32 bit memory at 0xf8000000 [0xfbffffff].
      BAR2: 32 bit memory at 0xf4000000 [0xf4003fff].
      BAR3: I/O at 0xc020 [0xc03f].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
      id ""
  Bus  0, device   3, function 0:
    SCSI controller: PCI device 1af4:1001
      IRQ 0.
      BAR0: I/O at 0xc040 [0xc07f].
      BAR1: 32 bit memory at 0xf4020000 [0xf4020fff].
      id "ide0-0-0"
  Bus  0, device   5, function 0:
    Class 0403: PCI device 8086:2668
      IRQ 11.
      BAR0: 32 bit memory at 0xffffffffffffffff [0x00003ffe].
      id "sound0"
  Bus  0, device   6, function 0:
    RAM controller: PCI device 1af4:1002
      IRQ 5.
      BAR0: I/O at 0xffffffffffffffff [0x001e].
      id "balloon"
  Bus  0, device   9, function 0:
    Ethernet controller: PCI device 8086:100e
      IRQ 11.
      BAR0: 32 bit memory at 0xffffffffffffffff [0x0001fffe].
      BAR1: I/O at 0xffffffffffffffff [0x003e].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0001fffe].
      id "net0"
Comment 24 Mike Cao 2013-03-20 09:57:54 UTC 
(qemu)system_reset
(qemu)cont
(qemu)info pci
(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 0xc000 [0xc00f].
      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 10.
      BAR0: 32 bit memory at 0xf0000000 [0xf3ffffff].
      BAR1: 32 bit memory at 0xffffffffffffffff [0x03fffffe].
      BAR2: 32 bit memory at 0xf4000000 [0xf4003fff].
      BAR3: I/O at 0xc020 [0xc03f].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
      id ""
  Bus  0, device   3, function 0:
    SCSI controller: PCI device 1af4:1001
      IRQ 11.
      BAR0: I/O at 0xc040 [0xc07f].
      BAR1: 32 bit memory at 0xf4020000 [0xf4020fff].
      id "ide0-0-0"
  Bus  0, device   5, function 0:
    Class 0403: PCI device 8086:2668
      IRQ 10.
      BAR0: 32 bit memory at 0xf4024000 [0xf4027fff].
      id "sound0"
  Bus  0, device   6, function 0:
    RAM controller: PCI device 1af4:1002
      IRQ 10.
      BAR0: I/O at 0xc080 [0xc09f].
      id "balloon"
  Bus  0, device   9, function 0:
    Ethernet controller: PCI device 8086:100e
      IRQ 10.
      BAR0: 32 bit memory at 0xf4040000 [0xf405ffff].
      BAR1: I/O at 0xc0c0 [0xc0ff].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0001fffe].
      id "net0"
Comment 25 Vadim Rozenfeld 2013-03-20 11:31:59 UTC 
Thanks, seems like system_reset returns the original configuration. 
That is why this trick doesn't work. I'll try to find a better way
how to resume VM with absolutely the same HW configuration as it was on 
hibernate.

Cheers,
Vadim.
Comment 26 Mike Cao 2013-03-21 03:22:05 UTC 
(In reply to comment #25)
> Thanks, seems like system_reset returns the original configuration. 
> That is why this trick doesn't work. I'll try to find a better way
> how to resume VM with absolutely the same HW configuration as it was on 
> hibernate.
> 
> Cheers,
> Vadim.

Sorry ,What's the original configuration mean here ?the pci info after hot-unplug ?
Comment 27 Vadim Rozenfeld 2013-03-21 03:45:50 UTC 
(In reply to comment #26)
> (In reply to comment #25)
> > Thanks, seems like system_reset returns the original configuration. 
> > That is why this trick doesn't work. I'll try to find a better way
> > how to resume VM with absolutely the same HW configuration as it was on 
> > hibernate.
> > 
> > Cheers,
> > Vadim.
> 
> Sorry ,What's the original configuration mean here ?the pci info after
> hot-unplug ?

if I read it correctly:
we have 
  Bus  0, device   3, function 0:
    SCSI controller: PCI device 1af4:1001
      IRQ 0.
      BAR0: I/O at 0xc040 [0xc07f].
      BAR1: 32 bit memory at 0xf4020000 [0xf4020fff].
      id "ide0-0-0"
before hibernate, and 
  Bus  0, device   3, function 0:
    SCSI controller: PCI device 1af4:1001
      IRQ 11.
      BAR0: I/O at 0xc040 [0xc07f].
      BAR1: 32 bit memory at 0xf4020000 [0xf4020fff].
      id "ide0-0-0"
after resume. For OS it means that HW configuration was changed between these two events,
Comment 28 Mike Cao 2013-03-21 03:59:51 UTC 
(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #25)
> > > Thanks, seems like system_reset returns the original configuration. 
> > > That is why this trick doesn't work. I'll try to find a better way
> > > how to resume VM with absolutely the same HW configuration as it was on 
> > > hibernate.
> > > 
> > > Cheers,
> > > Vadim.
> > 
> > Sorry ,What's the original configuration mean here ?the pci info after
> > hot-unplug ?
> 
> if I read it correctly:
> we have 
>   Bus  0, device   3, function 0:
>     SCSI controller: PCI device 1af4:1001
>       IRQ 0.
>       BAR0: I/O at 0xc040 [0xc07f].
>       BAR1: 32 bit memory at 0xf4020000 [0xf4020fff].
>       id "ide0-0-0"
> before hibernate, and 
>   Bus  0, device   3, function 0:
>     SCSI controller: PCI device 1af4:1001
>       IRQ 11.
>       BAR0: I/O at 0xc040 [0xc07f].
>       BAR1: 32 bit memory at 0xf4020000 [0xf4020fff].
>       id "ide0-0-0"
> after resume. For OS it means that HW configuration was changed between
> these two events,

I did not find 00:03.0 changed 
What I did is remove 00:04.0
Comment 29 Mike Cao 2013-03-21 04:01:18 UTC 
(In reply to comment #28)
> (In reply to comment #27)
> > (In reply to comment #26)
> > > (In reply to comment #25)
> > > > Thanks, seems like system_reset returns the original configuration. 
> > > > That is why this trick doesn't work. I'll try to find a better way
> > > > how to resume VM with absolutely the same HW configuration as it was on 
> > > > hibernate.
> > > > 
> > > > Cheers,
> > > > Vadim.
> > > 
> > > Sorry ,What's the original configuration mean here ?the pci info after
> > > hot-unplug ?
> > 
> > if I read it correctly:
> > we have 
> >   Bus  0, device   3, function 0:
> >     SCSI controller: PCI device 1af4:1001
> >       IRQ 0.
> >       BAR0: I/O at 0xc040 [0xc07f].
> >       BAR1: 32 bit memory at 0xf4020000 [0xf4020fff].
> >       id "ide0-0-0"
> > before hibernate, and 
> >   Bus  0, device   3, function 0:
> >     SCSI controller: PCI device 1af4:1001
> >       IRQ 11.
> >       BAR0: I/O at 0xc040 [0xc07f].
> >       BAR1: 32 bit memory at 0xf4020000 [0xf4020fff].
> >       id "ide0-0-0"
> > after resume. For OS it means that HW configuration was changed between
> > these two events,
> 
> I did not find 00:03.0 changed 
> What I did is remove 00:04.0

Got you .you mean IRQ Changed
Comment 34 Vadim Rozenfeld 2014-04-27 04:09:42 UTC 
Hi Mike,
Can yo please recheck this issue with the latest drivers?

Thanks,
Vadim.
Comment 35 Ronen Hod 2014-08-06 08:56:39 UTC 
QE, please recheck. Thanks.
Comment 36 Min Deng 2014-08-14 08:22:31 UTC 
  QE still could reproduce the bug on rhel6.6 host but I could not reproduce it on rhel7 host.
On rhel6.6 host *reproduce*
virtio-win-prewhql-0.1-89
kernel-2.6.32-492.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.430.el6.x86_64
seabios-0.6.1.2-28.el6.x86_64 (latest so far)

On rhel7 host  *Not reproduce*
virtio-win-prewhql-0.1-89
kernel-3.10.0-143.el7.x86_64
qemu-kvm-rhev-2.1.0-1.el7.x86_64.rpm
seabios-1.7.5-4.el7.x86_64.rpm
seabios-bin-1.7.5-4.el7.noarch.rpm
seavgabios-bin-1.7.5-4.el7.noarch.rpm

Steps,
1.boot up guest /usr/libexec/qemu-kvm -cpu SandyBridge,+x2apic -smp 4 -m 2G -device virtio-balloon-pci,id=balloon0 -k en-us -usb -device usb-tablet,id=tablet0 -drive file=win2k8-32.qcow2,format=qcow2,cache=none,if=none,id=scsi0,media=disk -device virtio-blk-pci,drive=scsi0,id=ide-disk0 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device e1000,netdev=hostnet0,id=net0,mac=00:12:7a:00:11:12 -rtc base=localtime,clock=host,driftfix=slew -name win2k8 -spice port=5931,disable-ticketing -vga qxl -uuid a4ef4247-36ba-4f37-bf98-e82de9382532 -monitor stdio -boot cd  -drive file=disk1.qcow2,format=qcow2,cache=none,if=none,id=scsi1,media=disk  -device virtio-blk-pci,drive=scsi1,id=ide-disk1  -drive file=disk2.qcow2,format=qcow2,cache=none,if=none,id=scsi2,media=disk -device virtio-blk-pci,drive=scsi2,id=ide-disk2 -drive file=disk3.raw,format=raw,cache=none,if=none,id=scsi3,media=disk -device virtio-blk-pci,drive=scsi3,id=ide-disk3 -global PIIX4_PM.disable_s3=0

2.(qemu) __com.redhat_drive_add  file=test3.raw,format=raw,id=blkdisk3
  (qemu) device_add virtio-blk-pci,drive=blkdisk3,id=blkdisk3
3.Do S4

4.resume guest with CLI of step1 + "-drive file=test3.raw,format=raw,cache=none,if=none,id=blkdisk3,media=disk -device virtio-blk-pci,drive=blkdisk3,id=blkdisk3"


Actual results,hit the bug (only on rhel6.6 host)
Expected results,guest could resume successfully

So could you please double check ? Thanks!
Comment 37 Ronen Hod 2014-08-14 16:24:33 UTC 
(In reply to dengmin from comment #36)
>   QE still could reproduce the bug on rhel6.6 host but I could not reproduce
> it on rhel7 host.

Since S4 is not officially supported in RHEL6, and it seems to be solved in RHEL7, I am closing this bug.
Thanks.
Note You need to log in before you can comment on or make changes to this bug.