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 920083

Summary: virtio-scsi gives errors like: sd 2:0:0:0: [sda] Invalid command failure
Product: Red Hat Enterprise Linux 7 Reporter: bfan
Component: qemu-kvmAssignee: Markus Armbruster <armbru>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 7.0CC: acathrow, hhuang, juzhang, leiwang, michen, pbonzini, qguan, rjones, sluo, virt-maint, wshi
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-27 06:44:52 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:
Attachments:
Description Flags
guestfish boot log
none
/var/log/message
none
libguestfs-test-tool.log
none
guestfish -v -x -N fs:ext3 exit
none
Use rhel7 appliance in FC18
none
Use FC18 appliance in rhel7 none

Description bfan 2013-03-11 10:37:07 UTC 
Description of problem:
For ext2, ext3, xfs, 'mkfs' failed immediately
For ext4, btrfs, 'mkfs' run successfully, but can not get the fs type by command "list-filesystems", shows "unknown"
Already disabled selinux
 

Version-Release number of selected component (if applicable):
kernel: 3.7.0-0.36.el7.x86_64
guestfish: guestfish 1.20.2rhel=7,release=1.el7,libvirt
libvirt: 1.0.3-1.el7.x86_64

How reproducible:
acutually this won't happend with many scenarios, eg
1, run on nfs instead local filesystem
2, run on a local disk created by "dd"
3, just certain machine could reproduce this problem 


Steps to Reproduce:
(1) boot up guestfish with ext3 fs failed, summarize the boot log 
# guestfish -x -v -N fs:ext3
...
ext2fs_mkdir: Attempt to read block from filesystem resulted in short read while creating root dir
guestfsd: main_loop: proc 278 (mkfs) took 0.09 seconds
libguestfs: recv_from_daemon: 192 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 01 16 | 00 00 00 01 | 00 12 34 01 | ...
libguestfs: trace: mkfs = -1 (error)
libguestfs: error: mkfs: ext3: /dev/sda1: mke2fs 1.42.6 (21-Sep-2012)
ext2fs_mkdir: Attempt to read block from filesystem resulted in short read while creating root dir
guestfish: error creating prepared disk image 'fs:ext3' on 'test1.img': failed to create filesystem (ext3): mkfs: ext3: /dev/sda1: mke2fs 1.42.6 (21-Sep-2012)
ext2fs_mkdir: Attempt to read block from filesystem resulted in short read while creating root dir
...


(2) boot up guestfish with ext4, boot successfully, but can not get the file system type
# guestfish -x -v -N fs:ext4
><fs>list-filesystems
/dev/sda1: unknown
><fs>mkfs ext4 /dev/sda1
libguestfs: trace: mkfs = 0
><fs>list-filesystems
/dev/sda1: unknown

><fs>mkfs ext3 /dev/sda1
libguestfs: trace: mkfs = -1 (error)
libguestfs: error: mkfs: ext3: /dev/sda1: mke2fs 1.42.6 (21-Sep-2012)
Warning: could not read block 0: Attempt to read block from filesystem resulted in short read
ext2fs_mkdir: Attempt to read block from filesystem resulted in short read while creating root dir


Actual results:
For ext2, ext3, xfs, 'mkfs' failed
For ext4, btrfs, 'mkfs' run successfully, but can not get the correct fs type

Expected results:
All kinds of fs can be created successfully and can get the correct type


Additional info:
Attach detail logs , it may be useful
boot.log -- guestfish boot log with ext3
message  --  /var/log/message
Comment 5 bfan 2013-03-12 02:09:35 UTC 
Created attachment 708708 [details]
guestfish boot log
Comment 6 bfan 2013-03-12 02:10:17 UTC 
Created attachment 708713 [details]
/var/log/message
Comment 7 bfan 2013-03-12 02:18:38 UTC 
Created attachment 708715 [details]
libguestfs-test-tool.log
Comment 8 bfan 2013-03-12 02:19:26 UTC 
Created attachment 708717 [details]
guestfish -v -x -N fs:ext3 exit
Comment 10 Richard W.M. Jones 2013-03-12 14:15:53 UTC 
I'm more sure than before this is a kernel or qemu or virtio-scsi
bug in RHEL 7.  Nothing like this happens in Fedora 18.  The log shows:

[    0.510742] scsi2 : Virtio SCSI HBA
[    0.513571] scsi 2:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    1.4. PQ: 0 ANSI: 5
[    0.514436] scsi 2:0:1:0: Direct-Access     QEMU     QEMU HARDDISK    1.4. PQ: 0 ANSI: 5
[    0.526318] sd 2:0:0:0: [sda] 204800 512-byte logical blocks: (104 MB/100 MiB)
[    0.527064] sd 2:0:1:0: [sdb] 8388608 512-byte logical blocks: (4.29 GB/4.00 GiB)

and then shortly afterwards lots and lots of this:

[    1.247328] sd 2:0:0:0: [sda] Invalid command failure
[    1.248467] sd 2:0:0:0: [sda]  
[    1.249108] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[    1.250161] sd 2:0:0:0: [sda]  
[    1.250704] Sense Key : Illegal Request [current] 
[    1.251654] sd 2:0:0:0: [sda]  
[    1.252282] Add. Sense: Invalid field in cdb
[    1.253136] sd 2:0:0:0: [sda] CDB: 
[    1.253730] Read(10): 28 00 00 03 1f ff 00 00 01 00
[    1.255074] end_request: critical target error, dev sda, sector 204799
Comment 11 Paolo Bonzini 2013-03-12 16:24:11 UTC 
virtio-scsi is not a separate component.  Can you try swapping out qemu and kernel?  That is, using the RHEL7 appliance on F18 libguestfs, or the F18 appliance on RHEL7 libguestfs?
Comment 12 Richard W.M. Jones 2013-03-12 17:47:30 UTC 
bfan: If you want to follow Paolo's suggestion, then just run:

  libguestfs-make-fixed-appliance --xz

on one machine, and copy the generated file 'appliance-<VERSION>.tar.xz'
to another machine.  They unpack that file and follow the simple
instructions in the README file, which are also online here:
http://libguestfs.org/download/binaries/appliance/README.txt
Comment 13 Richard W.M. Jones 2013-03-12 17:48:23 UTC 
(In reply to comment #12)
> They unpack that file and follow the simple
> instructions in the README file, which are also online here:
> http://libguestfs.org/download/binaries/appliance/README.txt

Erm, I mean: You don't need to do the compiling bit.  Just
setting LIBGUESTFS_PATH to wherever you unpacked the appliance
is sufficient.
Comment 14 bfan 2013-03-13 10:33:20 UTC 
Created attachment 709476 [details]
Use rhel7 appliance in FC18
Comment 15 bfan 2013-03-13 10:33:54 UTC 
Created attachment 709477 [details]
Use FC18 appliance in rhel7
Comment 16 bfan 2013-03-13 10:35:38 UTC 
(In reply to comment #13)
> (In reply to comment #12)
> > They unpack that file and follow the simple
> > instructions in the README file, which are also online here:
> > http://libguestfs.org/download/binaries/appliance/README.txt
> 
> Erm, I mean: You don't need to do the compiling bit.  Just
> setting LIBGUESTFS_PATH to wherever you unpacked the appliance
> is sufficient.

Use rhel7 appliance in FC18, works well.
attached: "Use rhel7 appliance in FC18"

Use FC18 appliance in rhel7, failed with same reason.
attached: "Use FC18 appliance in rhel7"

FC18:
3.6.10-4.fc18.x86_64
guestfish 1.20.2fedora=18,release=5.fc18,libvirt
Comment 17 Richard W.M. Jones 2013-03-13 13:16:59 UTC 
(In reply to comment #16)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > They unpack that file and follow the simple
> > > instructions in the README file, which are also online here:
> > > http://libguestfs.org/download/binaries/appliance/README.txt
> > 
> > Erm, I mean: You don't need to do the compiling bit.  Just
> > setting LIBGUESTFS_PATH to wherever you unpacked the appliance
> > is sufficient.
> 
> Use rhel7 appliance in FC18, works well.
> attached: "Use rhel7 appliance in FC18"
> 
> Use FC18 appliance in rhel7, failed with same reason.
> attached: "Use FC18 appliance in rhel7"
> 
> FC18:
> 3.6.10-4.fc18.x86_64
> guestfish 1.20.2fedora=18,release=5.fc18,libvirt

This implies that it's a qemu-on-RHEL 7 bug.  Reassigning
accordingly.
Comment 18 Paolo Bonzini 2013-03-14 14:55:47 UTC 
bfan, what's the QEMU version you're testing?

And Richard, can you test rawhide please?  I'd hope that this just fixes itself with the next RHEL7 rebase...
Comment 19 bfan 2013-03-15 10:02:27 UTC 
(In reply to comment #18)
> bfan, what's the QEMU version you're testing?
> 
qemu-kvm-1.4.0-1.el7 and qemu-1.2.2-6.fc18

> And Richard, can you test rawhide please?  I'd hope that this just fixes
> itself with the next RHEL7 rebase...
Comment 20 Richard W.M. Jones 2013-05-22 14:13:16 UTC 
(In reply to Paolo Bonzini from comment #18)
> bfan, what's the QEMU version you're testing?
> 
> And Richard, can you test rawhide please?  I'd hope that this just fixes
> itself with the next RHEL7 rebase...

I wonder if this is still a problem?  I've been using upstream
qemu from git and qemu-1.5.0-1.fc20.x86_64 and have not seen any
virtio-scsi bugs for a long long time.
Comment 21 bfan 2013-05-27 02:41:24 UTC 
(In reply to Richard W.M. Jones from comment #20)
> (In reply to Paolo Bonzini from comment #18)
> > bfan, what's the QEMU version you're testing?
> > 
> > And Richard, can you test rawhide please?  I'd hope that this just fixes
> > itself with the next RHEL7 rebase...
> 
> I wonder if this is still a problem?  I've been using upstream
> qemu from git and qemu-1.5.0-1.fc20.x86_64 and have not seen any
> virtio-scsi bugs for a long long time.

I tried qemu-kvm-1.5.0-1.el7.x86_64 with latest rhel7 eng tree, it works
Comment 22 Markus Armbruster 2013-05-27 06:44:52 UTC 
Closing out as per comment#21.