Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 617271

Summary: RHEL6 qemu-kvm guest gets partitioned at sector 63
Product: Red Hat Enterprise Linux 6 Reporter: Eric Sandeen <esandeen>
Component: qemu-kvmAssignee: chellwig <chellwig>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: bcao, chellwig, ddumas, hdegoede, llim, mkenneth, rwheeler, tburke, virt-maint, yanwang
Target Milestone: rcKeywords: RHELNAK
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: qemu-kvm-0.12.1.2-2.102.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-10 21:26:48 UTC Type: ---
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: 519834    

Description Eric Sandeen 2010-07-22 16:06:29 UTC
Description of problem:

Installing RHEL6.0-20100721.n.0-Server-x86_64-DVD1.iso on a host with:

kernel-2.6.32-50.el6.x86_64
qemu-kvm-0.12.1.2-2.96.el6.x86_64
parted-2.1-8.el6.x86_64

yields a /boot partition starting at sector 63 by default.  This is not optimal alignment, and causes perf and/or corruption issues (see bug #615309 for the corruption bug)

Version-Release number of selected component (if applicable):

qemu-kvm-0.12.1.2-2.96.el6.x86_64

How reproducible:

every time

Steps to Reproduce:

qemu-img create /home/rhel6.img 8G
/usr/libexec/qemu-kvm -smp 2 -m 4096 -drive file=/home/rhel6.img,if=virtio,cache=none,aio=native -cdrom RHEL6.0-20100721.n.0-Server-x86_64-DVD1.iso -vnc :0

In the guest, I get logical_block_size, hw_sector_size, minimum_io_size, optimal_io_size, and physical_block_size all at 512.

hansg tells me that optimal_io_size should be 0, and this is why parted is behaving as it does.  TBH I'm not certain where this bug should lie, but given that a normal local disk shows 0 for this value, and a guest shows 512, I'm starting w/ qemu-kvm ...

Comment 1 RHEL Program Management 2010-07-22 16:18:27 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 2 Eric Sandeen 2010-07-22 16:52:06 UTC
(TBH I don't know where this bug belongs, maybe it's parted, but had to start
somewhere.  Also this may be a blocker, it has the potential to really clobber
guest performance I think)

Comment 3 chellwig@redhat.com 2010-07-23 07:22:55 UTC
There are bugs everywhere.  qemu should not advertisze an opt_io_size.  the kernel should not corrupt data for unaligned aio.  But parted also really shouldn't do things against the stated consensus and never ever should move it's alignment below the 1MB threshold.

Comment 4 Hans de Goede 2010-07-23 09:11:56 UTC
Hi,

(In reply to comment #3)
> There are bugs everywhere.  qemu should not advertisze an opt_io_size.  the
> kernel should not corrupt data for unaligned aio.  But parted also really
> shouldn't do things against the stated consensus and never ever should move
> it's alignment below the 1MB threshold.    

The last time this was discussed the conclusion was that parted would default to 1 MiB alignment (which it does), and that it would honer alignment offset and optimum io size (with a fall back to minimum io size) when they are present.

This is exactly what parted is doing. Not moving the alignment below a 1 MiB threshold was never discussed before, and I see no reason for this (actually when 4k physical 512 byte logical sector disks are jumpered for XP compatibility doing so is a bad idea).

Regards,

Hans (the parted maintainer)

Comment 5 Ric Wheeler 2010-07-23 11:38:35 UTC
Will the right thing happen if we fix qemu not to advertise an optimal_io_size?

Comment 6 Hans de Goede 2010-07-23 12:26:23 UTC
(In reply to comment #5)
> Will the right thing happen if we fix qemu not to advertise an optimal_io_size? 

If there is no optimal_io_size and no alignment_offset and minimal_io_size is a power of 2, then parted will use its default alignment of 1MiB, so yes.

Comment 10 Mike Cao 2010-07-29 09:25:57 UTC
Reproduced in qemu-kvm-0.12.1.2-2.99.el6
Verified in qemu-kvm-0.12.1.2-2.104.el6.

Steps :
1.Start VM:
CLI:/usr/libexec/qemu-kvm -M rhel6.0.0 -cpu qemu64,+sse2,+x2apic -enable-kvm -m 8G -smp 8,sockets=8,cores=1,threads=1 -name RHEL6_64 -uuid `uuidgen` -nodefconfig -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/RHEL6.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -boot c -drive file=/mnt/RHEL6.0.raw,if=none,id=drive-ide0-0-0,boot=on,format=raw,cache=none -device virtio-blk-pci,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:20:8d:62:99,bus=pci.0,addr=0x5 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -spice port=5931,disable-ticketing -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
2.in the guest #cat /sys/block/vda/queue/optimal_io_size.

Actual Results:
0

The bug has already been fixed.

Change status to VERIFIED.

Comment 11 releng-rhel@redhat.com 2010-11-10 21:26:48 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.