Bug 982197 - Unable to successfully virt-install from localhost (unattended)
Summary: Unable to successfully virt-install from localhost (unattended)
Status: CLOSED DUPLICATE of bug 748906
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Kevin Wolf
QA Contact: Virtualization Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2013-07-08 11:34 UTC by Pavel Raiskup
Modified: 2014-06-16 12:12 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-12-06 17:33:32 UTC
Target Upstream Version:

Attachments (Terms of Use)
kickstart (2.43 KB, text/plain)
2013-07-08 11:34 UTC, Pavel Raiskup
no flags Details
/tmp/anaconda-* logs in tarball (34.49 KB, application/x-xz)
2013-07-08 11:36 UTC, Pavel Raiskup
no flags Details
Logs (3.56 MB, application/x-xz)
2013-07-31 11:40 UTC, Pavel Raiskup
no flags Details
installation logs (3.25 KB, application/x-xz)
2013-07-31 11:51 UTC, Pavel Raiskup
no flags Details

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

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@redhat.com 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]

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@pensioner.usersys.redhat.com/system'


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.

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