Bug 1994266 - 'qemu-img convert' Fails While the Size of The Souce Image Is Unaligned to The 4k Sector Size of The Host
Summary: 'qemu-img convert' Fails While the Size of The Souce Image Is Unaligned to Th...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: qemu-kvm
Version: 9.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: beta
: ---
Assignee: Hanna Reitz
QA Contact: Tingting Mao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-08-17 07:44 UTC by Tingting Mao
Modified: 2022-02-10 06:25 UTC (History)
6 users (show)

Fixed In Version: qemu-kvm-6.2.0-1.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-02-10 06:25:31 UTC
Type: ---
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-93764 0 None None None 2021-08-17 07:45:19 UTC

Description Tingting Mao 2021-08-17 07:44:48 UTC
Description of problem:
As above, and the sector size of the host is 4k insteand of 512.


Version-Release number of selected component (if applicable):
qemu-kvm-6.0.0-11.el9
kernel-5.14.0-0.rc4.35.el9.x86_64


How reproducible:
100%


Steps to Reproduce:
1. Create a soure image with 18432 bytes(18432 = 4.5 * 4096)
                                                 ^^^ 
# truncate -s 18432 test.img

2. Convert the soure image to a target image file
# qemu-img convert -f raw -O raw -p -t none -T none test.img tgt.img 
qemu-img: Could not open 'tgt.img': Cannot get 'write' permission without 'resize': Image size is not a multiple of request alignment

Note:
The disk info host:
# fdisk -l
Disk /dev/sda: 558.38 GiB, 599550590976 bytes, 146374656 sectors
Disk model: PERC H730P Adp  
Units: sectors of 1 * 4096 = 4096 bytes ----------------------------------> 4k
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 31D4FB66-164D-4707-8679-4F624D134835

Device      Start       End   Sectors   Size Type
/dev/sda1     256    153855    153600   600M EFI System
/dev/sda2  153856    415999    262144     1G Linux filesystem
/dev/sda3  416000 146374399 145958400 556.8G Linux LVM




Actual results:
As above, converting fails.


Expected results:
Converting successes like converting with the sector size of 512.


Additional info:
While for the sector size of the host is 512, converting works fine.
# truncate -s 11136 test.img  (######## 11136 = 21.75 * 512)

# qemu-img convert -f raw -O raw -t none -T none test.img tgt.img -p
    (100.00/100%)

The disk info of the host:
# fdisk -l
Disk /dev/sda: 558.91 GiB, 600127266816 bytes, 1172123568 sectors
Disk model: ST600MM0208     
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x395d8cdd

Device     Boot   Start        End    Sectors   Size Id Type
/dev/sda1  *       2048    2099199    2097152     1G 83 Linux
/dev/sda2       2099200 1172121599 1170022400 557.9G 8e Linux LVM

Comment 1 Hanna Reitz 2021-08-19 08:32:19 UTC
Hi,

The problem is exactly what the error message says.  We create the target image with the same size as the source, i.e. a non-4k-aligned size, but writing to it would mean we would have to change its size.

Is this really a bug?  Do we want qemu-img convert to create an image of a different size than the source?

The error message is also clear enough that I think it’s clear to users what to do to work around this, namely to first extend the source image to be aligned to 4k.


OTOH, changing this behavior seems really simple, it could be a one-liner, like:

diff --git a/qemu-img.c b/qemu-img.c
index 908fd0cce5..c5308dcdad 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -2622,6 +2622,7 @@ static int img_convert(int argc, char **argv)
     s.target_is_new = !skip_create;
 
     flags = s.min_sparse ? (BDRV_O_RDWR | BDRV_O_UNMAP) : BDRV_O_RDWR;
+    flags |= BDRV_O_RESIZE;
     ret = bdrv_parse_cache_mode(cache, &flags, &writethrough);
     if (ret < 0) {
         error_report("Invalid cache option: %s", cache);



And basically that change tells the story: We would need to allow opening the target image to lead to it being resized, but naively img_convert() doesn’t want the target image to be resized after it’s been created.

I think I’ll send an RFC upstream and see what others think.

Hanna

Comment 2 Tingting Mao 2021-08-19 09:04:13 UTC
(In reply to Hanna Reitz from comment #1)
> Hi,
> 
> The problem is exactly what the error message says.  We create the target
> image with the same size as the source, i.e. a non-4k-aligned size, but
> writing to it would mean we would have to change its size.
> 
> Is this really a bug?  Do we want qemu-img convert to create an image of a
> different size than the source?
The case is from bug 1649788, and you could check the reproduced steps via https://bugzilla.redhat.com/show_bug.cgi?id=1649788#c32. And user can convert success without any error message after this bug was fixed.
                                                                                                                                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^       
The only difference: The host sector size is 512 of bug 1649788, while for this bug the host sector size is 4k.


Best,
Tingting

Comment 3 Tingting Mao 2021-08-19 09:07:14 UTC
(In reply to Tingting Mao from comment #2)
> (In reply to Hanna Reitz from comment #1)
> > Hi,
> > 
> > The problem is exactly what the error message says.  We create the target
> > image with the same size as the source, i.e. a non-4k-aligned size, but
> > writing to it would mean we would have to change its size.
> > 
> > Is this really a bug?  Do we want qemu-img convert to create an image of a
> > different size than the source?
> The case is from bug 1649788, and you could check the reproduced steps via
> https://bugzilla.redhat.com/show_bug.cgi?id=1649788#c32. And user can
> convert success without any error message after this bug was fixed.
>                                                                             
> ^^^^^^^^^^^^^^^^^^^^^^^^^       
Change bug 1649788 to bug 1678979.

> The only difference: The host sector size is 512 of bug 1649788, while for
> this bug the host sector size is 4k.
Change bug 1649788 to bug 1678979.

Comment 4 Hanna Reitz 2021-08-19 09:34:14 UTC
Hm, OK.  I think that bug is still quite different, because a failed assertion is worse than a clean error message that implies what to do to work around the problem.

Comment 5 Hanna Reitz 2021-08-19 10:26:17 UTC
I’ve sent a patch upstream: https://lists.nongnu.org/archive/html/qemu-block/2021-08/msg00280.html

Comment 6 Tingting Mao 2021-08-19 10:40:30 UTC
(In reply to Hanna Reitz from comment #5)
> I’ve sent a patch upstream:
> https://lists.nongnu.org/archive/html/qemu-block/2021-08/msg00280.html

Agree. What I would like to say is that converting from the image with unaligned size to 512 bytes works fine, but converting from the image with unaligned size to 4k bytes fails with error messages.

Note:
AFAIK, the machines with sector unit size of 512 bytes are mostly used by users. But there are also some users using the machines with the sector unit size of 4k bytes.

Comment 7 Hanna Reitz 2022-02-09 15:12:35 UTC
Sorry for forgetting about this BZ; the patch from comment 4 has been merged as a1c62436a4f053766892355da0ca35c5df19fc22, which became part of the 6.2.0 release.

Comment 8 CongLi 2022-02-10 00:23:50 UTC
Hi Tingting,

Please have a test with latest build.

Thanks.

Comment 9 Tingting Mao 2022-02-10 06:24:14 UTC
Tried in latest qemu, there is no the bug.


Tested with:
qemu-kvm-6.2.0-7.el9
kernel-5.14.0-47.el9.x86_64


Steps:
# truncate -s 18432 test.img
# qemu-img convert -f raw -O raw -p -t none -T none test.img tgt.img 
    (100.00/100%)

Note for host disk info:
# fdisk -l
Disk /dev/sda: 558.38 GiB, 599550590976 bytes, 146374656 sectors
Disk model: PERC H730P Adp  
Units: sectors of 1 * 4096 = 4096 bytes ------------------------------> 4k 
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F1DCBC9E-C1C1-40C9-AA96-A074EEE22514

Device      Start       End   Sectors   Size Type
/dev/sda1     256    153855    153600   600M EFI System
/dev/sda2  153856    415999    262144     1G Linux filesystem
/dev/sda3  416000 146374399 145958400 556.8G Linux LVM


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