Bug 749122 - Allow configuring 4KiB alignment for 4KiB physical drives
Allow configuring 4KiB alignment for 4KiB physical drives
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
7.0
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Gunannan Ren
Virtualization Bugs
:
Depends On: 748902 748906
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-26 05:03 EDT by Dor Laor
Modified: 2015-02-27 22:14 EST (History)
28 users (show)

See Also:
Fixed In Version: libvirt-0.10.2-3.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 748906
Environment:
Last Closed: 2014-06-13 05:57:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
testing script (822 bytes, text/x-csrc)
2013-04-26 04:34 EDT, Gunannan Ren
no flags Details

  None (edit)
Comment 3 David Woodhouse 2011-11-23 05:39:09 EST
Fixing summary. You really don't want to align to 4000 bytes; you want 4096 (4KiB). Dunno why people are *still* getting this wrong.
Comment 4 Laine Stump 2011-12-13 11:15:21 EST
I'm pretty sure everyone involved knows that in the case of disk sectors, "4k" means 4096. (This whole "KiB" thing is a fairly recent device (1999) and hasn't been universally accepted. To those of us who've been around for awhile, 4k will always mean 4096, not 4000.)
Comment 5 David Woodhouse 2011-12-13 11:36:12 EST
Cunsistant speling iz orlso a relutivlee resent devise (C15th) and, inn meny kayses wenn peepol ar layzey or dimm, dusn't seme too hav bene universaley acepted ithur.

But still, in a professional environment we usually at least *try* to make sure that our communication is correct and unambiguous.
Comment 11 Paolo Bonzini 2013-02-19 06:10:55 EST
> Paolo, has this become something pressing, or should we continue to hold on it 
> until these disks become more common?

No, we can hold on it.

> Also, is this something that we can fix anytime and it'll just work when 4096 > disks become more common, or is there a chance of getting things wrong by 
> moving too quickly on it?

Should be safe.

But I believe the implementation should be just in QEMU.  Configurability in libvirt would be just a workaround, and it turns out that it's now done: https://www.redhat.com/archives/libvir-list/2012-August/msg01849.html

Moving to ON_QA.
Comment 12 Dave Allan 2013-02-19 09:38:46 EST
(In reply to comment #11)
> But I believe the implementation should be just in QEMU.  Configurability in
> libvirt would be just a workaround, and it turns out that it's now done:
> https://www.redhat.com/archives/libvir-list/2012-August/msg01849.html
> 
> Moving to ON_QA.

Cool, thanks Paolo
Comment 13 Shanzhi Yu 2013-04-24 06:27:45 EDT
Hi there,

When i try to verify this bug on rhel7 with below packages but fail.

kernel-3.8.0-0.43.el7.x86_64
qemu-kvm-1.4.0-2.1.el7.x86_64
libvirt-1.0.4-1.1.el7.x86_64

Would you please approve more detail steps how to reproduce this bug through ?

My step is as below:
1. download the source code of libguestfs and unpackage the tar package.
2. run ./configure
3. run make

then i met below error:
gcc: error: 和export: No such file or directory
make[3]: *** [libguestfs_la-actions-0.lo] Error 1
make[3]: Leaving directory `/usr/local/libguestfs-1.20.6/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/local/libguestfs-1.20.6/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/libguestfs-1.20.6'
make: *** [all] Error 2
Comment 14 Paolo Bonzini 2013-04-24 08:19:51 EDT
There is a libguestfs package in rhel7, why build your own?
Comment 15 Gunannan Ren 2013-04-24 23:25:34 EDT
Yes, do we have to build libguestfs ourselves?
Could you please give the error without any translation in error context.
Comment 16 Shanzhi Yu 2013-04-25 05:08:23 EDT
(In reply to comment #15)
> Yes, do we have to build libguestfs ourselves?
> Could you please give the error without any translation in error context.

Hi

Would you please provide  detail steps  how to verify this bug through libvirt?
Comment 17 Gunannan Ren 2013-04-26 04:34:54 EDT
Created attachment 740294 [details]
testing script
Comment 18 Gunannan Ren 2013-04-26 04:39:41 EDT
After you added <blockio logical_block_size='512' physical_block_size='4096'/> into domain XML, you copy compiled testing program(see above attachment) to guest to examine if these value are set right.

compile: gcc -Wall -o getsize /path/to/getsize.c
scp getsize to guest
run: ./path/to/getsize /dev/[s|v]da

output like
# ./getsize /dev/sda
BLKSSZGET=512 BLKPBSZGET=4096
I think it's okay to test this way, if something wrong, please correct me.
Comment 19 Paolo Bonzini 2013-04-26 11:02:11 EDT
Yes, that's okay.  You can also test logical_block_size='4096' on a 512-byte sector disk.  It's not something that should be done in production, but for testing purposes it's ok.

Also, you can use sysfs too:

$ cat /sys/block/sda/queue/logical_block_size 
512
$ cat /sys/block/sda/queue/physical_block_size 
512

Please test both virtio-blk and virtio-scsi.
Comment 20 Shanzhi Yu 2013-05-03 22:53:09 EDT
Verify this bug but fails with below package:

kernel-3.8.0-0.43.el7.x86_64
libvirt-1.0.4-1.1.el7.x86_64
qemu-kvm-1.4.0-3.el7.x86_64

Setup
1. Find the test machine in Beaker: dell-per300-01.rhts.eng.bos.redhat.com

2. Confirm it has a disk of 4k sector.

[root@dell-per300-01 ~]# fdisk -l /dev/sda

Disk /dev/sda: 160.0 GB, 160000000000 bytes, 312500000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
......................
[root@dell-per300-01 ~]# fdisk -l /dev/sdb

Disk /dev/sdb: 162.8 GB, 162842222592 bytes, 39756402 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
.....................

Steps:

1. create a guest named rhel6.4  on default dir pool backed on  sda

2. define a disk pool named sdb backed on /dev/sdb
# virsh pool-dumpxml sdb
<pool type='disk'>
  <name>sdb</name>
  <uuid>c4604c53-315a-3b45-b9b4-c7ac07571edd</uuid>
  <capacity unit='bytes'>162794741760</capacity>
  <allocation unit='bytes'>11062747136</allocation>
  <available unit='bytes'>151731736576</available>
  <source>
    <device path='/dev/sdb'>
    <freeExtent start='11063005184' end='162794741760'/>
    </device>
    <format type='dos'/>
  </source>
  <target>
    <path>/dev</path>
    <permissions>
      <mode>0700</mode>
      <owner>0</owner>
      <group>0</group>
    </permissions>
  </target>
</pool>

3. build and start the pool defined in step 2
# virsh pool-build sdb (with --overwrite option if met error)
# virsh pool-start sdb
4. create a vol in the disk pool using vol.xml
#cat vol.xml
<volume>
  <name>sdb1</name>
  <key>/dev/sdb1</key>
  <source>
    <device path='/dev/sdb'>
    </device>
  </source>
  <capacity unit='M'>10240</capacity>
  <target>
    <path>/dev</path>
  </target>
</volume>
# virsh vol-create sdb vol.xml
5. add the vol sdb1 to guest rhel6.4 as disk sdb, and add "<blockio logical_block_size='512' physical_block_size='4096'/>"
6. reboot guest rhel6.4 and login it
7. check logical_block_size and physical_block_size

# cat /sys/block/sdb/queue/logical_block_size 
512
# cat /sys/block/sdb/queue/physical_block_size 
4096
8. when try to make an partition in sdb with "fdisk" met below error:
...........................
atat1.01:error: { DRDY ERR }
atat1.01:error: { ABRT }
atat1.01:exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
atat1.01:failed command:READ MULTIPLE
atat1.01:cmd c4/00:08:3f:00:00/00:00:00:00:00/f0 tag 0 io 4096 in
         res 41/04:08:3f:00:00/04:00:47:39:80:f0 Emask 0x1 (device error)
atat1.01:status: { DRDY ERR }
atat1.01:error: { ABRT }
atat1.01:exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
atat1.01:failed command:READ MULTIPLE
atat1.01:cmd c4/00:08:3f:00:00/00:00:00:00:00/f0 tag 0 io 4096 in
         res 41/04:08:3f:00:00/04:00:47:39:80:f0 Emask 0x1 (device error)
Buffer I/O error on device sdb, logical block 0
9. check sdb disk.
# fdisk /dev/sdb

Unable to open /dev/sdb

Does that means libvirt work well while the problem is related with qemu-kvm ?
Comment 21 Paolo Bonzini 2013-05-06 11:39:03 EDT
> Sector size (logical/physical): 4096 bytes / 4096 bytes

With 4k logical sector size in the host, you must have a 4k logical sector size in the guest too.
Comment 22 Shanzhi Yu 2013-05-07 02:53:52 EDT
verify this bug with package:
libvirt-1.0.4-1.1.el7.x86_64
qemu-kvm-1.4.0-3.el7.x86_64
Setup:
1. Find the test machine in Beaker: dell-per300-01.rhts.eng.bos.redhat.com

2. Confirm it has a disk of 4k sector.

[root@dell-per300-01 ~]# fdisk -l /dev/sda

Disk /dev/sda: 160.0 GB, 160000000000 bytes, 312500000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
......................
[root@dell-per300-01 ~]# fdisk -l /dev/sdb

Disk /dev/sdb: 162.8 GB, 162842222592 bytes, 39756402 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0008e73a

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63     2622611    10490196   83  Linux
/dev/sdb2         2622720     3622720     4000004   83  Linux

3. create a guest on disk /dev/sda, and add /dev/sdb1 to guest as sda
Steps:
1.Test virtio-scsi
1.1 #virsh edit kvm-rhel6.4,make sure below configurations:
....................
<disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source dev='/dev/sdb1'/>
      <blockio logical_block_size='4096' physical_block_size='4096'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='scsi' index='0' model='virtio-scsi'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </controller>
....................
1.2 start guest and login it.
1.3 check sda disk
# cat /sys/block/sda/queue/logical_block_size 
4096
# cat /sys/block/sda/queue/physical_block_size 
4096
1.4 make an partition sda1 of disk sda and mount it to /mnt/test
# mount
....................
/dev/sda1 on /mnt/test type ext4 (rw)
1.5 can read/write /mnt/test directory without error
# touch /mnt/test/hello
# ls /mnt/test/hello
hello  lost+found
2. Test virtio-blk
2.1 #virsh edit kvm-rhel6.4,make sure below configurations:
..............
<disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source dev='/dev/sdb1'/>
      <blockio logical_block_size='4096' physical_block_size='4096'/>
      <target dev='vdb' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
.................
2.2 start guest and login it.
2.3 check sda disk
# cat /sys/block/vdb/queue/logical_block_size 
4096
# cat /sys/block/vdb/queue/physical_block_size 
4096
2.4 make an partition vdb1 of disk vdb and mount it to /mnt/test
# mount
................
/dev/vdb1 on /mnt/test type ext4 (rw)
2.5 can read/write /mnt/test directory without error
# touch /mnt/test/hello
# ls /mnt/test/hello
hello  lost+found

So verify this bug.

3. while add a images created on /dev/sdb, the guest can't start
3.1 # mount /dev/sdb2/ /var/lib/libvirt/test/
3.2 # qemu-img create -f qcow2 /var/lib/libvirt/test/test.qcow2 5G
3.3 # add test.qcow2 to guest, make below configurations

<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/libvirt/test/test.qcow2'/>
      <blockio logical_block_size='4096' physical_block_size='4096'/>
      <target dev='vdb' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
3.4 start guest, met below error:
# virsh start kvm-rhel6.4
error: Failed to start domain kvm-rhel6.4
error: internal error process exited while connecting to monitor: char device redirected to /dev/pts/1 (label charserial0)
qemu-kvm: -drive file=/var/lib/libvirt/test/test.qcow2,if=none,id=drive-virtio-disk1,format=qcow2,cache=none: could not open disk image /var/lib/libvirt/test/test.qcow2: Invalid argument

Hi Paolo,
while add a image created on /dev/sdb(4k sector) to guest as a file type disk,even through set "blockio" options, the guest fail to start. What's the reason?
Details is as step 3 above.
Comment 23 Shanzhi Yu 2013-05-07 04:17:43 EDT
Hi Paolo,
when I add a image created on /dev/sdb(4kB sector) to guest as a file type disk, even through set "blockio" option, the guest fail to start. Would you please help explain why? Details is in comment 22 step 3.
Thanks
Comment 24 Shanzhi Yu 2013-05-07 05:53:48 EDT
I also test logical_block_size='4096' on a 512-byte sector disk, and it succeed.
Setup:
exist a guest
Steps:
1. create a raw format disk
# qemu-img create -f raw /mnt/test1.img 1G
2. add test.img to guest as sdb. make below configurations
..........
  <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/mnt/test1.img'/>
      <blockio logical_block_size='4096' physical_block_size='4096'/>
      <target dev='sdb' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='scsi' index='0' model='virtio-scsi'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </controller>
3. start guest and login it
4. check sdb disk
# cat /sys/block/sdb/queue/logical_block_size 
4096
# cat /sys/block/sdb/queue/physical_block_size 
4096
5. try to use disk sdb, such as make a partition, format it, read/write it without any error.
Comment 25 Paolo Bonzini 2013-05-07 07:44:23 EDT
Re. comment 23, please open a separate bug.
Comment 26 Shanzhi Yu 2013-05-07 23:22:03 EDT
(In reply to comment #25)
> Re. comment 23, please open a separate bug.

file a new bug:Bug 960803
Comment 27 Ludek Smid 2014-06-13 05:57:39 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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