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 982197

Summary: Unable to successfully virt-install from localhost (unattended)
Product: Red Hat Enterprise Linux 7 Reporter: Pavel Raiskup <praiskup>
Component: qemu-kvmAssignee: Kevin Wolf <kwolf>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: acathrow, codong, dyuan, hhuang, lcui, mkletzan, praiskup, tzheng, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-06 17:33:32 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
kickstart
none
/tmp/anaconda-* logs in tarball
none
Logs
none
installation logs none

Description Pavel Raiskup 2013-07-08 11:34:47 UTC 
Created attachment 770439 [details]
kickstart

I'm unable to finish unattended virt-install'ation (of any Fedora/RHEL virtual
machine) on RHEL7 box from the same RHEL7 box.  Note that I *am* able to
install it from my F19 on the remote RHEL7 box over qemu+ssh://.

The installation always fails in anaconda on mounting already prepared
(probably successfully) filesystems.  Another note worth to say is that I'm
able to properly run (e.g.) 'mkfs.ext4 /dev/vdaX' but mounting of that image
fails and asks me to look into dmesg output.  That output says that:

  ....
  [ timestamp ] end_request: I/O error, dev vda, sector XXXXXXXX
  [ timestamp ] EXT4-fs (vda1): unable to read superblock
  ...

Full virt-install command:

  virt-install                                                          \
    --connect qemu:///system                                            \
    --name f18-x86_64-sec                                               \
    --ram 500                                                           \
    --disk size=5,path=/var/lib/libvirt/images/f18-x86_64-sec.img       \
    --network network=default                                           \
    --virt-type kvm                                                     \
    --graphics spice                                                    \
    --os-variant fedora18                                               \
    --extra-args "ks=http://pensioner.usersys.redhat.com/fedora-live-mini.ks" \
    --location http://download.eng.brq.redhat.com/pub/fedora/linux/releases/18/Fedora/x86_64/os/

Kickstart is attached (not very important, though), the /tmp/anaconda-* files
will be attached later.

The weird thing is that if I run this ^^^ on F19 box by switching the
--connect option to use qemu+ssh://root@my-RHEL7-host/system it works fine. 

Thanks for looking at it, Pavel
Comment 1 Pavel Raiskup 2013-07-08 11:36:12 UTC 
Created attachment 770440 [details]
/tmp/anaconda-* logs in tarball
Comment 3 Martin Kletzander 2013-07-12 09:21:52 UTC 
May I ask you run libvirtd like this:

LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUTS=1:file:/tmp/libvirtd.log libvirtd

try the mentioned installations again (from F19 and RHEL7), both with '--debug', gzip both output of virt-install and /tmp/libvirtd.log on host and attach them to this BZ?  That would be really helpful, thanks.

This problem is so weird I can't really think of anything that might cause it.  You might also do 'virsh dumpxml f18-x86_64-sec' after both installations and compare the output.  If there is no difference between these two, than I'm afraid there is no difference from the host POV.  However there probably will be difference due to default controllers/buses chosen from the supported ones, but that doesn't indicate an error on our side, the problem with reading from the disk must be either in qemu (unlikely) or kernel (depending on how the disk is connected to the machine).
Comment 6 Martin Kletzander 2013-07-31 10:52:17 UTC 
(In reply to hyao from comment #5)
Could you please provide information requested in comment #3?
Comment 7 Pavel Raiskup 2013-07-31 11:40:50 UTC 
Created attachment 781045 [details]
Logs

Apart from Hyao's run, here is the debug info you requested.  There are two
subfolders, 'local' and 'remote' (logs for installation from localhost on RHEL7
box and from remote F19).

If you miss something, let me know.  I rather turned the SELinux off, but still
reproducible.  Note that (i think) the only non-standard setting I have on my
RHEL7 workstation is that the image-data directory is a symlink

    # ls -alh /var/lib/libvirt/images
    lrwxrwxrwx. 1 root root 18 Jun 19 13:58 /var/lib/libvirt/images -> /data/virt-images/

The only difference between the two runs is:
    - --connect qemu:///system
    + --connect qemu+ssh://root.redhat.com/system'

Pavel
Comment 8 Pavel Raiskup 2013-07-31 11:51:50 UTC 
Created attachment 781057 [details]
installation logs

Ups, forgot to add logs from virt-install --debug.  Attaching now.
Comment 9 Martin Kletzander 2013-07-31 12:17:17 UTC 
When installing locally, virt-install (probably thanks to different version), automatically adds cache='none' to the disk, which causes the qemu to be started with ',cache=none' added to the qemu command.  Not elaborating on whether this should be on or off by default, this should fail and the problem is lower than virt-{manager,install} or libvirt.  I'm transferring to QEMU, but problem may be even lower in the stack.
Comment 10 Martin Kletzander 2013-07-31 12:34:42 UTC 
(In reply to Martin Kletzander from comment #9)

s/this should fail/this should NOT fail/

Sorry for the typo which completely changes the meaning.
Comment 12 Pavel Raiskup 2013-11-09 10:10:31 UTC 
Update:  The same hardware, the same system - but switched filesystem from xfs
to ext4 and it works OK now.  It looks like it is somehow related to xfs.
Comment 13 Ademar Reis 2013-12-06 17:33:32 UTC 
cache=none failing when using XFS on the host. Duplicate of 748906

*** This bug has been marked as a duplicate of bug 748906 ***
Comment 14 Pavel Raiskup 2014-06-16 12:12:40 UTC 
Don't know why I'm in needinfo, clearing.