Bug 1071046
| Summary: | block_resize guest notification gets lost for virtio-blk and scsi-hd when guest is in S3 | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jun Li <juli> | |
| Component: | qemu-kvm | Assignee: | Markus Armbruster <armbru> | |
| Status: | CLOSED WONTFIX | QA Contact: | FuXiangChun <xfu> | |
| Severity: | low | Docs Contact: | ||
| Priority: | low | |||
| Version: | 7.0 | CC: | hhuang, juli, juzhang, knoel, michen, rbalakri, virt-maint, xfu | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1371359 (view as bug list) | Environment: | ||
| Last Closed: | 2016-08-31 20:28:59 UTC | Type: | Bug | |
| 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: | ||||
| Bug Blocks: | 923626, 1371359 | |||
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. err, wrong block_resize bug, that was meant for 1070531 Seems like a corner case that's not important to prioritize for 7.1, so deferring to 7.2 I'm not really keyed into the RHEL process, so resetting assignee (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. 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? (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 (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"} 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. (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 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! One more question: is RHEL-6 affected, too? 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. (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 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. (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. |
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: