Bug 749122

Fixing summary. You really don't want to align to 4000 bytes; you want 4096 (4KiB). Dunno why people are *still* getting this wrong.

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.)

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.

> 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.

(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

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

There is a libguestfs package in rhel7, why build your own?

Yes, do we have to build libguestfs ourselves?
Could you please give the error without any translation in error context.

(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?

Created attachment 740294 [details]
testing script

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.

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.

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 ?

> 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.

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.

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

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.

Re. comment 23, please open a separate bug.

(In reply to comment #25)
> Re. comment 23, please open a separate bug.

file a new bug:Bug 960803

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.