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 1071046 - block_resize guest notification gets lost for virtio-blk and scsi-hd when guest is in S3
Summary: block_resize guest notification gets lost for virtio-blk and scsi-hd when gue...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Markus Armbruster
QA Contact: FuXiangChun
URL:
Whiteboard:
Depends On:
Blocks: Virt-S3/S4-7.0 1371359
TreeView+ depends on / blocked
 
Reported: 2014-02-28 02:26 UTC by Jun Li
Modified: 2016-08-31 20:29 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1371359 (view as bug list)
Environment:
Last Closed: 2016-08-31 20:28:59 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jun Li 2014-02-28 02:26:02 UTC 
Description of problem:
when guest in S3, can not do block_resize successfully. But block_resize does not give any unsuccessful hint. 

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-1.5.3-49.el7.x86_64
host kernel:
3.10.0-95.el7.x86_64
guest kernel:
3.10.0-89.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Boot guest with following cli:
/usr/libexec/qemu-kvm -M pc -m 4G -smp 2 -monitor stdio -boot menu=on,reboot-timeout=-1,strict=on -qmp tcp::8888,server,nowait -device virtio-scsi-pci,bus=pci.0,id=scsi0 -drive file=/home/juli/rhel-server-7.0-64.qcow2,if=none,format=qcow2,id=img,cache=writethrough,werror=stop,rerror=stop -device scsi-hd,bus=scsi0.0,drive=img,id=sys-img -netdev tap,id=tap1,vhost=on,queues=4,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -device virtio-net-pci,netdev=tap1,id=net1,mq=on,vectors=17,mac=18:03:73:39:a6:11 -vga qxl -global qxl-vga.revision=3 -spice port=5931,disable-ticketing \
-drive file=/home/data-img,if=none,id=drive-data-disk,format=raw,cache=none,aio=native,werror=stop,rerror=stop,discard=on -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x8 \
-device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk \
-global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0
2.after guest boot, do S3 inside guest.
# pm-suspend
3.Before resume from S3, do block_resize with a new size for data disk(drive-data-disk) via qmp.
---
{ "execute": "block_resize", "arguments": { "device": "drive-data-disk", "size": 13741824000 }}
4.resume from S3, check data disk(drive-data-disk) size inside guest.

Actual results:
After step 4, data disk size did not changed. But after step 3, qmp return 
{ "execute": "block_resize", "arguments": { "device": "drive-data-disk", "size": 13741824000 }}
{"return": {}}


Expected results:
If block_resize can not change the data disk size, should give some unsuccessful hint. Maybe just like qmp command hot-unplug a disk, it will give a event when success.

Additional info:
Comment 3 Cole Robinson 2014-07-29 15:43:08 UTC 
bdrv_truncate needs to be extended to pass around an Error object. Not upstream and not urgent, so 7.2 material at the least.

But this is a fairly minor error reporting issue IMO. Certainly worth fixing upstream at some point, but I don't think it's worth a backport, figuring that every bdrv_truncate implementation will need to be touched which is probably 10 files or so.
Comment 4 Cole Robinson 2014-07-29 15:44:36 UTC 
err, wrong block_resize bug, that was meant for 1070531
Comment 5 Cole Robinson 2014-07-29 19:33:54 UTC 
Seems like a corner case that's not important to prioritize for 7.1, so deferring to 7.2
Comment 9 Cole Robinson 2016-05-03 21:05:35 UTC 
I'm not really keyed into the RHEL process, so resetting assignee
Comment 10 Ademar Reis 2016-05-09 20:32:40 UTC 
(In reply to Jun Li from comment #0)
> Description of problem:
> when guest in S3, can not do block_resize successfully. But block_resize
> does not give any unsuccessful hint. 
> 

Please notice S3 is not supported in RHEL, but I'm reassigning to Markus anyway, for further evaluation of the error reporting improvement.
Comment 11 Markus Armbruster 2016-07-22 12:30:20 UTC 
This bug was filed against qemu-kvm, but comment#0 gives a qemu-kvm-rhev version.  Does the bug reproduce with current qemu-kvm?  What about current qemu-kvm-rhev?
Comment 12 juzhang 2016-07-25 01:37:05 UTC 
(In reply to Markus Armbruster from comment #11)
> This bug was filed against qemu-kvm, but comment#0 gives a qemu-kvm-rhev
> version.  Does the bug reproduce with current qemu-kvm?  What about current
> qemu-kvm-rhev?

Hi Xiangchun,

Could you add comments?

Best Regards,
Junyi
Comment 13 FuXiangChun 2016-07-26 06:43:19 UTC 
(In reply to Markus Armbruster from comment #11)
> This bug was filed against qemu-kvm, but comment#0 gives a qemu-kvm-rhev
> version.  Does the bug reproduce with current qemu-kvm?  What about current
> qemu-kvm-rhev?

Both qemu-kvm and qemu-kvm-rhev can reproduce this problem. 
version:
qemu-kvm-1.5.3-118.el7.x86_64
qemu-kvm-rhev-2.6.0-15.el7.x86_64

result:
can not change disk size. and didn't give some unsuccessful hint


{"timestamp": {"seconds": 1469514909, "microseconds": 739554}, "event": "WAKEUP"}
{"timestamp": {"seconds": 1469515006, "microseconds": 781798}, "event": "SUSPEND"}
{ "execute": "block_resize", "arguments": { "device": "drive-data-disk", "size":27483648000 }}
{"return": {}}
{"timestamp": {"seconds": 1469515038, "microseconds": 785077}, "event": "WAKEUP"}
Comment 14 Markus Armbruster 2016-07-28 09:49:04 UTC 
I suspect the block_resize itself works fine, but the guest
notification gets lost due to the guest's S3 state.  If the
notification gets lost, the guest still sees the old size even after a
successful resize.

Guest notification is device-specific.  It's implemented for
virtio-blk, ide-hd and scsi-hd/scsi-cd/scsi-block.

Xiangchun, could you please find out whether block_resize changes the
image for you?  Easiest to see when the image is a regular file.

Additionally, please test whether the guest sees the changed image
size seperately separately for virtio-blk, ide-hd and scsi-hd.
Comment 15 FuXiangChun 2016-08-02 07:39:05 UTC 
(In reply to Markus Armbruster from comment #14)
> I suspect the block_resize itself works fine, but the guest
> notification gets lost due to the guest's S3 state.  If the
> notification gets lost, the guest still sees the old size even after a
> successful resize.
> 
> Guest notification is device-specific.  It's implemented for
> virtio-blk, ide-hd and scsi-hd/scsi-cd/scsi-block.
> 
> Xiangchun, could you please find out whether block_resize changes the
> image for you?  Easiest to see when the image is a regular file.
> 
> Additionally, please test whether the guest sees the changed image
> size seperately separately for virtio-blk, ide-hd and scsi-hd.

Markus,
I am sorry for replying this bug so late. I tested virtio-blk, ide-hd and scsi-hd as data disk. and tested qemu-kvm-1.5.3-120 and qemu-kvm-rhev-2.6.0-17. This is test result and steps below.

result:

          change image size   change disk size in guest   qemu-kvm/qemu-kvm-rhev
 
virtio-blk     Y               N                           Both

ide-hd         Y               Y                           Both

scsi-hd        Y               N                           Both


steps:
For regular file.

1)qemu-img create -f raw /home/1G.raw 1G
image: /home/1G.raw
file format: raw
virtual size: 1.0G (1073741824 bytes)
disk size: 0

2) do s3 inside guest

3){ "execute": "block_resize", "arguments": { "device": "drive-data-disk", "size": 13741824000 }}
{"return": {}}
{"timestamp": {"seconds": 1470116409, "microseconds": 828233}, "event": "WAKEUP"}

3)# qemu-img info /home/1G.raw 
image: /home/1G.raw
file format: raw
virtual size: 13G (13741824000 bytes)
disk size: 0

4)check disk size inside guest.(ide-hd can be changed only)
#fdisk -l
Comment 16 Markus Armbruster 2016-08-02 09:19:01 UTC 
Interesting.  Conclusions:

* The resize itself works fine.

* When the guest is in S3, the guest notification gets lost for virtio-blk and scsi-hd, but not for ide-hd.

Thanks, Xiangchun!
Comment 17 Markus Armbruster 2016-08-02 09:26:19 UTC 
One more question: is RHEL-6 affected, too?
Comment 18 Ademar Reis 2016-08-04 17:14:53 UTC 
Just as a reminder in case my previous comment was lost in noise: S3 and S4 are not supported in RHEL (all versions). There's no need to test this kind of scenario or even fix them, unless we're talking about a low-hanging fruit or something that affects other uses.
Comment 19 FuXiangChun 2016-08-10 10:13:59 UTC 
(In reply to Markus Armbruster from comment #17)
> One more question: is RHEL-6 affected, too?

As S3 is not supported. so I only tested without S3 for RHEL6.8.  This is test result below. For ide-drive, disk size can not be changed inside guest. qemu version is qemu-kvm-0.12.1.2-2.491.el6.x86_64. Do QE need to file a new bug to track it?

result:

          change image size   change disk size in guest   qemu
 
virtio-blk     Y               Y                          qemu-kvm-rhev

ide-drive      Y               N                          qemu-kvm-rhev

scsi-hd        Y               Y                          qemu-kvm-rhev


Re-test RHEL7.3 without S3. The latest result. ide disk can not be changed in guest. qemu version:qemu-kvm-1.5.3-121 & qemu-kvm-rhev-10-2.6.0-19.el7

          change image size   change disk size in guest   qemu-kvm/qemu-kvm-rhev
 
virtio-blk     Y               Y                           Both

ide-hd         Y               N                           Both

scsi-hd        Y               Y                           Both
Comment 20 Markus Armbruster 2016-08-10 16:03:22 UTC 
Paolo explained to me why this cannot be fixed in QEMU: S3 is
essentially a system reset, and the devices are not active during the
sleep.  There is no virtqueue or no interrupt to put the notification
in.  It's the guest driver that should check for a resized disk after
S3 resume.

That means we'll need to file bugs against the kernel for the affected
drivers.  Once that's done, this bug can be closed.
Comment 21 Ademar Reis 2016-08-31 20:28:59 UTC 
(In reply to Markus Armbruster from comment #20)
> Paolo explained to me why this cannot be fixed in QEMU: S3 is
> essentially a system reset, and the devices are not active during the
> sleep.  There is no virtqueue or no interrupt to put the notification
> in.  It's the guest driver that should check for a resized disk after
> S3 resume.
> 
> That means we'll need to file bugs against the kernel for the affected
> drivers.  Once that's done, this bug can be closed.

I see the new BZs, but I'm closing all of them as WONTFIX. We have many bugs in S3/S4 scenarios and this one is not special (S3/S4 are not supported under KVM). I considered it worth checking just in case it was a trivial fix, which it's not.
Note You need to log in before you can comment on or make changes to this bug.